Re: [Idr] Can we eliminate the "IETF Review" Capablities range? [was: Re: I-D Action: draft-ietf-idr-capabilities-registry-change-04.txt]

tom petch <> Thu, 23 May 2019 16:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E15C120132 for <>; Thu, 23 May 2019 09:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.247
X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 28GrEpXvElKL for <>; Thu, 23 May 2019 09:33:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD70012011D for <>; Thu, 23 May 2019 09:33:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7bLVp9yoMtTtSwr81VOZtii1t7G1T5ay+Q/FHh2yyRU=; b=OF0CaeACHB3DVeU1DEHDhkmrwM6vLLYLcA+ijuxhkfQ5egzJQlNJDS+v0SCBTDgC2+0+7vw90b7vxvW0Ids2EvOfeMwHqVbjfBnSI30tCblHYwhaHLDieNN0ftNbxgPbLsCSYgbYJbg7vuSsdT84GTKgfL/krUyumxu44c36A2Y=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.9; Thu, 23 May 2019 16:33:05 +0000
Received: from ([fe80::7537:44ee:88c1:dd6d]) by ([fe80::7537:44ee:88c1:dd6d%7]) with mapi id 15.20.1943.007; Thu, 23 May 2019 16:33:05 +0000
From: tom petch <>
To: "" <>, John Scudder <>
Thread-Topic: [Idr] Can we eliminate the "IETF Review" Capablities range? [was: Re: I-D Action: draft-ietf-idr-capabilities-registry-change-04.txt]
Thread-Index: AQHVEYUyVIsCWqG9LUSO7O62sTvrZg==
Date: Thu, 23 May 2019 16:33:05 +0000
Message-ID: <015701d51184$a55712c0$>
References: <> <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-clientproxiedby: LO2P265CA0234.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:b::30) To (2603:10a6:802:20::28)
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 15e7f2be-541b-48ee-a8ae-08d6df9c54bb
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB3488;
x-ms-traffictypediagnostic: VI1PR07MB3488:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:3631;
x-forefront-prvs: 00462943DE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(366004)(39860400002)(376002)(199004)(189003)(13464003)(1556002)(81156014)(81166006)(8936002)(52116002)(110136005)(76176011)(84392002)(81816011)(8676002)(61296003)(66574012)(14454004)(50226002)(7736002)(3846002)(99286004)(2906002)(305945005)(81686011)(14496001)(68736007)(53546011)(6506007)(386003)(6116002)(102836004)(186003)(62236002)(2501003)(66946007)(73956011)(64756008)(66556008)(66476007)(66446008)(478600001)(14444005)(44716002)(256004)(25786009)(229853002)(6512007)(6306002)(6436002)(5660300002)(86152003)(6486002)(9686003)(44736005)(4720700003)(316002)(26005)(966005)(66066001)(71200400001)(86362001)(446003)(53936002)(486006)(71190400001)(6246003)(476003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3488;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Xv3vijErw2kxrK8c0znfEzsMpRMZ5kGw21jo394bR26W0gJSKEETe/XJ9W38l6I3DbsYUlVhcRFuVVe/vduNmTlg6/hhne8mteATZkUWZa2u6MtYYo0Tdb4Sqng5k+5j7UoFCeoxZgu/QBKpLUStV8fwB3Xt683znqA3l2+CCF987/RzJnxW9OD8miwlO3673ojg1iJXJHc35pbP/XwVnhviIoXvCMQTiFqyb4qmcWHYcwjDbWRBdSVG9rx3glu1/yNetc5rQK9taR3UjAQ47oK2IClRwGjF1XWAAsdQ92L6LP/5Y8QzfLPygwmcZvjn58pPUn1nS4G+2hV7KNwLvkzx00Uab3tN8nzRW9e6Td88OSLCBoSZfufR912cHDlKpk5ZZ5rRViGRyemOTWMrhMup/k+OvgIZTl+Y2bSG+ZE=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 15e7f2be-541b-48ee-a8ae-08d6df9c54bb
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2019 16:33:05.2178 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3488
Archived-At: <>
Subject: Re: [Idr] Can we eliminate the "IETF Review" Capablities range? [was: Re: I-D Action: draft-ietf-idr-capabilities-registry-change-04.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: Thu, 23 May 2019 16:33:12 -0000

----- Original Message -----
From: "John Scudder" <>
Sent: Thursday, May 23, 2019 11:10 AM

> On May 23, 2019, at 12:53 PM,<> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> This draft is a work item of the Inter-Domain Routing WG of the IETF.
>        Title           : Revision to Capability Codes Registration
>        Author          : John Scudder
> Filename        : draft-ietf-idr-capabilities-registry-change-04.txt
> Pages           : 5
> Date            : 2019-05-23
> This is a version bump to refresh the draft, which had expired. There
are two outstanding points I can think of:
> 1. I’ve received a report of another use of Capability 129 (different
from the one reported in the draft). I’m following up with the reporter
to find out if that needs to be documented in the draft, if it does I’ll
issue a revision.
> 2. The draft currently leaves Capabilities 1-63 as “IETF Review”. As I
’ve mentioned in another thread recently, I’ve become skeptical of the
value of splitting registries between IETF Review and FCFS. Here are
some options, listed in order of my own preference:
> 2.a. Make 1-238 all FCFS.
> Pro: this is the easiest allocation policy with the least admin
overhead. There is no decision required as to which range to select, so
less confusion.
> Con: there’s a theoretical risk of the number space being completely
consumed, without any formal way for the WG to prevent it. (A “run on
the bank”.)
> Rebuttal: this hasn’t been seen to happen in practice. Also, we do
reserve 255 in case we need it for future extension.
> 2.b. Make 1-63 Reserved, 64-238 FCFS.
> Pro: as above, but without the chance that the number space could be
completely consumed since 1-63 is protected. If that range is needed in
the future, another draft can be written to reclassify it as IETF Review
again, or as whatever is desired at that time.
> Con: it’s a slightly more complicated solution to what may be a
> 2.c. Leave it as written in version 04, 1-63 IETF Review, 64-238 FCFS.
> Pro: it’s what we’ve already been discussing and nobody (other than
me, in this note) has raised an objection so far.
> Con: authors are required to choose between the two ranges, experience
shows that many assume that IETF Review is “better” for some reason.
This holds up number allocation, retards implementation, and invokes
additional administrative overhead without returning any concrete
> I’d be interested in discussion of these options. Once these points
are settled IMO the draft is ready for last call.


I see it as a question of security.  The Internet used to consist of
friendly, helpful people who worked together to make it happen.  Now
there is a whole raft of evil people, some state actors, some
individual, some corporate - in fact, actors of any kind.

So, if we make it FCFS, and an evil actor sets out to sabotage us, what
mechanisms do we have to stop them?  Think of the kind of mechanisms
that routers have to stop them being overwhelmed.

As RFC8126says,

"   It is also important to understand that First Come First Served
   really has no filtering.  Essentially, any well-formed request is

so we have no defence against a DoS attack.  We have not had one such
yet but as they say of pilots, there are those who have landed with the
wheels up and there are those who will land with the wheels up.

We should reserve enough entries, i.e. IETF Review, to accommodate our
needs for, say, the next decade.

Tom Petch

> Thanks,
> —John


> _______________________________________________
> Idr mailing list