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

From: Margaret Wasserman <[email-masked]>
Date: Mon, 2 May 2005 05:45:31 -0400

Hi All,

I have reviewed draft-ietf-ipdvb-ule-05.txt.  I do have a few 
comments/questions on this document (see below), but they are not 
very fundamental issues.  So, I will send this document to IETF Last 
Call, and we can resolve my issues along with any other IETF LC 
comments.

Gorry and Bernhard, thanks for your excellent work on this document.

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.

    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?

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 last one/  ??
>>
>>  If I understand this correctly, the PUSI field will be 0 if
>>  the TS does not include the start of an SNDU.

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 02 May 2005 15:13:10 +0100

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.
 >    < ----------------------------- SNDU ----------------------------- >
Gorry/Bernard writes:

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

OLD:

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

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

 >>>  s/the presence of at least one/the start of at least one/  ??
 >>>

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

----

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 24 May 2005 15:52:37 -0400

Hi Gorry,

Sorry not to write back sooner...  I tend to get behind on the WG 
mailing lists.

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

Yes, definitely!  I think that this is a well-written and sound document.

>Do these cover your current concerns?

Yes, your answers have resolved my concerns.   I have this document 
on the IESG agenda for this Thursday, so you can wait to address 
these comments along with any other IESG comments. Please make sure 
that the edits make it into the next version, though.

Thanks!

Margaret