RE: [Technical Errata Reported] RFC5458 (1746)

"Allison, Art" <AAllison@nab.org> Wed, 29 April 2009 17:40 UTC

Return-Path: <owner-ipdvb@erg.abdn.ac.uk>
X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com
Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C867C28C2D2 for <ietfarch-ipdvb-archive@core3.amsl.com>; Wed, 29 Apr 2009 10:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_STOP=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-ttgQv+q6EM for <ietfarch-ipdvb-archive@core3.amsl.com>; Wed, 29 Apr 2009 10:40:30 -0700 (PDT)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id DB23F28C2CE for <ipdvb-archive@ietf.org>; Wed, 29 Apr 2009 10:40:28 -0700 (PDT)
Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n3THHRK9019499 for <ipdvb-subscribed-users@dee.erg.abdn.ac.uk>; Wed, 29 Apr 2009 18:17:27 +0100 (BST)
Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id n3THHR2Q019498 for ipdvb-subscribed-users; Wed, 29 Apr 2009 18:17:27 +0100 (BST)
X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f
Received: from chip2og55.obsmtp.com (chip2og55.obsmtp.com [64.18.13.47]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id n3THGxcZ019479 for <ipdvb@erg.abdn.ac.uk>; Wed, 29 Apr 2009 18:16:59 +0100 (BST)
Received: from source ([63.210.44.41]) by chip2ob55.postini.com ([64.18.5.12]) with SMTP ID DSNKSfiLiwqK48a9FmKUFYkf6dezYiOu6e0H@postini.com; Wed, 29 Apr 2009 10:17:00 PDT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Technical Errata Reported] RFC5458 (1746)
Date: Wed, 29 Apr 2009 13:16:08 -0400
Message-ID: <71C9EC0544D1F64D8B7D91EDCC6220200320E738@NABSREX027324.NAB.ORG>
In-reply-to: <225B6337E699484095DA8EE02A5063B5798D2C@EVS-EC1-NODE1.surrey.ac.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Technical Errata Reported] RFC5458 (1746)
Thread-Index: AcnI4dLxcPD4go+ASzO49Tu77xchhQAB0zawAAEbKnA=
References: <49F86931.8080508@erg.abdn.ac.uk> <225B6337E699484095DA8EE02A5063B5798D2C@EVS-EC1-NODE1.surrey.ac.uk>
From: "Allison, Art" <AAllison@nab.org>
To: <ipdvb@erg.abdn.ac.uk>
X-ERG-MailScanner: Found to be clean, Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id n3THHRkT019495
Sender: owner-ipdvb@erg.abdn.ac.uk
Precedence: bulk
Reply-To: ipdvb@erg.abdn.ac.uk
X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk

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