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 |> |> | |> |> | |> |> |> |> |> | |> | |> | |> |> | | |
- RE: [Technical Errata Reported] RFC5458 (1746) H.Cruickshank
- RE: [Technical Errata Reported] RFC5458 (1746) Allison, Art
- Re: [Technical Errata Reported] RFC5458 (1746) Gorry Fairhurst
- RE: [Technical Errata Reported] RFC5458 (1746) Allison, Art
- Re: [Technical Errata Reported] RFC5458 (1746) Gorry Fairhurst
- RE: [Technical Errata Reported] RFC5458 (1746) H.Cruickshank
- RE: [Technical Errata Reported] RFC5458 (1746) Allison, Art
- Re: [Technical Errata Reported] RFC5458 (1746) Gorry Fairhurst
- Re: [Technical Errata Reported] RFC5458 (1746) Marie-Jose Montpetit