Re: [Idr] Requesting WG adoption for draft-scudder-idr-capabilities-registry-change-02.txt

"Jakob Heitz (jheitz)" <> Fri, 21 September 2018 00:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79B3112DD85; Thu, 20 Sep 2018 17:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id anW5Ed0Ownhn; Thu, 20 Sep 2018 17:48:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 51B42130DDA; Thu, 20 Sep 2018 17:48:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1929; q=dns/txt; s=iport; t=1537490917; x=1538700517; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pMyU8rHAK5Kyse0hK06f8vUfWd2VqMJxCtEJvw12bZQ=; b=jcT3op8B1VDvvY3lkqLnr3nlQ5jpixURmbKEEFbQDA2vhA41Tj5l97GE C8RLTnQyyDAVC4xVoXltuuVMLNwU6lEkotfZxHD9DYJQ3qAmk5y1FWYSf UPQhqN29FQskRUPXjRvEnIT/tCBLnyFnAbhu6pyNwTij7SwzmrKg1Wsv3 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAABjP6Rb/5pdJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYIIZX8oCot+jkCWToF6CxgNhEcCg0IhNBgBAwEBAgE?= =?us-ascii?q?BAm0cDIU4AQEBAQMBATg0CwwEAgEIDgMEAQEfECcLHQgCBAENBQiDGoIBD6Q?= =?us-ascii?q?3igkFim8XgUE/gRKDEoFBAYFZAQGBLYYMAoYfgh2GcY1BCQKMVINGH4FEhFC?= =?us-ascii?q?JDpROAhEUgSUdOIFVcBU7gmyCTYhJhT5vAYxwgR4BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,282,1534809600"; d="scan'208";a="452028623"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2018 00:48:12 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w8L0mCiY007210 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Sep 2018 00:48:13 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 20 Sep 2018 19:48:11 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Thu, 20 Sep 2018 19:48:11 -0500
From: "Jakob Heitz (jheitz)" <>
To: John Scudder <>, "" <>
CC: "" <>
Thread-Topic: Requesting WG adoption for draft-scudder-idr-capabilities-registry-change-02.txt
Thread-Index: AQHUUKixsqEn2M98Pke/8kwMHYP+c6T56B6A
Date: Fri, 21 Sep 2018 00:48:11 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Idr] Requesting WG adoption for draft-scudder-idr-capabilities-registry-change-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Sep 2018 00:48:40 -0000

I support. Thanks John.


-----Original Message-----
From: Idr <> On Behalf Of John Scudder
Sent: Wednesday, September 19, 2018 11:11 PM
Subject: [Idr] Requesting WG adoption for draft-scudder-idr-capabilities-registry-change-02.txt

Hi All,

People with sharp memories may recall that in 2015 I proposed we revise the BGP Capabilities registry to provide a good-sized FCFS space. I think our experience shows this works fine in practice and makes it easier for implementors to get code points in a timely fashion, helping prevent conflicts. I wrote a draft at that time but failed to follow it up. I've revised the draft and would like to propose it as a WG item. Here's the abstract:

   This document updates RFC 5492 by making a change to the registration
   procedures for BGP Capability Codes.  Specifically, the range
   formerly designated "Reserved for Private Use" is divided into three
   new ranges, respectively designated as "First Come First Served",
   "Experimental" and "Reserved".

One thing to draw your attention to in the revised draft:

   Finally, we invite implementors who have used values in the range
   128-255 to contribute to this draft, so that the values can be
   included in the registry.

That is, if you have a shipped implementation that's using one of the Private Use values, please contribute that information to the draft and (assuming the draft progresses) you'll automatically get a registered code point.


--John (an individual contributor to the WG, and recusing myself as co-chair from the adoption and subsequent process)

Idr mailing list