[mpls] R: [Technical Errata Reported] RFC5960 (2533)
"BUSI, ITALO (ITALO)" <italo.busi@alcatel-lucent.com> Fri, 29 October 2010 07:09 UTC
Return-Path: <italo.busi@alcatel-lucent.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11ECE3A6A0B for <mpls@core3.amsl.com>; Fri, 29 Oct 2010 00:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.294
X-Spam-Level:
X-Spam-Status: No, score=-5.294 tagged_above=-999 required=5 tests=[AWL=0.955, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 bDYluMEn7MKD for <mpls@core3.amsl.com>; Fri, 29 Oct 2010 00:09:15 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 5FEC63A6A09 for <mpls@ietf.org>; Fri, 29 Oct 2010 00:09:15 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9T797a9018959 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Oct 2010 09:10:45 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 29 Oct 2010 09:10:38 +0200
From: "BUSI, ITALO (ITALO)" <italo.busi@alcatel-lucent.com>
To: "stbryant@cisco.com" <stbryant@cisco.com>, Benjamin Niven-Jenkins <ben@niven-jenkins.co.uk>
Date: Fri, 29 Oct 2010 09:10:35 +0200
Thread-Topic: [mpls] [Technical Errata Reported] RFC5960 (2533)
Thread-Index: ActmIC64yWOBqfEEQ6aXBOp1o/fpLQRF6zrQ
Message-ID: <15740615FC9674499FBCE797B011623F105FBB7A@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
References: <20100929173931.1B2F0E06C4@rfc-editor.org> <38C5A032-A518-4CFA-B387-CE6F9BF01F6C@niven-jenkins.co.uk> <4CADC554.6040307@cisco.com>
In-Reply-To: <4CADC554.6040307@cisco.com>
Accept-Language: it-IT, en-US
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: it-IT, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
Cc: "ahmpls-tp@lists.itu.int" <ahmpls-tp@lists.itu.int>, "mpls@ietf.org" <mpls@ietf.org>, "danfrost@cisco.com" <danfrost@cisco.com>, "adrian.farrel@huawei.com" <adrian.farrel@huawei.com>, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: [mpls] R: [Technical Errata Reported] RFC5960 (2533)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2010 07:09:17 -0000
Stewart, As you actively contributed to and agree with the ITU-T LS proposing the change during the last ITU-T meeting (with claims implying that these were very minor changes the editors could have easily made to the document even if it were in the RFC Editor Queue), could you please clarify what has changed from June 2010 to now to cause your view to change? Thanks, Italo > -----Messaggio originale----- > Da: Stewart Bryant [mailto:stbryant@cisco.com] > Inviato: giovedì 7 ottobre 2010 15.04 > A: Benjamin Niven-Jenkins > Cc: RFC Errata System; danfrost@cisco.com; Bocci, Matthew (Matthew); > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu; mpls@ietf.org; > BUSI, ITALO (ITALO) > Oggetto: Re: [mpls] [Technical Errata Reported] RFC5960 (2533) > > Speaking as an author, my view is that the original text is correct, > and the correction is not needed. > > It's a fundamental of the IP protocol suite (which includes MPLS) that > the parser knows what protocol to expect from the previous header or if > there is no previous header from an identifier in the lower layer. > > Indeed the "correction" makes an additional statement, but I don't think > that is needed because it's an implication of the existing text. > > - Stewart > > > > On 30/09/2010 01:18, Benjamin Niven-Jenkins wrote: > > While the intent of reported errata is technically correct I'm somewhat > torn between whether I think it should be rejected, or whether I don't > care. > > > > My thinking is: > > > > The errata is technically correct because a corner case does exist where > a section layer that doesn't support higher layer protocol multiplexing > can still be used to support MPLS-TP in some scenarios. > > > > I don't like the proposed replacement text because the original text is > placing a requirement on the section layer technology and I think it is > reasonable to say "if you want your section layer to work with MPLS-TP it > MUST do/support X", however I don't think it's reasonable to say "if you > want your section layer to work with MPLS-TP it MAY have to do X" (which > is essentially the change the proposed text makes) because it leaves it > unclear as to what is actually required from the section layer which > practically reduces to section layers having to support X anyway so it > becomes a (implicit) MUST in any case. > > > > Furthermore the original text only states that a section layer MUST have > a means of identifying the type of payload. If a section layer does not > support multiplexing then it has an implicit means of identifying the > payload by the interface over which the payload arrived and therefore it > meets the requirement as stated by the original text. > > > > Ben > > > > > > On 29 Sep 2010, at 18:39, RFC Errata System wrote: > > > >> The following errata report has been submitted for RFC5960, > >> "MPLS Transport Profile Data Plane Architecture". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=5960&eid=2533 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: Italo Busi<italo.busi@alcatel-lucent.com> > >> > >> Section: 3.2 > >> > >> Original Text > >> ------------- > >> A section MUST provide a means of identifying the type of payload it > >> carries. > >> > >> Corrected Text > >> -------------- > >> A section MAY be required to provide a mechanism for multiplexing > MPLS > >> with other protocols. > >> > >> > >> Notes > >> ----- > >> This change is intended to clarify that providing a multiplexing > capability for a section layer is optional. > >> > >> See https://datatracker.ietf.org/liaison/916/ > >> > >> 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. > >> > >> -------------------------------------- > >> RFC5960 (draft-ietf-mpls-tp-data-plane-04) > >> -------------------------------------- > >> Title : MPLS Transport Profile Data Plane Architecture > >> Publication Date : August 2010 > >> Author(s) : D. Frost, Ed., S. Bryant, Ed., M. Bocci, Ed. > >> Category : PROPOSED STANDARD > >> Source : Multiprotocol Label Switching > >> Area : Routing > >> Stream : IETF > >> Verifying Party : IESG > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >
- [mpls] [Technical Errata Reported] RFC5960 (2533) RFC Errata System
- Re: [mpls] [Technical Errata Reported] RFC5960 (2… Benjamin Niven-Jenkins
- [mpls] R: [Technical Errata Reported] RFC5960 (25… BUSI, ITALO (ITALO)
- Re: [mpls] R: [Technical Errata Reported] RFC5960… Ben Niven-Jenkins
- Re: [mpls] R: [Technical Errata Reported] RFC5960… Thomas Nadeau
- Re: [mpls] R: [Technical Errata Reported] RFC5960… Huub van Helvoort
- Re: [mpls] [Technical Errata Reported] RFC5960 (2… Stewart Bryant
- Re: [mpls] [Technical Errata Reported] RFC5960 (2… Ross Callon
- Re: [mpls] [Technical Errata Reported] RFC5960 (2… Huub van Helvoort
- Re: [mpls] [Technical Errata Reported] RFC5960 (2… Stewart Bryant
- Re: [mpls] [Technical Errata Reported] RFC5960 (2… John E Drake
- Re: [mpls] [Technical Errata Reported] RFC5960 (2… Trowbridge, Stephen J (Steve)
- [mpls] R: [Technical Errata Reported] RFC5960 (25… BUSI, ITALO (ITALO)