+----+---------------------------+---------------------------+ | | ULE-Spec 03 | WGLC Issues, | | | | updated 17th Jan 2004 | +----+---------------------------+---------------------------+ |Iss |Section Status | Description | | | | | +----+---------------------------+---------------------------+ | 1 | 5 Raised during WGLC | The text says: "a 5-bit | | |fig. 10 - diagram Changed | zero prefix and a 3-bit | | | | H-Len field", but the | | | | figure | | | |shows 4 bits zero and thus | | | | suggests 4 bit for H-Len. | +----+---------------------------+---------------------------+ | 2 | 4.7 Raised during WGLC |"Next Header Type Fields": | | | - Moved to Sect 5 |When considering extension | | | - NOTE: Padding is |headers, type field values | | | an OPTIONAL | of 0x0000 (TEST SNDU), | | | 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 | | | Text added to section 5 | decode as a 2 bytes long | | | to describe the format | optional extension | | | and strcuture of the |header, which is obviously | | | extension length field. | not as intended. | +----+---------------------------+---------------------------+ | 4 | 4.5 Raised during WGLC | "SNDU Destination Address | | | - | Field": | | | | If extension headers are | | | Figure 8 changed to | used in combination with | | | 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 | | | Text ammended to |after the SNDU header (thus| | | state the NPA |occupying bytes 5 to 10 of | | | address follows the | the SNDU). For | | | 4th byte of the ULE | ease of processing and | | | header. | 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 | VLANs are a | Bridging VLAN frames: | | | standard IEEE type, |There is a note in section | | | this use is | 4.7.5, after figure 9, | | | therfore covered | stating that a | | | by existing | bridged SNDU could convey | | | reference to the |an 802.3 Ethernet frame (as| | | IEEE/IANA | opposed to | | | Ethertype. |the examples (fig. 8, fig. | | | | 9) containing an LLC/SNAP | | | No specific changes | encapsulation. | | | are required. | 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 | | |Fig 12 This diagram was | clear guidance on the | | | changed 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. | | | See also (4) | | +----+---------------------------+---------------------------+ | 7 | 4.7.5 Changed. | Bridge Frame SNDU | | | Fig 8 | Encapsulation | | | | - "Receiver Destination | | | | Address" should be marked | | | | as "NPA Address" | +----+---------------------------+---------------------------+ | 8 |Definit Definitions |Broad issue - if the term | | | ions changed in line |being defined is in all | | | with suggestion. |caps, should not it be in | | | There was no |all caps when that defined | | | intention to |term is used? Or a rule | | | modify ISO 13818 |that only initial caps | | | behaviour. |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 Ref will be |Quick scan - Need work on | | | updated. |MPEG term usage; Section 7 | | | |scoping; Refs should be | | | |updated from source web | | | |sited just b4 publications | | | |(A/53 is now A/53C, for | | | |example) | +----+---------------------------+---------------------------+ | 10 |Definti New text proposed |@PRIVATE SECTION. While | | | ons for the section |the use listed is one use, | | | p10 defining these |use of private sections | | | terms. |is NOT constrained to only | | | |service information. It may| | | This is a |be used for any | | | terminology issue, |Program data. It is not | | | the operation of the|accurate to assert that all| | | protocol, but is |table sections must be | | | important to ensure |carried over a single TS | | | clear interpretation|Logical Channel. Further | | | of the ISO 13818 |attempting to assert the | | | standard |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 New text proposed |TABLE SECTION. Table| | | ons for the section |sections are used for many| | | p10 defining these |purposes beside MPEG-2 | | | terms. |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 Definition added. | missing PDU definition. | | | ons | | | | p10 | | +----+---------------------------+---------------------------+ | 13 |Definti This was the | TS LOGICAL CHANNEL: Add | | | ons intended meaning, | 'unique' to: "...All | | | p10 text was ammended. | packets sent over a | | | | 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 |Definti New text proposed |TS MULTIPLEX: Defining | | | ons for the section |a TS MULTIPLEX in terms of | | | p10 defining a | the set of TS | | | multiplex - the | logical channels is an | | | new text also |interesting way to view it,| | | covers the case | but as there is an | | | where MPEG2TS is | internationally approved | | | over RTP - as in |standard it would seem best| | | IETF AVT WG. | 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 The comment is | Asserting that ULE is | | |Sect 3 correct, further | limited to TS private | | | standards work | streams seems | | | will be required |underspecified. What is the| | | to define | means of identifying that | | | descriptors for | this private use of a | | | the ULE stream | particular private | | | when used within a | stream_type is different | | | TV Multiplex. This | from another's use of the | | | work needs to be | same | | | done within DVB, | stream_type? It is a | | | ATSC, etc - and is |choice for the draft to be | | | not one that can |silent on how the PID value| | | be specified by | with these datagrams is | | | the IETF. | 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 New text is |4th para. It is interesting| | |Sect 3 proposed, this |that this receiver behavior| | | impacts the wording | is believed to be known. | | | of teh section, but | Particularly since the | | | not the protocol |value 0xFF for table_id is | | | sepc itself. | 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 Issue was correct | last para. The use and | | |Sect 4 the description in |meaning of adaptation field| | | the draft appears | is completely | | | to mandate a | defined by ISO-MPEG. The | | | behaviour to an | assertion of its primary | | | ISO-reserved field. | purpose does not appear | | | The sentence has | relevant or needed and I | | | been removed, | would not agree with the | | | without chnage to | word 'primary' . The | | | the ULE protocol. |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 Wording changed. |The sentence "Each SNDU is | | |Sect 4 | sent as a MPEG-2 Payload | | | | Unit." can be expanded to | | | |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 | | | Internet byte order | more intended? It | | | was sepcified, but | would seem that the order | | | the but-order has | of the bits in each byte | | | been added. | should be specified as | | | | well. MSBit first? | +----+---------------------------+---------------------------+ | 19 | 12-13 Text changed in | The D field is shown as a | | | Sect several places to | separate field in | | | 4.1 & clarify that this |figure 1 and then described| | | 4.2 is a separate |as part of the Length field| | | 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 See (18) | Define bit order of the | | | | bytes in the field | | | | | +----+---------------------------+---------------------------+ | 21 | 4.5 Text changed and |I don't see the location of| | | diagram modified | this filed. Does the | | | (4) to clarify | destination address field | | | this. |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 This is an alternate| "...represented | | | way of specification| 0x104C11DB7..." is opaque | | | of the polynomial | in meaning. What is | | | terms. Current text | the ref for translating | | | seems clear. |this and what does it mean?| +----+---------------------------+---------------------------+ | 23 | 4.7 This observation is |is this a receiver behavior| | | correct, and the |spec section rather than a | | | description | description of format | | | consistent with the | section ( as it seems to | | | sender behaviour. | be)? The format meanings | | | | were already specified | | | | using slightly different | | | | words. | +----+---------------------------+---------------------------+ | 24 |ToC ToC updated to | ToC is out of date. | | | match the section | | | | titles. | | | | | | +----+---------------------------+---------------------------+ | 25 | 4.7 Other formats may be | | | | defined through | The extensions text | | | relevant assignments | anticipates new | | | in the IEEE and IANA | extension header. | | | registries. | Last para unclear. | | | | | +----+---------------------------+---------------------------+