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

[<Rod.Walsh@nokia.com>]

Hi Gorry & WG

I also support ULE adoption as a WG draft.

Please spell out the proposed timeframe as this has a big effect on the quality of the final document developed.

BTW, the "option (2)" is rather confusing "That there is (or could be) alternative approaches to the problem, and that the current draft is not sufficiently developed", since there is an existing solution (MPE) and there certainly are alternatives (even ipdvb started with 2 :). Also, the point of chartering into a WG is to develop the work-in-progress draft with the aim of publishing as an RFC - not just rubber stamp the individual draft with an RFC number. Is this just imprecise wording, or have I misunderstood? - please clarify.

(I'll be in Korea, so would be happy to share a couple of round with anyone interested in a bar-WG - not a bar-bof anymore :)

Cheers, Rod.


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