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

["Gessler Gerhard" <Gessler@iabg.de>]

I do support the adoption of this draft as a WG item.

--------------------------------------------
Gerhard Geßler

Communication Networks, IABG mbH
Einsteinstr. 20
85521 Ottobrunn, Germany

Telefon: +49 89 6088 - 2021
Fax: +49 89 6088 - 2845

E-Mail: gessler@iabg.de 

  > -----Original Message-----
  > From: owner-ip-dvb@erg.abdn.ac.uk 
  > [mailto:owner-ip-dvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst
  > Sent: Monday, February 09, 2004 11:58 AM
  > To: ipdvb@erg.abdn.ac.uk
  > Subject: 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) ???
  > 
  > 
  >