[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Technical Errata Reported] RFC5458 (1746)

To: <ipdvb@erg.abdn.ac.uk>
Subject: RE: [Technical Errata Reported] RFC5458 (1746)
From: "Allison, Art" <AAllison@nab.org>
Date: Wed, 29 Apr 2009 13:16:08 -0400
In-reply-to: <>
References: <> <>
Reply-to: ipdvb@erg.abdn.ac.uk
Sender: owner-ipdvb@erg.abdn.ac.uk
Thread-index: AcnI4dLxcPD4go+ASzO49Tu77xchhQAB0zawAAEbKnA=
Thread-topic: [Technical Errata Reported] RFC5458 (1746)
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: owner-ipdvb@erg.abdn.ac.uk 
|[mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of 
|H.Cruickshank@surrey.ac.uk
|Sent: Wednesday, April 29, 2009 12:40 PM
|To: ipdvb@erg.abdn.ac.uk
|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: +44 1483 686007 (indirect 689844)
|Fax: +44 1483 686011
|e-mail: H.Cruickshank@surrey.ac.uk
|http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ 
|
|-----Original Message-----
|From: owner-ipdvb@erg.abdn.ac.uk 
|[mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst
|Sent: 29 April 2009 15:50
|To: ipdvb@erg.abdn.ac.uk
|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  202 429 5418
|> Fax  202 775 4981
|> www.nab.org
|> 
|> Advocacy  Education  Innovation
|> 
|> 
|> 
|> 
|> |-----Original Message-----
|> |From: owner-ipdvb@erg.abdn.ac.uk
|> |[mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst
|> |Sent: Wednesday, April 29, 2009 2:46 AM
|> |To: ipdvb@erg.abdn.ac.uk
|> |Cc: rfc-editor@rfc-editor.org; p.pillai@Bradford.ac.uk; 
|> |mnoist@cosy.sbg.ac.at; sunil.iyengar@logica.com; rdroms@cisco.com; 
|> |jari.arkko@piuha.net; ah@TR-Sys.de
|> |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  202 429 5418
|> |> Fax  202 775 4981
|> |> www.nab.org
|> |> 
|> |> Advocacy  Education  Innovation
|> |> 
|> |> 
|> |>   
|> |> 
|> |> 
|> |> 
|> |> |-----Original Message-----
|> |> |From: owner-ipdvb@erg.abdn.ac.uk
|> |> |[mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of 
|> |> |H.Cruickshank@surrey.ac.uk
|> |> |Sent: Tuesday, April 07, 2009 11:47 AM
|> |> |To: rfc-editor@rfc-editor.org; p.pillai@Bradford.ac.uk; 
|> |> |mnoist@cosy.sbg.ac.at; sunil.iyengar@logica.com; 
|rdroms@cisco.com;
|
|> |> |jari.arkko@piuha.net; townsley@cisco.com; gorry@erg.abdn.ac.uk
|> |> |Cc: ah@TR-Sys.de; ipdvb@erg.abdn.ac.uk
|> |> |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: +44 1483 686007 (indirect 689844)
|> |> |Fax: +44 1483 686011
|> |> |e-mail: H.Cruickshank@surrey.ac.uk 
|> |> |http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
|> |> |
|> |> |-----Original Message-----
|> |> |From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
|> |> |Sent: 30 March 2009 08:25
|> |> |To: Cruickshank HS Dr (CCSR); p.pillai@bradford.ac.uk; 
|> |> |mnoist@cosy.sbg.ac.at; sunil.iyengar@logica.com; 
|rdroms@cisco.com;
|
|> |> |jari.arkko@piuha.net; townsley@cisco.com; gorry@erg.abdn.ac.uk
|> |> |Cc: ah@TR-Sys.de; ipdvb@erg.abdn.ac.uk; rfc-editor@rfc-editor.org
|> |> |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 <ah@TR-Sys.de>
|> |> |
|> |> |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
|> |> |
|> |> |
|> |> 
|> |> 
|> |
|> |
|> |
|> 
|> 
|
|
|
Follow-Ups:
- Re: [Technical Errata Reported] RFC5458 (1746)
  - From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
References:
- Re: [Technical Errata Reported] RFC5458 (1746)
  - From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
- RE: [Technical Errata Reported] RFC5458 (1746)
  - From: <H.Cruickshank@surrey.ac.uk>
Prev by Date: RE: [Technical Errata Reported] RFC5458 (1746)
Next by Date: Re: [Technical Errata Reported] RFC5458 (1746)
Previous by thread: RE: [Technical Errata Reported] RFC5458 (1746)
Next by thread: Re: [Technical Errata Reported] RFC5458 (1746)
Index(es):
- Date
- Thread