[mpls] R: [mpls-tp] Progressing Resolution of Erratum 2533 (RFC 5960)
"BUSI, ITALO (ITALO)" <italo.busi@alcatel-lucent.com> Wed, 10 November 2010 15:57 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 047543A68DA; Wed, 10 Nov 2010 07:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.248
X-Spam-Level:
X-Spam-Status: No, score=-5.248 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 14LW0F3GIE4w; Wed, 10 Nov 2010 07:57:30 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 326A43A63CB; Wed, 10 Nov 2010 07:57:28 -0800 (PST)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAAFvkJZ006619 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 10 Nov 2010 16:57:48 +0100
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 10 Nov 2010 16:57:45 +0100
From: "BUSI, ITALO (ITALO)" <italo.busi@alcatel-lucent.com>
To: "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>, "Adrian.Farrel@huawei.com" <Adrian.Farrel@huawei.com>
Date: Wed, 10 Nov 2010 16:57:42 +0100
Thread-Topic: [mpls-tp] Progressing Resolution of Erratum 2533 (RFC 5960)
Thread-Index: AcuA0DTlMUvHiL0iQ6ShlfrSvKjQzAAGseUw
Message-ID: <15740615FC9674499FBCE797B011623F1698805F@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
References: <0d0301cb80aa$4a9d75a0$dfd860e0$@huawei.com> <OF9E85DBD7.4F112FBF-ON852577D7.003BD994-852577D7.0042ABF9@zte.com.cn>
In-Reply-To: <OF9E85DBD7.4F112FBF-ON852577D7.003BD994-852577D7.0042ABF9@zte.com.cn>
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: multipart/alternative; boundary="_000_15740615FC9674499FBCE797B011623F1698805FFRMRSSXCHMBSB1d_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13
Cc: "mpls@ietf.org" <mpls@ietf.org>, "ahmpls-tp@lists.itu.int" <ahmpls-tp@lists.itu.int>, "mpls-tp@ietf.org" <mpls-tp@ietf.org>, "mpls-tp-bounces@ietf.org" <mpls-tp-bounces@ietf.org>
Subject: [mpls] R: [mpls-tp] Progressing Resolution of Erratum 2533 (RFC 5960)
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: Wed, 10 Nov 2010 15:57:39 -0000
I agree that the changes proposed by Adrian are not resolving the ITU-T comment. I also understand NOW that the erratum was the wrong approach to resolve the comment. Note that in the reply sent by the IETF chair to the ITU-T LS it was explicitly said: " If IETF contributors feel that there is an issue to be resolved, there are two processes that are available to make changes to published RFCs. One method is to submit an Erratum Notice using the IETF web pages (http://www.rfc-editor.org/errata.php). The other method is to produce a revision or modification to the published RFC by submitting an Internet-Draft and taking it through the IETF consensus process. Both methods are subject to review before approval. " I am very concerned by the way this issue has been managed by the IETF. The Routing ADs attended, as ISOC representatives, the ITU-T meeting where the comment was developed; so they were fully aware of its technical content. A proper instruction from them at the time the Erratum was submitted (i.e., 30 September) would have saved a lot of time and speeded up the resolution of the ITU-T comment. I was also confused by the fact that one of the two Routing AD during the same ITU-T meeting claimed that the proposed text was just a minor editorial change the editors could have easily fixed despite the document was in the RFC Editor Queue. I am very concerned to see that people are speaking with different voices in different SDOs: this behaviour is not helping the standardization work to progress in the right direction nor the convergence between ITU-T and IETF. Italo ________________________________ Da: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] Per conto di Malcolm.BETTS@zte.com.cn Inviato: mercoledì 10 novembre 2010 20.09 A: Adrian.Farrel@huawei.com Cc: mpls@ietf.org; ahmpls-tp@lists.itu.int; mpls-tp-bounces@ietf.org; mpls-tp@ietf.org Oggetto: Re: [mpls-tp] Progressing Resolution of Erratum 2533 (RFC 5960) Adrian, Thank you for the clarification the process. I now understand that the erratum was the wrong approach to address this comment from the ITU. Unfortunately I don't think that the change you are proposing will address the comment raised in the liaison from the ITU. "This change is intended to clarify that providing a multiplexing capability for a section layer is optional." My understanding is that the only motivation for the erratum was to address this comment, if this is the case then I see little point in progressing the erratum. Regards, Malcolm Adrian Farrel <Adrian.Farrel@huawei.com> Sent by: mpls-tp-bounces@ietf.org 10/11/2010 02:38 AM Please respond to Adrian.Farrel@huawei.com To ahmpls-tp@lists.itu.int, mpls@ietf.org, mpls-tp@ietf.org cc Subject [mpls-tp] Progressing Resolution of Erratum 2533 (RFC 5960) All, Thank you for your input and suggestions on this topic. To be clear, we are not attempting to reach consensus on what change to make, but I am listening to your individual opinions. In deciding what Erratum to post, I will select a form of words that clarifies the published RFC text, but which does not make a technical change. I intend to reflect the consensus of the IETF that was demonstrated by the publication of this document. The Erratum process is intended to correct typographic or rendition issues that produce Editorial or Technical issues in the published text. The process is not intended to make technical changes or fixes. Such issues should be handled by revising the work through the IETF consensus process. draft-ietf-mpls-tp-uni-nni is a good example of how that is done. Now, with regard to this particular Erratum. It seems to me that there are two separate concerns. The first concern is about identification of payloads. This is needed for a range of reasons, and is a firm requirement in the existing text (and, indeed in the MPLS architecture). However, it is noted that the identification may be explicit or implicit. The text also notes that the use of explicit identification of payload is a facilitator for demultiplexing multiplexed payloads. The second concern is whether there is a requirement to support payload multiplexing. I do not believe there is any statement about the support for multiplexing in RFC 5960. The only mention of the subject is in the filed Erratum. It would be wrong to introduce any statement of requirement or non-requirement through an Erratum. So, I'm not hearing anything that persuades me that the Erratum should be different from what I wrote. If folk want to establish a specific requirement that multiplexing is not required, then they can go ahead and write a draft. I cannot speak for how the WG will greet such a draft. Thanks, Adrian _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp
- [mpls] Progressing Resolution of Erratum 2533 (RF… Adrian Farrel
- Re: [mpls] Progressing Resolution of Erratum 2533… Alexander Vainshtein
- Re: [mpls] [mpls-tp] Progressing Resolution of Er… neil.2.harrison
- Re: [mpls] [mpls-tp] Progressing Resolution of Er… Malcolm.BETTS
- [mpls] R: [mpls-tp] Progressing Resolution of Err… BUSI, ITALO (ITALO)
- Re: [mpls] [mpls-tp] R: Progressing Resolution of… Adrian Farrel
- [mpls] R: [mpls-tp] R: Progressing Resolution of … BUSI, ITALO (ITALO)
- Re: [mpls] [mpls-tp] R: R: Progressing Resolution… Stewart Bryant
- [mpls] How can ITU-T experts contribute to the wo… BUSI, ITALO (ITALO)