AW: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.

["Fritsche Wolfgang" <Fritsche@iabg.de>]

I do support the adoption of the ULE draft as a WG draft.

Cheers,

Wolfgang

> -----Ursprüngliche Nachricht-----
> Von: owner-ip-dvb@erg.abdn.ac.uk
> [mailto:owner-ip-dvb@erg.abdn.ac.uk] Im Auftrag von Gorry Fairhurst
> Gesendet: Montag, 9. Februar 2004 11:58
> An: ipdvb@erg.abdn.ac.uk
> Betreff: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
> 
> 
> As WG chair, I request the ipdvb list to consider whether the
> WG is ready to support adoption of the following individual 
> Internet Draft (ID) as a WG ID. 
> By adopting an individual ID as a working group ID, this WG 
> indicates that 
> it intends to be develop this into an RFC, according to the 
> WG charter. 
> 
> WG documents should no longer be regarded as the property of the
> individuals who originally authored them - the working group 
> as a whole 
> must decide how they are shaped, and to see the document to
> a successful conclusion. If adopted, the Internet Draft will 
> be renamed to start with the filename draft-ietf-ipdvb..., 
> and will be listed on the IETF web page for this WG.
> 
> ---
> 
>         Title           : Ultra Lightweight Encapsulation (ULE) for
>                           transmission of IP datagrams over
>                           MPEG-2/DVB networks
>         Author(s)       : G. Fairhurst, B. Collini-Nocker
>         Filename        : draft-fair-ipdvb-ule-02.txt
>         Pages           : 32
>         Date            : 2003-11-24
>         
> The MPEG-2 TS has been widely accepted not only for providing
> digital TV services, but also as a subnetwork technology for 
> building IP networks. This document describes an Ultra 
> Lightweight Encapsulation (ULE) mechanism for the transport 
> of IPv4 and IPv6 Datagrams and other network protocol packets 
> directly over ISO MPEG- 2 Transport Streams (TS) as TS Private Data.
> 
> ---
> 
> You are encouraged to send email to this WG, to help make the
> decision for adoption.  Possible recommendations are:
> 
>       1) Support for adoption as a working group draft under
> our Charter -
>       i.e. Recommend this Internet Draft SHOULD be used as 
> the basis for
>       developing an RFC by the ipdvb WG.
> 
>       2) Request for non-adoption
>       i.e. That there is (or could be) alternative approaches to
>       the problem, and that the current draft is not sufficiently
>       developed / or correctly designed ipdvb WG
> 
>       3) Out of scope
>       i.e. you believe the document to be beyond the scope of the
>       approved ipdvb WG charter.
> 
> Emails on this topic should be sent to the ipdvb mailing list
> before 23rd February 2004.
> 
> Note that an ID does not need to be complete to be adopted.
> It would also be most useful to collect as many 
> comments/criticisms as possible from those reading this ID.  
> Looking through the archived mailing list, a first list of 
> issues to be addressed is included at the end of this email.
> 
> Please do help to identify any more known (or potential)
> issues that should be addressed/discussed.
> 
> Best wishes,
> 
> Gorry Fairhurst
> (ipdvb WG Chair)
> 
> 
> ---
> 
> 
> Known issues with draft-fair-ipdvb-ule-02.txt
> =============================================
> 
> 1) Refinement of the text on CRC generation to be unambiguous
> (explicitly talk about the polynomial as a forward CRC-32
>  and THEN explicitly about the computation process)
> - Text to be rewritten.
> 
> 2) Query about the code point value for an Ethernet Bridging
> SNDU - should the ULE type-field be 0x0001 ; 0x0007 as in 
> ATM/AAL5 (as in RFC2684); 
> or should the IEEE Ethertype for bridging (0x6558) be used instead?
> - Discuss on list.
> 
> 3) Need to check the SNDU Packing/Padding examples in the
> informative appendix of the ID for correctness (including the 
> length of the last 
> packet of example A.4) 
> --- any volunteers?
> 
> 4) Suggestion to add an appendix to the next rev of the ID,
> with a hexadecimal example of an SNDU, to assist implementors 
> in validating the operation of the CRC. The following example 
> has been proposed:
> 
> >> Ping6
> >> from 2001:660:3008:1789::5 to 2001:660:3008:1789::6, with the
> >> associated DVB MAC addr being 01:02:03:04:05:06. It gives the 
> >> following SNDU :
> >> 
> >> 0000:  00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d
> >> .?........`.....
> >> 0010:  3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00  :@ 
> ..`0.........
> >> 0020:  00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00  ..
> ..`0.........
> >> 0030:  00 06 80 00 9c 58 07 70 00 00 00 00 00 00 00 02
> .....X.p........
> >> 0040:  72 c9 c2                                         r..
> >> 
> - The exact decode of this needs to be done and verified
> 
> 
> 5) ???
> 
> 
>