Re: I-D ACTION:draft-wan-ipdvb-rohc-00.txt

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

Thanks,

See in-line for a clarification, and some suggestions on formatting.

Best wishes,

Gorry

Ang Way Chuang wrote:
> Dear Dr. Fairhurst,
>
> Here is updated version according your previous feedback, but still 
> incomplete. I removed the section that carries ROHC compressed packet 
> directly over MPEG2-TS. So, what works for ULE should also work for GSE 
> except for section 4.1.4.1.1 which relies on MPEG2-TS.
>
> In addition to 2 new ULE type, we also need to have a new EtherType for 
> section 3.1.2. If getting new EtherType is hard, we may need to redefine 
> the packet format.
>
> As for your previous comment:
>  > 2) In Section 3.1.1:
>  >
>  > "In the absence of multiple receivers, a transmitter can send an
>  > SNDU"...
>  >
>  > I think this is only partially true, it may be safer to refer this to
>  > RFC4326, since this is also dependent on the way in which the ULE
>  > Stream is used.
>
> I'm not sure what you meant exactly. I refer to figure 11 of RFC4326 and 
>  the Receiver Destination NPA address field seems redundant since MAC 
> destination address is there. Any practical scenario where Receiver 
> Destination needs to be different from MAC destination address?
There could be - when the receiver is an Ethernet Bridge and this is 
feeding a local area network. In the case in Figure 11, the NPA address 
is the address of the receiver itself. This topology resembles that of 
Metro-Ethernet - where Ethernet frames are bridged between two or more 
attached LANs using a L2 network. The NPA addresses are local only to 
the DVB/MPEG network and used to construct the "virtual" transmission 
network.


> Diagrams has been changed to conform with the style used by RFC4326, but 
>  style of diagram 4, 5, 6 and 7 is left untouched since it is difficult 
> to represent variable format imposed by medium information using the 
> former style.
>
> Thank you.
---

The abstract should state the name of the specification it is extendin 
in full, hence:

 " This document describes a set of Extension Headers for the
   Unidirectional Lightweight Encapsulation (ULE), RFC4326."

---

You may also wish to define:
   B: Byte. Groups of bytes are represented in Internet byte order.


   Next-Header: A Type value indicating an Extension Header [RFC4326].

   NPA: Network Point of Attachment [RFC4326]. In this document, refers
   to a destination address (resembling an IEEE MAC address) within the
   DVB-S/S2 transmission network that is used to identify individual
   Receivers or groups of Receivers.

   ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A
   method that encapsulates PDUs into SNDUs that are sent in a series
   of TS Packets using a single TS Logical Channel. The encapsulation
   defines an extension format and an associated IANA Registry.


---


I suggest rewriting the IANA section, so that reads something like the 
following. This is the form of words we used in previous IANA requests.

   This document requires IANA involvement for the assignment of two
   new Next-Header Type values from the IANA ULE Next-Header Registry.

   The following assignments have been made in this document, and
   registered by IANA:

   XXX NOTE: IANA please replace TBD and TBD-1 when assigned XXX

         Type      Name                             Reference

         TBD:      ULE-ROHC                        Section 3.1
         TBD-1:    ULE-ROHC-Neg                    Section 4.1


   The ULE-ROHC Extension is a Mandatory next-type Extension Header,
   specified in section 3.1 of this document. The value of this next-
   header is defined by an IANA assigned H-Type value of TBD.

   The ULE-ROHC-Neg Extension is a Mandatory next-type Extension Header
   specified in section 4.1 of this document. The value of this next-
   header is defined by an IANA assigned H-Type value of TBD-1.

---


The University of Aberdeen is a charity registered in Scotland, No SC013683.