Re: AD Review Comments on draft-ietf-ipdvb-ule-05.txt

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

Thanks Margaret, this seems like a very positive review from our AD.

See below for text which we hope will resolve the issues that you raised.
Do these cover your current concerns?

If they do, we will add them to the edit list for the next rev (and publish 
when you finally call a revised I-D).

Gorry & Bernhard
(ULE ID Authors)


Margaret Wasserman wrote:

>
> Hi All,
>
> I have finished my AD review of draft-ietf-ipdvb-ule-05.txt.  This document 
appears to be in very good shape.  I just have a couple of comments/questions 
on the document (see below) that I would like to resolve before sending the 
document to the IESG for final review.
>
> Since any changes related to these comments are likely to be very small, I 
will send the document to IETF LC in parallel with resolving these issues. 
Gorry, if you like, you can wait until the IETF LC completes and make any 
changes resulting from these comments at the same time as you make any changes 
to address the IETF LC comments.
>
> Margaret
>
> ---
>
> 4. SNDU Format
>
>    PDUs are encapsulated using ULE to form an SNDU. (Each SNDU is an
>    MPEG-2 Payload Unit.) The encapsulation format to be used for PDUs
>    is illustrated below:
>
>    < ----------------------------- SNDU ----------------------------- >
>    +-+-------------------------------------------------------+--------+
>    |D| Length | Type |                 PDU                   | CRC-32 |
>    +-+-------------------------------------------------------+--------+
>
>    Figure 1: SNDU Encapsulation
>
>    All multi-byte values in ULE (including Length, Type, and
>    Destination fields) are transmitted in network byte order (most
>    significant byte first). The most significant bit of each byte is
>    placed in the left-most position of the 8-bit field. Appendix A
>    provides informative examples of usage.
>
>>>  A destination field is mentioned in the text, but not shown in
>>>  the diagram?  It might make sense to how/where the destination
>>>  may be included before mentioning it.
>
>
Gorry/Bernard writes:

Hmm... yes you're correct this contains a forward reference, and probably
should be made explicit:

OLD:
   < ----------------------------- SNDU ----------------------------- >
   +-+-------------------------------------------------------+--------+
   |D| Length | Type |                 PDU                   | CRC-32 |
   +-+-------------------------------------------------------+--------+

   Figure 1: SNDU Encapsulation

NEW:

   < ----------------------------- SNDU ----------------------------- >
   +-+-------------------------------------------------------+--------+
   |D| Length | Type | Dest Address* |           PDU         | CRC-32 |
   +-+-------------------------------------------------------+--------+

   Figure 1: SNDU Encapsulation (* optional Destination Address)

OLD:
   All multi-byte values in ULE (including Length, Type, and
   Destination fields) are transmitted in network byte order (most
   significant byte first).
NEW:
   All multi-byte values in ULE (including the Length/End Indicator
   (4.2,4.3), Type (4.4), Destination Address (4.5), and Extension
   Headers (5)) are transmitted in network byte order (most
   significant byte first).



>
>    5.1 Test SNDU
>
>    A Test SNDU (figure 10) is of a Mandatory Extension Header of Type
>    1. This header must be the final (or only) extension header
>    specified in the header chain of a SNDU.
>
> [...]
>
>    5.2 Bridge Frame SNDU Encapsulation
>
>    A bridged SNDU is a Mandatory Extension Header of Type 1. It must be
>    the final (or only) extension header specified in the header chain
>    of a SNDU.
>
>>>  Is it intentional that the Test SNDU and the Bridge Frame SNDU
>>>  headers cannot be used in the same SNDU?


Gorry/Bernhard:
 Certainly a bridged SNDU must be the last extension header
 in a chain, the payload of the bridged SNDU *IS* an Ethernet MAC/LLC frame.

 The payload of a TEST SNDU is ignored, and teh format is not defined.

- So the answer to the question is "Yes".  Both these examples MUST come at 
the end of the header chain. I guess this could be true of other Mandatory 
Extension Headers, but this is not necessarily intended to be true of all 
mandatory extension headers:

e.g. A mandatory encryption header (much discussed informally, but not yet 
specified - expect an I-D proposing before the next IETF) could possibly 
contain a Type field with further extensions specified - ROHC inside 
encryption would be a good example of a useful combination, bridging inside 
encryption also seems useful.


>
>
> 3. Description of the Method
>
> [...]
>
>    The ULE encapsulation is limited to TS private streams only. The
>    header of each TS Packet carries a one bit Payload Unit Start
>    Indicator (PUSI) field. A PUSI field with a value of 1 indicates the
>    presence of at least one Payload Unit (SNDU) within the TS Packet
>    payload.
>
>>>  s/the presence of at least one/the start of at least one/  ??
>>>
>>>  If I understand this correctly, the PUSI field will be 0 if
>>>  the TS does not include the start of an SNDU.
>

YES. Your proposed edit is good. The text will be updated.

----