Re: [mpls] to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)
Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 14 May 2015 09:52 UTC
Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA9D1B35B6 for <mpls@ietfa.amsl.com>; Thu, 14 May 2015 02:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.491
X-Spam-Level:
X-Spam-Status: No, score=0.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-rrrcvbTLmi for <mpls@ietfa.amsl.com>; Thu, 14 May 2015 02:51:59 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D36E1B35AF for <mpls@ietf.org>; Thu, 14 May 2015 02:51:59 -0700 (PDT)
Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (25.161.55.12) by DB3PR03MB0777.eurprd03.prod.outlook.com (25.161.54.27) with Microsoft SMTP Server (TLS) id 15.1.160.19; Thu, 14 May 2015 09:51:39 +0000
Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) with mapi id 15.01.0166.017; Thu, 14 May 2015 09:51:39 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Loa Andersson <loa@pi.nu>
Thread-Topic: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)
Thread-Index: AQHQjZzAsr+eVgEnQkSV6+FhG15t2Z17NQWAgAAGrjA=
Date: Thu, 14 May 2015 09:51:38 +0000
Message-ID: <DB3PR03MB0780DBAB2961BD0D7296C1449DD80@DB3PR03MB0780.eurprd03.prod.outlook.com>
References: <DB3PR03MB0780EB97294D9CD37A9711A19DD90@DB3PR03MB0780.eurprd03.prod.outlook.com> <55546A61.7080007@pi.nu>
In-Reply-To: <55546A61.7080007@pi.nu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: pi.nu; dkim=none (message not signed) header.d=none;
x-originating-ip: [147.234.56.21]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0777;
x-microsoft-antispam-prvs: <DB3PR03MB07779F45EF8985FC583AC8129DD80@DB3PR03MB0777.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR03MB0777; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0777;
x-forefront-prvs: 0576145E86
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(51704005)(377454003)(377424004)(252514010)(479174004)(106116001)(74316001)(87936001)(40100003)(2656002)(122556002)(76576001)(33656002)(86362001)(54356999)(76176999)(50986999)(15188155005)(16799955002)(66066001)(62966003)(77156002)(19580405001)(19580395003)(5001960100002)(92566002)(102836002)(15975445007)(189998001)(2900100001)(2950100001)(46102003)(110136002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0777; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2015 09:51:38.1645 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0777
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/QyWRkq8XaJThJLrsWRAOvU9u5yU>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "rcallon@juniper.net" <rcallon@juniper.net>
Subject: Re: [mpls] to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 14 May 2015 09:52:02 -0000
Loa, Lots of thanks for a prompt and highly informative response. I will consider writing a short ID addressing this issue with 5586. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Thursday, May 14, 2015 12:27 PM To: Alexander Vainshtein; BRUNGARD, DEBORAH A Cc: mpls@ietf.org; matthew.bocci@alcatel-lucent.com; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com; akatlas@gmail.com; aretana@cisco.com; rcallon@juniper.net; swallow@cisco.com Subject: Re: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) Sasha, On 2015-05-13 18:49, Alexander Vainshtein wrote: > Loa, > > I do not argue with the decision. > > I would simply like to understand > > (a) whether you think that this change should be considered if/when > 5586bis is considered We have a a proposed changed, and it should certainly be considered if/when we do a 5586bis. > > (b) how to preserve this input if it has any value. The simple answer is that I don't know if the IETF have a method to do this - other than the mail archives. I've a set of notes with potential changes/updates/extensions to the MPLS RFCs and the RFCs that I been involved in writing. Sometimes the number of entries towards one item/issues gets such that it makes sense to do something, but when a full bis is not motivated. What I've don in such cases is towrite a small ID to preserve the input. If you want it is possible to turn the "errata" into a draft. We would then get wg consensus and if published it is guaranteed to be considered when we do the bis. If not I think we need to trust that we keep our notes straight. /Loa > > My gut feeling after reading your original email was that the change > is worth considering. And I do not know the answer for (b). > > Thumb typed on my LG, > Sasha > > ------ Original message ------ > *From: *Loa Andersson > *Date: *13/05/2015 18:43 > *To: *Alexander Vainshtein;BRUNGARD, DEBORAH A; > *Cc: > *mpls@ietf.org;matthew.bocci@alcatel-lucent.com;martin.vigoureux@alcat > el-lucent.com;stbryant@cisco.com;akatlas@gmail.com;aretana@cisco.com;r > callon@juniper.net;swallow@cisco.com; > *Subject:*Re: to be rejected - Re: [Technical Errata Reported] RFC5586 > (4364) > > Sasha, > > I think the rationale is that the wg chairs don't see this as an > errata, but rather as a change. > > Not being an errata, it seems odd to use the errata system to maintain > a non-errata. > > /Loa > > On 2015-05-13 14:14, Alexander Vainshtein wrote: >> Deborah, Loa and all, >> I accept the decision to reject the errata, of course. >> >> Revisiting this issue if/when the document is updated is OK with me, even if must admit that I do not understand the difference between this and the disposition of errata that says "take into account when the document is updated" (or something like this). >> >> I would just like to clarify that my interest in the issue was triggered by a question I've received from the field, when a person examining some capture as asked me: >> "Why is the TTL in the LSE containing GAL set to 2" Is this standard?" >> >> I have looked up RFC 5586, and I did not find a straightforward answer to this question. >> >> Regards, >> Sasha >> >> Office: +972-39266302 >> Cell: +972-549266302 >> Email: Alexander.Vainshtein@ecitele.com >> >> -----Original Message----- >> From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] >> Sent: Wednesday, May 13, 2015 2:58 PM >> To: Loa Andersson; RFC Errata System; >> matthew.bocci@alcatel-lucent.com; >> martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com; >> akatlas@gmail.com; aretana@cisco.com; swallow@cisco.com; >> rcallon@juniper.net >> Cc: Alexander Vainshtein; mpls@ietf.org >> Subject: RE: to be rejected - Re: [Technical Errata Reported] RFC5586 >> (4364) >> >> Will do - >> Thanks Loa- >> Deborah >> >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Wednesday, May 13, 2015 2:59 AM >> To: RFC Errata System; matthew.bocci@alcatel-lucent.com; >> martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com; >> akatlas@gmail.com; BRUNGARD, DEBORAH A; aretana@cisco.com; >> swallow@cisco.com; rcallon@juniper.net >> Cc: Alexander.Vainshtein@ecitele.com; mpls@ietf.org >> Subject: to be rejected - Re: [Technical Errata Reported] RFC5586 >> (4364) >> >> Folks, >> >> MPLS chairs have discussed the errata. >> >> We feel that it is a change to the document rather than an errata, on that ground it should be rejected. >> >> We think that the appropriate would be to revisit this if the document is updated. >> >> I'm always uncertain of the procedures around accepting/rejecting errata, but I guess it requires AD decision. >> >> Deborah, >> >> Can you mark this a "rejected"? >> >> >> /Loa >> >> On 2015-05-12 16:14, RFC Errata System wrote: >>> The following errata report has been submitted for RFC5586, "MPLS >>> Generic Associated Channel". >>> >>> -------------------------------------- >>> You may review the report below and at: >>>http://www.rfc-editor.org/errata_search.php?rfc=5586&eid=4364 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Alexander ("Sasha") Vainshtein >>> <Alexander.Vainshtein@ecitele.com> >>> >>> Section: 4.2.1 >>> >>> Original Text >>> ------------- >>> The Time-To-Live (TTL) field of the LSE that contains the GAL follows >>> the definition and processing rules specified in [RFC3443]. >>> >>> Corrected Text >>> -------------- >>> The value of the Time-To-Live (TTL) field of the LSE that contains >>> the GAL follows is irrelevant as long as it exceeds 1. (Setting this >>> value to 0 or 1 SHOULD be avoided because it could result in >>> trapping the OAM packets in with wrong reason: "TTL expiration" >>> instead of "GAL encountered"). >>> >>> Notes >>> ----- >>> The processing rules specific in RFC 3443 deal with handling TTL in the LSE of a labeled packets that are forwarded based on this LSE, or with setting the TTL value by a LER pushing a label stack on an unlabeled packet. >>> As per the last para in Section 4.2, LSRs and LERs MUST NOT forward packets based on the LSE that contains GAL, hence these rules are mainly not applicable. >>> >>> Instructions: >>> ------------- >>> This erratum 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. >>> >>> -------------------------------------- >>> RFC5586 (draft-ietf-mpls-tp-gach-gal-06) >>> -------------------------------------- >>> Title : MPLS Generic Associated Channel >>> Publication Date : June 2009 >>> Author(s) : M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed. >>> Category : PROPOSED STANDARD >>> Source : Multiprotocol Label Switching >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG >>> >> > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
- Re: [mpls] to be rejected - Re: [Technical Errata… Alexander Vainshtein
- Re: [mpls] to be rejected - Re: [Technical Errata… Loa Andersson
- Re: [mpls] to be rejected - Re: [Technical Errata… Alexander Vainshtein