[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hello,

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

Benoit

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