Subject: Completion of ULE WGLC -03

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 20 Dec 2004 17:15:58 +0000

Revision 3 of the ULE Spec recently completed the last call period within this 
WG.  There is still one report to be submitted, but in the mean-time I have 
collated the issues that have been raised in the following spread-sheet.

Gorry Fairhurst
(ipdvb WG Chair)

+----+---------------------------+---------------------------+----------+
|    |           ULE-Spec 03     |       WGLC Issues,        |          |
|    |                           |updated 17th Deecember 2004|          |
+----+---------------------------+---------------------------+----------+
|Iss |Section       Status       |        Description        |  Notes   |
|    |                           |                           |          |
+----+---------------------------+---------------------------+----------+
| 1  |   5    Raised during WGLC |  The text says: "a 5-bit  |W.Stering |
|    |fig. 10 - diagram Changed  |  zero prefix and a 3-bit  |archive/ms|
|    |                           |   H-Len field", but the   |g00861.htm|
|    |                           |          figure           |    l     |
|    |                           |shows 4 bits zero and thus |          |
|    |                           | suggests 4 bit for H-Len. |          |
+----+---------------------------+---------------------------+----------+
| 2  |  4.7   Raised during WGLC |"Next Header Type Fields": |W.Stering |
|    |         - Moved to Sect 5 |When considering extension |archive/ms|
|    |        - NOTE: Padding is |headers, type field values |g00861.htm|
|    |           an OPTIONAL     |  of 0x0000 (TEST SNDU),   |    l     |
|    |        extension header.  |0x0001 (BRIDGED SNDU), and |          |
|    |                           |0x0100 (PADDING) are to be |          |
|    |                           |      interpreted as       |          |
|    |                           |    mandatory extension    |          |
|    |                           |  headers.  We propose to  |          |
|    |                           |describe these in section 5|          |
|    |                           |  and state in 4.4.1 that  |          |
|    |                           |type field values less than|          |
|    |                           |   1536 denote extension   |          |
|    |                           |         headers.          |          |
+----+---------------------------+---------------------------+----------+
| 3  |        Raised during WGLC |PADDING type: 0x0100 would |W.Stering |
|    |        - clarification of | decode as a 2 bytes long  |archive/ms|
|    |        question required. |    optional extension     |g00861.htm|
|    |                           |header, which is obviously |    l     |
|    |                           |     not as intended.      |          |
+----+---------------------------+---------------------------+----------+
| 4  |  4.5   Raised during WGLC | "SNDU Destination Address |W.Stering |
|    |                -          |          Field":          |archive/ms|
|    |                           | If extension headers are  |g00861.htm|
|    |       Figure 8 changed to | used in combination with  |    l     |
|    |       show case where D=0 | SNDU destination address  |          |
|    |        and therefore the  |(i.e. D-Bit is zero), it is|          |
|    |       NPA directly follows| not clear, where exactly  |          |
|    |        the Type field of  |  the NPA address has to   |          |
|    |         the base header.  |be placed, i.e. after which|          |
|    |                           |type field: after the last |          |
|    |                           |    extension header or    |          |
|    |                           |after the SNDU header (thus|          |
|    |                           |occupying bytes 5 to 10 of |          |
|    |                           |      the SNDU).  For      |          |
|    |                           |  ease of processing and   |          |
|    |                           | filtering, we propose to  |          |
|    |                           |   have the NPA address'   |          |
|    |                           | position fixed, directly  |          |
|    |                           |following the 4-bytes SNDU |          |
|    |                           |   header.  An STB would   |          |
|    |                           |    have to decode all     |          |
|    |                           | extension headers to find |          |
|    |                           | the NPA address, just to  |          |
|    |                           |discover that it has to be |          |
|    |                           |  dropped, if it doesn't   |          |
|    |                           |match its own MAC address. |          |
+----+---------------------------+---------------------------+----------+
| 5  |        Raised during WGLC |   Bridging VLAN frames:   |W.Stering |
|    |        - query, this is a |There is a note in section |archive/ms|
|    |       standard ethertype. |  4.7.5, after figure 9,   |g00861.htm|
|    |                           |      stating that a       |    l     |
|    |                           | bridged SNDU could convey |          |
|    |                           |an 802.3 Ethernet frame (as|          |
|    |                           |        opposed to         |          |
|    |                           |the examples (fig. 8, fig. |          |
|    |                           | 9) containing an LLC/SNAP |          |
|    |                           |      encapsulation.       |          |
|    |                           |    This note should be    |          |
|    |                           |  extended to also cover   |          |
|    |                           |   802.1q frames (VLAN),   |          |
|    |                           |which contain a 4-byte VLAN|          |
|    |                           | tag after the 2 Ethernet  |          |
|    |                           |      MAC addresses.       |          |
|    |                           |                           |          |
+----+---------------------------+---------------------------+----------+
| 6  |   5   Proposed resolution:|Figure 12 does not provide |Raised by |
|    |Fig 12 This  diagram could |   clear guidance on the   |   BCN    |
|    |           be fixed by     |placement of the NPA field |          |
|    |        replacing it with  |when extension headers are |          |
|    |         one quoting ther  |  present. The placement   |          |
|    |          case where D=0   |  within the base-header   |          |
|    |                           |  needs to be clarified.   |          |
|    |                           |                           |          |
+----+---------------------------+---------------------------+----------+
| 7  | 4.7.5  Raised during WGLC |     Bridge Frame SNDU     |Raised by |
|    | Fig 8                     |       Encapsulation       |    GF    |
|    |                           |  - "Receiver Destination  |          |
|    |                           | Address" should be marked |          |
|    |                           |     as "NPA Address"      |          |
+----+---------------------------+---------------------------+----------+
| 8  |Definit Raised during WGLC |Broad issue - if the term  |Raised by |
|    | ions                      |being defined is in all    |    AA    |
|    |                           |caps, should not it be in  | msg00867 |
|    |                           |all caps when that defined |          |
|    |                           |term is used? Or a rule    |          |
|    |                           |that only initial caps     |          |
|    |                           |are used after the all caps|          |
|    |                           |format should be pointed   |          |
|    |                           |out. It is very bad to     |          |
|    |                           |attempt, and I believe this|          |
|    |                           |draft must not, normatively|          |
|    |                           |redefine any ISO/IEC       |          |
|    |                           |defined term. It may       |          |
|    |                           |informatively list what    |          |
|    |                           |another standard defines.  |          |
+----+---------------------------+---------------------------+----------+
| 9  | Refs   Raised during WGLC |Quick scan - Need work on  |Raised by |
|    |                           |MPEG term usage; Section 7 |    AA    |
|    |                           |scoping; Refs should be    | msg00867 |
|    |                           |updated from source web    |          |
|    |                           |sited just b4 publications |          |
|    |                           |(A/53 is now A/53C, for    |          |
|    |                           |example)                   |          |
+----+---------------------------+---------------------------+----------+
| 10 |Definti Raised during WGLC |@PRIVATE SECTION. While    |Raised by |
|    |  ons                      |the use listed is one use, |    AA    |
|    |  p10                      |use of private sections    | msg00867 |
|    |                           |is NOT constrained to only |          |
|    |                           |service information. It may|          |
|    |                           |be used for any            |          |
|    |                           |Program data<a 13818-1     |          |
|    |                           |defined term>.  It is not  |          |
|    |                           |accurate to assert that all|          |
|    |                           |table sections must be     |          |
|    |                           |carried over a single TS   |          |
|    |                           |Logical Channel. Further   |          |
|    |                           |attempting to assert the   |          |
|    |                           |rules for such sections is |          |
|    |                           |in appropriate as          |          |
|    |                           |13818-1 rules. The draft   |          |
|    |                           |should say, informatively, |          |
|    |                           |something like "ISO-MPEG   |          |
|    |                           |requires that all table    |          |
|    |                           |sections of a particular   |          |
|    |                           |table _id must be carried  |          |
|    |                           |in packets identified with |          |
|    |                           |a single PID. A packets    |          |
|    |                           |with a given PID may       |          |
|    |                           |contain data for more than |          |
|    |                           |one set of table sections. |          |
+----+---------------------------+---------------------------+----------+
| 11 |Definti Raised during WGLC |TABLE   SECTION.      Table|Raised by |
|    |  ons                      |sections are used for  many|    AA    |
|    |  p10                      |purposes beside MPEG-2     | msg00867 |
|    |                           |SI. Users  of  MPEG-2  have|          |
|    |                           |added  their  own  PSI[sic]|          |
|    |                           |table sections and         |          |
|    |                           |employer  them  for   other|          |
|    |                           |purposed. Also there may be|          |
|    |                           |private table sections     |          |
|    |                           |that   have   any   desired|          |
|    |                           |purpose. The point is  they|          |
|    |                           |are related to any         |          |
|    |                           |particular  MPEG   Program,|          |
|    |                           |not the System Information.|          |
+----+---------------------------+---------------------------+----------+
| 12 |Definti Raised during WGLC |  missing PDU definition.  |Raised by |
|    |  ons                      |                           |    AA    |
|    |  p10                      |                           | msg00867 |
+----+---------------------------+---------------------------+----------+
| 13 |        Raised during WGLC | TS LOGICAL CHANNEL:  Add  |Raised by |
|    |                           |   'unique' to: "...All    |    AA    |
|    |                           |    packets sent over a    | msg00867 |
|    |                           | TS Logical Channel carry  |          |
|    |                           |the same unique PID value."|          |
|    |                           |      PID values are       |          |
|    |                           |   required to be unique   |          |
|    |                           |within each TS MULTIPLEX by|          |
|    |                           |      MPEG-2 systems.      |          |
+----+---------------------------+---------------------------+----------+
| 14 |        Raised during WGLC |TS MULTIPLEX:     Defining |Raised by |
|    |                           |a TS MULTIPLEX in terms of |    AA    |
|    |                           |       the set of TS       | msg00867 |
|    |                           |  logical channels is an   |          |
|    |                           |interesting way to view it,|          |
|    |                           |    but as there is an     |          |
|    |                           | internationally approved  |          |
|    |                           |standard it would seem best|          |
|    |                           |   to reference ISO/IEC    |          |
|    |                           |13818-1.  It is NOT limited|          |
|    |                           |to a common physical link. |          |
|    |                           |   Common physical links   |          |
|    |                           |e.g., Ethernet, IEEE 1394, |          |
|    |                           |Satellite transponders can |          |
|    |                           |    have more than one     |          |
|    |                           | MPEG-2 transport stream.  |          |
|    |                           |So the implication that the|          |
|    |                           |   TS Logical Channel ID   |          |
|    |                           |  is unique to a physical  |          |
|    |                           |link is incorrect. The last|          |
|    |                           |      sentence in the      |          |
|    |                           | definition is not wrong,  |          |
|    |                           |but is not complete either.|          |
|    |                           |  The same PID value can   |          |
|    |                           |  identify MPEG-2 packets  |          |
|    |                           |  with totally unrelated   |          |
|    |                           |  content in different TS  |          |
|    |                           |       MULTIPLEXes.        |          |
+----+---------------------------+---------------------------+----------+
| 15 |  P11   Raised during WGLC |   Asserting that ULE is   |Raised by |
|    |Sect 3                     |   limited to TS private   |    AA    |
|    |                           |       streams seems       | msg00867 |
|    |                           |underspecified. What is the|          |
|    |                           | means of identifying that |          |
|    |                           |   this private use of a   |          |
|    |                           |    particular private     |          |
|    |                           | stream_type is different  |          |
|    |                           | from another's use of the |          |
|    |                           |           same            |          |
|    |                           |   stream_type?  It is a   |          |
|    |                           |choice for the draft to be |          |
|    |                           |silent on how the PID value|          |
|    |                           |  with these datagrams is  |          |
|    |                           | found, but is seems that  |          |
|    |                           | use of the MRD should be  |          |
|    |                           | required in the PMT loop  |          |
|    |                           |   that has the private    |          |
|    |                           | stream_type used by ULE.  |          |
|    |                           |            All            |          |
|    |                           |programs must be listed per|          |
|    |                           |13818-1, but that standard |          |
|    |                           |   is silent on conflict   |          |
|    |                           | resolution among private  |          |
|    |                           |          users.           |          |
+----+---------------------------+---------------------------+----------+
| 16 |  p12   Raised during WGLC |4th para. It is interesting|Raised by |
|    |Sect 3                     |that this receiver behavior|    AA    |
|    |                           | is believed to be known.  | msg00867 |
|    |                           |  Particularly since the   |          |
|    |                           |value 0xFF for table_id is |          |
|    |                           |  expressly forbidden by   |          |
|    |                           |   ISO-MPEG. The meaning   |          |
|    |                           | asserted is simply wrong. |          |
|    |                           |Padding (bytes of 0xFF) may|          |
|    |                           |occur in TS packets when a |          |
|    |                           |      table section's      |          |
|    |                           |content ends before the end|          |
|    |                           |of the TS packet. When they|          |
|    |                           |    occur the following    |          |
|    |                           |  statements are correct.  |          |
+----+---------------------------+---------------------------+----------+
| 17 |  p12   Raised during WGLC |  last para. The use and   |Raised by |
|    |Sect 4                     |meaning of adaptation field|    AA    |
|    |                           |       is completely       | msg00867 |
|    |                           | defined by ISO-MPEG. The  |          |
|    |                           | assertion of its primary  |          |
|    |                           |  purpose does not appear  |          |
|    |                           | relevant or needed and I  |          |
|    |                           | would not agree with the  |          |
|    |                           |   word 'primary' . The    |          |
|    |                           |assertion that values of 00|          |
|    |                           |     are discarded is      |          |
|    |                           | interesting, and I would  |          |
|    |                           |agree with the speculation |          |
|    |                           |that they should be ignored|          |
|    |                           | and discard the packets.  |          |
|    |                           |   The value '00' is not   |          |
|    |                           |  available for use, and   |          |
|    |                           |discussion of anything but |          |
|    |                           | the requirement that the  |          |
|    |                           | value 01 is required here |          |
|    |                           |      seems unneeded.      |          |
+----+---------------------------+---------------------------+----------+
| 18 |  p12   Raised during WGLC |The sentence "Each SNDU is |Raised by |
|    |Sect 4                     | sent as a MPEG-2 Payload  |    AA    |
|    |                           | Unit." can be expanded to | msg00867 |
|    |                           |read '"Each Subnetwork Date|          |
|    |                           | Unit is sent as a MPEG-2  |          |
|    |                           |Payload Unit." But Payload |          |
|    |                           |  Unit is a defined term   |          |
|    |                           | here, meaning a sequence  |          |
|    |                           | of bytes sent using a TS. |          |
|    |                           | So all this sentence says |          |
|    |                           |    is each sequence of    |          |
|    |                           |bytes is sent as a sequence|          |
|    |                           | of bytes.  Was something  |          |
|    |                           |    more intended?   It    |          |
|    |                           | would seem that the order |          |
|    |                           | of the bits in each byte  |          |
|    |                           |  should be specified as   |          |
|    |                           |    well. MSBit first?     |          |
+----+---------------------------+---------------------------+----------+
| 19 | 12-13  Raised during WGLC | The D field is shown as a |Raised by |
|    | Sect                      |     separate field in     |    AA    |
|    | 4.1 &                     |figure 1 and then described| msg00867 |
|    |  4.2                      |as part of the Length field|          |
|    |                           |   in the text. One can    |          |
|    |                           |  deduce that the length   |          |
|    |                           |field bits are sent divided|          |
|    |                           |  over two bytes and that  |          |
|    |                           |the first byte has one bit |          |
|    |                           | that is unrelated to the  |          |
|    |                           |  length,  but the field   |          |
|    |                           |is not explicitly defined. |          |
|    |                           |The MSbyte is the one that |          |
|    |                           |   has a bit that means    |          |
|    |                           |    Destination Address    |          |
|    |                           |  present, and it is the   |          |
|    |                           |first bit sent? The MSB of |          |
|    |                           | the length field follows  |          |
|    |                           |    the D bit? Clarify.    |          |
+----+---------------------------+---------------------------+----------+
| 20 |  4.4   Raised during WGLC |  Define bit order of the  |Raised by |
|    |                           |    bytes in the field     |    AA    |
|    |                           |                           | msg00867 |
+----+---------------------------+---------------------------+----------+
| 21 |  4.5   Raised during WGLC |I don't see the location of|Raised by |
|    |                           |   this filed. Does the    |    AA    |
|    |                           | destination address field | msg00867 |
|    |                           |arrive just before the CRC?|          |
|    |                           |Section 4.1 says the D must|          |
|    |                           |be set to 0, unless an End |          |
|    |                           |indicator, yet this section|          |
|    |                           |says is 1 may be used for a|          |
|    |                           |     non End Indicator     |          |
|    |                           | situation. These sections |          |
|    |                           |need to be made consistent.|          |
|    |                           |  What is the non-default  |          |
|    |                           |situation and when can that|          |
|    |                           |   be used? Why say "by    |          |
|    |                           | default" in section 4.1?  |          |
|    |                           |  The situations for not   |          |
|    |                           |using the default should be|          |
|    |                           |   stated, if any exist.   |          |
+----+---------------------------+---------------------------+----------+
| 22 |  4.6   Raised during WGLC |      "...represented      |Raised by |
|    |                           | 0x104C11DB7..." is opaque |    AA    |
|    |                           |    in meaning. What is    | msg00867 |
|    |                           |  the ref for translating  |          |
|    |                           |this and what does it mean?|          |
+----+---------------------------+---------------------------+----------+
| 23 |  4.7   Raised during WGLC |is this a receiver behavior|Raised by |
|    |                           |spec section rather than a |    AA    |
|    |                           |   description of format   | msg00867 |
|    |                           | section ( as it seems to  |          |
|    |                           | be)? The format meanings  |          |
|    |                           |  were already specified   |          |
|    |                           | using slightly different  |          |
|    |                           |          words.           |          |
+----+---------------------------+---------------------------+----------+