[Idr] Re: Éric Vyncke's No Objection on draft-ietf-idr-nhc-05: (with COMMENT)

Jeffrey Haas <jhaas@pfrc.org> Mon, 01 June 2026 20:19 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: idr@mail2.ietf.org
Delivered-To: idr@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 20337F8DF774; Mon, 1 Jun 2026 13:19:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1780345163; bh=XQp8y1XS1Po9RzjoojV3Nc/8Sz/evuKaspjNVzDy4WM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=HfKQF5px3k2ilVStBagxCVsx7bHa9kDMgy5zjZivPNfKYZqO0ec2TppuKpA0W5m4V r8OAs+FTZRcTGqTUnOMnRXV7DjtjNgVbX4QRNwqx5xELrqwcBWhexbJ/7oYXKxb84C ixXC5Tn5xN2Zvw24f2DPjJoGuax6rLWy09GHzbOs=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvikmfWArLV4; Mon, 1 Jun 2026 13:19:21 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by mail2.ietf.org (Postfix) with ESMTP id BDA41F8DF761; Mon, 1 Jun 2026 13:19:20 -0700 (PDT)
Received: from smtpclient.apple (99-188-202-8.lightspeed.livnmi.sbcglobal.net [99.188.202.8]) by slice.pfrc.org (Postfix) with ESMTPSA id 9144C1E25F; Mon, 1 Jun 2026 16:19:20 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <E25EA0E5-577D-45BA-B740-15F3466F88F0@hpe.com>
Date: Mon, 01 Jun 2026 16:19:09 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <296F1702-7A0C-4A9A-83C2-0D5B1DBB8B4F@pfrc.org>
References: <178027042358.1839115.10663719879470585099@dt-datatracker-5b4c8598b5-4ztf9> <12187F18-6F6F-4446-A6D0-8248C0C580E5@hpe.com> <A6BB5508-12D3-4365-A7E5-F3149B219456@pfrc.org> <E25EA0E5-577D-45BA-B740-15F3466F88F0@hpe.com>
To: "Scudder, John" <john.scudder@hpe.com>
X-Mailer: Apple Mail (2.3864.500.181)
Message-ID-Hash: Z27W6BKXSYBL6DQ3YORXHQIZYHF6DQ7L
X-Message-ID-Hash: Z27W6BKXSYBL6DQ3YORXHQIZYHF6DQ7L
X-MailFrom: jhaas@pfrc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "Scudder, John" <john.scudder=40hpe.com@dmarc.ietf.org>, Éric Vyncke <evyncke@cisco.com>, Hares Susan <shares@ndzh.com>, The IESG <iesg@ietf.org>, "draft-ietf-idr-nhc@ietf.org" <draft-ietf-idr-nhc@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Idr] Re: Éric Vyncke's No Objection on draft-ietf-idr-nhc-05: (with COMMENT)
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/J3HT6vmjfSwCmi4LLqTDgkJGJ1I>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

I support this option.

-- Jeff 

> On Jun 1, 2026, at 16:02, Scudder, John <john.scudder@hpe.com> wrote:
> 
> Hi Jeff and all, 
> 
> Jeff’s message reminded me that I omitted another option: Delete the contentious sentences, as in:
> 
> OLD:
>   Under the circumstances described in Section 2.2.1, when a route
>   includes only a link-local address and no global address, the BGPID
>   MUST be included.  Under other circumstances, the BGPID SHOULD NOT be
>   included.
> 
> NEW:
>   Under the circumstances described in Section 2.2.1, when a route
>   includes only a link-local address and no global address, the BGPID
>   MUST be included.  
> 
> OLD:
>   Other uses of the BGPID are beyond the scope of this document.  In
>   particular, if a route is received that has a global part to its next
>   hop and thus does not match the circumstances described in
>   Section 2.2.1, but which nonetheless has a BGPID, the BGPID SHOULD be
>   disregarded.
> 
> NEW:
>    <no text>
> 
> Now that I think about it, I rather like this solution. It returns us to the semantics of version 02, but without the explicit MAY that caused angst because it was seen as leading naïve developers astray.
> 
> I’d like to make this my new strawman proposal.
> 
> —John