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

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

On 12/2/04 8:16 am, "Rod.Walsh@nokia.com" <Rod.Walsh@nokia.com> wrote:

> 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.

There are now several early implementations being developed, so I'm keen to progress this, in parallel with this.

The milestones for ULE are on the ipdvb Charter page at: http://ietf.org/

> BTW, the "option (2)" is rather confusing

Sorry, it was just a general form of words for adopting a WG item. The aim is to allow people to tell the WG, if there is another (competing) ID on the way, or some alternative approach that also would address the charter, and hence they have concerns about adopting the WG item.

> "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 :).

Indeed MPE exists - and is acknowledged in the WG Charter.

The UNISAL encapsulation is not (as far as I am aware) being resubmitted to this WG as a competitor to ULE.

> 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.

Exactly, the WG is now looking for any inputs and/or potential concerns.

> Is this just imprecise wording, or have I misunderstood? - please 
> clarify.

The wording of (2) was loose, to allow scope to respond - thanks for asking.

> 
> (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) ???
> 
> 
5= Consideration of the proposed ULE Extension Header
>