Re: [mpls] [Editorial Errata Reported] RFC5036 (5597)

Stewart Bryant <stewart.bryant@gmail.com> Thu, 10 January 2019 14:32 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E213129AA0 for <mpls@ietfa.amsl.com>; Thu, 10 Jan 2019 06:32:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 l1jCo7QDSEKc for <mpls@ietfa.amsl.com>; Thu, 10 Jan 2019 06:32:51 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A6F130E67 for <mpls@ietf.org>; Thu, 10 Jan 2019 06:32:50 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id t200so12366132wmt.0 for <mpls@ietf.org>; Thu, 10 Jan 2019 06:32:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=nfTOC/C4dbXhzSXQeN/eXlB+sTaVU0vQJgc2w7g6dec=; b=D5p6ISXOUm5/TceL8VT8srj/SL47GXeZdeDPm8BhiCGpv2GT8kx9WNK5An+FCM6jd9 KNcWuTYiv6zo5KYqZkBTReQxYRsB9OQiIYM7HyLZgKMN0dFKiu0LlGStM4g03Lxk2agD BDlz2TUA6QA6b6NLoHjGPRCG1oY+f03gcJiiBsfSb2o+NFGCmDWw1nyd/QYDeJPvCq12 9PMRYWiHrkKkBrrJ0TDm1E7aRNwHdz8Fph7z+J0anT3H8xyQy3lMsqF70n2B9el1ASPr BMDF0bDl1afoAws2lqbpWkJ5T43RYH8mr/GaTNB/EXCaZcCUcSl+3KOz8sLsOIu6fjjE 51lA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=nfTOC/C4dbXhzSXQeN/eXlB+sTaVU0vQJgc2w7g6dec=; b=dzaU++a5APr3Ms86nnJpSPGgivn/UJaUjYysSkYHoRNTGI0LMUpZYkvYSd6u5Rw6zp bwUzAkdS4cXkPwAEb5mIxZgDLkTWmnfHb/w//3aNI2unjjnf4s8x10B4WbAZPph8TXA7 D2sBpfgKJzofMLTpwG2fkaKR6lF+v9UkrB8YWqMewQ3wjYuze55BRRZBjAfQtfRGbLe1 /dtw+64XYx6nRcjEjEZqsjlcEmM89W/m5ARUH0Nkao2gqS6A/h9MbSmF/6dzNwZxSwT3 FjK0efhsM3Qykm0wV++vtbc4XG5+4WM8ZY7YajvnUJ66zywSn3SfhRPEWWho0HEzyzBL i6Pg==
X-Gm-Message-State: AJcUukdUOe2kDv8HllGtgq4fsqkYoEBWPQEeio131iUuCL3sEfoAVpCs NwzGPPMnz6vCSedC1V6VIF0=
X-Google-Smtp-Source: ALg8bN6rdfkV8ILaD6ZlbZtpG8HgqmVy0tm+Vnky8xyuHio+ke6iKVh3OyYZ1Pj+BQaKwcYVgYIYqQ==
X-Received: by 2002:a1c:f707:: with SMTP id v7mr10360488wmh.18.1547130768816; Thu, 10 Jan 2019 06:32:48 -0800 (PST)
Received: from [10.66.17.45] ([131.227.23.37]) by smtp.gmail.com with ESMTPSA id w16sm57822966wrp.1.2019.01.10.06.32.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Jan 2019 06:32:48 -0800 (PST)
To: RFC Errata System <rfc-editor@rfc-editor.org>, loa@pi.se, ina@juniper.net, rhthomas@cisco.com, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, loa@pi.nu, n.leymann@telekom.de
Cc: mpls@ietf.org, ramakrishnadtv@gmail.com
References: <20190110103132.0326DB82473@rfc-editor.org>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <74f0b9ff-dd7b-5707-c7c9-7d5f314793c3@gmail.com>
Date: Thu, 10 Jan 2019 14:32:47 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <20190110103132.0326DB82473@rfc-editor.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/mFxIR_Esuhcir3rPhE3H_UBKZFE>
Subject: Re: [mpls] [Editorial Errata Reported] RFC5036 (5597)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 10 Jan 2019 14:32:54 -0000

I think that technically that is a technical change to the RFC, and so 
is outside the scope of an Errata.

Whatever the original intent, the original text say that it must grow to 
at least 2 minutes. I don't think we can just change it to be a maximum 
of 2 minutes without going through the consensus process with an, albeit 
very short, RFC.

- Stewart


On 10/01/2019 10:31, RFC Errata System wrote:
> The following errata report has been submitted for RFC5036,
> "LDP Specification".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5597
>
> --------------------------------------
> Type: Editorial
> Reported by: Ramakrishna Rao DTV <ramakrishnadtv@gmail.com>;
>
> Section: 2.5.3
>
> Original Text
> -------------
>     The session establishment setup attempt following a NAK'd
>     Initialization message MUST be delayed no less than 15 seconds, and
>     subsequent delays MUST grow to a maximum delay of no less than 2
>     minutes.  The specific session establishment action that must be
>     delayed is the attempt to open the session transport connection by
>     the LSR playing the active role.
>
>
> Corrected Text
> --------------
>     The session establishment setup attempt following a NAK'd
>     Initialization message MUST be delayed no less than 15 seconds, and
>     subsequent delays MUST grow to a maximum delay of no more than 2
>     minutes.  The specific session establishment action that must be
>     delayed is the attempt to open the session transport connection by
>     the LSR playing the active role.
>
>
> Notes
> -----
> In the 3rd line, "less" is changed to "more".
>
> The intention is to cap the maximum delay. But the existing text implies no cap
> essentially.
>
> 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
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5036 (draft-ietf-mpls-rfc3036bis-04)
> --------------------------------------
> Title               : LDP Specification
> Publication Date    : October 2007
> Author(s)           : L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed.
> Category            : DRAFT 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