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
|> |> |
|> |> |
|> |> |> |> |> |
|> |
|> |
|> |> |
|
|