[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Completion of ULE WGLC -03
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. | |
+----+---------------------------+---------------------------+----------+