Re: [Technical Errata Reported] RFC5458 (1746)

[Gorry Fairhurst <[e-mail]>]

[Sent not as WG chair]: I personally find it hard to see that this 
impacts implementation and interoperability, because this is a 
requirements spec. The term is defined already in RFC 4326.

[As WG Chair]: I would appreciate other working group feedback if other 
people have comments on this issue. Working Group members, please send 
feedback to the list, and we shall judge consensus by 5th May 2009.

Gorry

Allison, Art wrote:
> OK, if it is outside IETF process to have an errata that says " the line
> ...."  is not accurate and should read  " ..." in order to be accurate;
> then so be it.
> While I assert the line is technically in error; I agree it is
> informative and therefore may only cause some confusion by an
> implementation and should, not lead to an implementation error. 
> 
> Art
> |-----Original Message-----
> |From: [e-mail] 
> |[mailto:[e-mail]] On Behalf Of 
> |[e-mail]
> |Sent: Wednesday, April 29, 2009 12:40 PM
> |To: [e-mail]
> |Subject: RE: [Technical Errata Reported] RFC5458 (1746)
> |
> |
> | I agree with Gorry's suggestion.
> |Haitham
> |
> |
> |----
> |Dr. Haitham S. Cruickshank
> |Lecturer
> |Communications Centre for Communication Systems Research 
> |(CCSR) BA Building, Room E11 School of Electronics, Computing 
> |and Mathematics University of Surrey, Guildford, UK, GU2 7XH 
> | 
> |Tel: [phone] (indirect 689844)
> |Fax: [phone]
> |e-mail: [e-mail]
> |http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ 
> |
> |-----Original Message-----
> |From: [e-mail] 
> |[mailto:[e-mail]] On Behalf Of Gorry Fairhurst
> |Sent: 29 April 2009 15:50
> |To: [e-mail]
> |Subject: Re: [Technical Errata Reported] RFC5458 (1746)
> |
> |Noted, but it is not possible to delete lines from an RFC, we 
> |can make a public Errata statement if the protocol has a 
> |significant error or there is an ambiguity that will lead to 
> |implementation error, etc. Or we can make a note in the 
> |document database, that will be used when a new RFC is issued 
> |to replace this one. I suggested the latter.
> |
> |Gorry
> |
> |
> |Allison, Art wrote:
> |> The definition using the undefined term is "TS: Transport Stream
> |> [ISO-MPEG2]."   A method of 
> |> transmission at the MPEG-2 layer using TS Packets; it 
> |represents Layer
> |
> |> 2 of the ISO/OSI reference model.  See also TS Logical 
> |Channel and TS 
> |> Multiplex."
> |> 
> |> Fixing this error by defining the term "TS logical channel' 
> |is indeed 
> |> difficult, but as it was only introduces as one of two 'see also'
> |> references, fixing the definition by deletion seems 
> |appropriate as the
> |
> |> 'see also' only misleads.
> |> So, I suggest the last sentence be changed to read "See also TS 
> |> Multiplex."
> |> 
> |> This would remove the reference to an undefined term, and thereby 
> |> resolve the documentation issue.
> |> 
> |> Art
> |> Art Allison
> |> 
> |> Senior Director Advanced Engineering, Science and Technology
> |>  
> |> National Association of Broadcasters
> |> 1771 N Street NW
> |> Washington, DC 20036
> |> Phone  [phone]
> |> Fax  [phone]
> |> www.nab.org
> |> 
> |> Advocacy  Education  Innovation
> |> 
> |> 
> |> 
> |> 
> |> |-----Original Message-----
> |> |From: [e-mail]
> |> |[mailto:[e-mail]] On Behalf Of Gorry Fairhurst
> |> |Sent: Wednesday, April 29, 2009 2:46 AM
> |> |To: [e-mail]
> |> |Cc: [e-mail]; [e-mail]; 
> |> |[e-mail]; [e-mail]; [e-mail]; 
> |> |[e-mail]; [e-mail]
> |> |Subject: Re: [Technical Errata Reported] RFC5458 (1746)
> |> |
> |> |After looking at this reported Errata, I suggest there does 
> |seems to 
> |> |be a valid issue to note. My thoughts are that the term 'TS logical 
> |> |channel' has been used to describe a component of the TS multiplex, 
> |> |carried as an elementary stream
> |> |(ES) over a MPEG-2 TS. This term was used to differentiate it from 
> |> |the term "stream" which is widely used in other IETF specs to 
> |> |describe something different. It is not a peer of 'TS multiplex'.
> |> |
> |> |Given the term is already defined in other RFCs that are cited, I 
> |> |suggest this is not likely to result in implementation errors in 
> |> |future protocols.  I suggest the WG categorise this as "Hold for 
> |> |Document Update" - i.e. a future update of the document should 
> |> |consider this erratum when making the update.
> |> |
> |> |If anyone would like to add further comments, please send 
> |them to the
> |
> |> |list by 5th May 2009. After this date we will inform the 
> |RFC-Ed of a 
> |> |decision.
> |> |
> |> |Best wishes,
> |> |
> |> |Gorry Fairhurst
> |> |IPDVB Chair
> |> |
> |> |Allison, Art wrote:
> |> |> It is simply dead wrong to use TS logical channel in relation to 
> |> |> defining a Transport Stream.
> |> |> The errata should delete the term TS logical  channel, not define 
> |> |> it as it only misleads and propagates misunderstanding.
> |> |> 
> |> |> The term 'TS logical channel'  is not a peer of 'TS
> |> |multiplex', it is
> |> |> a component of the TS multiplex.
> |> |> 
> |> |> A MPEG-2 Transport Stream is a multiplex consisting of a
> |> |collection of
> |> |> elementary streams in 188-byte packets each stream having 
> |a Packet 
> |> |> IDentifier (PID).
> |> |> 
> |> |> I attempted to inform authors of RFC4326 of the poor construction 
> |> |> at the time, but the inventors of the term had more time and
> |> |used it very
> |> |> very narrowly so it was no longer dead wrong use, at 
> |which point my
> |
> |> |> budget to support this work was exhausted.
> |> |>  
> |> |> I do have time to educate and advocate better resolution of this 
> |> |> errata; but for accurate usage of PID and transport stream
> |> |see ISO/ITU
> |> |> 13818-1, not later attempts to 'clarify' those terms by those not 
> |> |> expert in
> |> |> MPEG-2 Systems. 
> |> |> 
> |> |> Art
> |> |> Art Allison
> |> |> 
> |> |> Director Advanced Engineering, Science and Technology
> |> |>  
> |> |> National Association of Broadcasters
> |> |> 1771 N Street NW
> |> |> Washington, DC 20036
> |> |> Phone  [phone]
> |> |> Fax  [phone]
> |> |> www.nab.org
> |> |> 
> |> |> Advocacy  Education  Innovation
> |> |> 
> |> |> 
> |> |>   
> |> |> 
> |> |> 
> |> |> 
> |> |> |-----Original Message-----
> |> |> |From: [e-mail]
> |> |> |[mailto:[e-mail]] On Behalf Of 
> |> |> |[e-mail]
> |> |> |Sent: Tuesday, April 07, 2009 11:47 AM
> |> |> |To: [e-mail]; [e-mail]; 
> |> |> |[e-mail]; [e-mail]; 
> |[e-mail];
> |
> |> |> |[e-mail]; [e-mail]; [e-mail]
> |> |> |Cc: [e-mail]; [e-mail]
> |> |> |Subject: RE: [Technical Errata Reported] RFC5458 (1746)
> |> |> |
> |> |> |
> |> |> | Hi again,
> |> |> |
> |> |> |I suggest to add the the TS Logical Channel definition 
> |(taken from
> |
> |> |> |RFC 4326). So here is the proposed text:
> |> |> |
> |> |> |*********************************************
> |> |> |
> |> |> |TS Logical Channel: Transport Stream Logical Channel. In this 
> |> |> |document, this term identifies a channel at the MPEG-2 level 
> |> |> |[ISO-MPEG2]. It exists at level 2 of the ISO/OSI reference
> |> |model. All
> |> |> |packets sent over a TS Logical Channel carry the same PID
> |> |value (this
> |> |> |value is unique within a specific TS Multiplex). The term
> |> |"Stream" is
> |> |> |defined in MPEG-2 [ISO-MPEG2] to describe the content 
> |carried by a
> |
> |> |> |specific TS Logical Channel (see ULE Stream). Some PID 
> |values are 
> |> |> |reserved (by
> |> |> |MPEG-2) for specific signalling. Other standards (e.g., ATSC,
> |> |> |DVB) also reserve specific PID values.
> |> |> |
> |> |> |**********************************************
> |> |> |
> |> |> |
> |> |> |----
> |> |> |Dr. Haitham S. Cruickshank
> |> |> |Lecturer
> |> |> |Communications Centre for Communication Systems Research
> |> |> |(CCSR) BA Building, Room E11 School of Electronics, 
> |Computing and 
> |> |> |Mathematics University of Surrey, Guildford, UK, GU2 7XH
> |> |> | 
> |> |> |Tel: [phone] (indirect 689844)
> |> |> |Fax: [phone]
> |> |> |e-mail: [e-mail] 
> |> |> |http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
> |> |> |
> |> |> |-----Original Message-----
> |> |> |From: RFC Errata System [mailto:[e-mail]]
> |> |> |Sent: 30 March 2009 08:25
> |> |> |To: Cruickshank HS Dr (CCSR); [e-mail]; 
> |> |> |[e-mail]; [e-mail]; 
> |[e-mail];
> |
> |> |> |[e-mail]; [e-mail]; [e-mail]
> |> |> |Cc: [e-mail]; [e-mail]; [e-mail]
> |> |> |Subject: [Technical Errata Reported] RFC5458 (1746)
> |> |> |
> |> |> |
> |> |> |The following errata report has been submitted for RFC5458,
> |> |"Security
> |> |> |Requirements for the Unidirectional Lightweight Encapsulation
> |> |> |(ULE) Protocol".
> |> |> |
> |> |> |--------------------------------------
> |> |> |You may review the report below and at:
> |> |> |http://www.rfc-editor.org/errata_search.php?rfc=5458&eid=1746
> |> |> |
> |> |> |--------------------------------------
> |> |> |Type: Technical
> |> |> |Reported by: Alfred Hoenes <[e-mail]>
> |> |> |
> |> |> |Section: 2
> |> |> |
> |> |> |Original Text
> |> |> |-------------
> |> |> |[[ at the bottom of page 5 / top of page 6 ]]
> |> |> |
> |> |> |   TS: Transport Stream [ISO-MPEG2].  A method of
> |> |transmission at the
> |> |> |   MPEG-2 layer using TS Packets; it represents Layer 2 of
> |> |the ISO/OSI
> |> |> |   reference model.  See also TS Logical Channel and TS 
> |Multiplex.
> |> |> |                              ^^^^^^^^^^^^^^^^^^^^^^^
> |> |> |
> |> |> |<< page break >>
> |> |> |
> |> |> |   TS Multiplex: In this document, ...
> |> |> |
> |> |> |
> |> |> |
> |> |> |Corrected Text
> |> |> |--------------
> |> |> |   TS: Transport Stream [ISO-MPEG2].  A method of
> |> |transmission at the
> |> |> |   MPEG-2 layer using TS Packets; it represents Layer 2 of
> |> |the ISO/OSI
> |> |> |   reference model.  See also TS Logical Channel and TS 
> |Multiplex.
> |> |> ||
> |> |> ||  TS Logical Channel: ...   << to be filled in >>
> |> |> ||  ...
> |> |> |
> |> |> |   TS Multiplex: In this document, ...
> |> |> |
> |> |> |
> |> |> |
> |> |> |
> |> |> |Notes
> |> |> |-----
> |> |> |The quoted keyword explanation for "TS Logical Channel" 
> |> |> |is missing in Section 2.
> |> |> |
> |> |> |Authors/Verifiers:
> |> |> |  Please restore the entry and fill in the missing 
> |Corrected Text.
> |> |> |
> |> |> |Instructions:
> |> |> |-------------
> |> |> |This errata is currently posted as "Reported". If
> |> |necessary, please use
> |> |> |"Reply All" to discuss whether it should be verified or 
> |rejected. 
> |> |> |When a decision is reached, the verifying party (IESG) 
> |can log in 
> |> |> |to change the status and edit the report, if necessary.
> |> |> |
> |> |> |--------------------------------------
> |> |> |RFC5458 (draft-ietf-ipdvb-sec-req-09)
> |> |> |--------------------------------------
> |> |> |Title               : Security Requirements for the 
> |Unidirectional
> |> |> |Lightweight Encapsulation (ULE) Protocol
> |> |> |Publication Date    : March 2009
> |> |> |Author(s)           : H. Cruickshank, P. Pillai, M. 
> |Noisternig, S.
> |> |> |Iyengar
> |> |> |Category            : INFORMATIONAL
> |> |> |Source              : IP over DVB
> |> |> |Area                : Internet
> |> |> |Stream              : IETF
> |> |> |Verifying Party     : IESG
> |> |> |
> |> |> |
> |> |> 
> |> |> 
> |> |
> |> |
> |> |
> |> 
> |> 
> |
> |
> |
> 
> 


-- 
Dr Gorry Fairhurst, School of Engineering, University of Aberdeen.
The University of Aberdeen is a charity registered in Scotland,
No SC013683.