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

[Martin Stiemerling <stiemerling@netlab.nec.de>]

Hi,

I support to accept ULE as WG document.

 Martin

--On Montag, 9. Februar 2004 10:57 Uhr +0000 Gorry Fairhurst 
<gorry@erg.abdn.ac.uk> wrote:

| 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) ???
|
|