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

----- Original Message -----
From: "John Scudder" <jgs=40juniper.net@dmarc.ietf.org>
Sent: Thursday, May 23, 2019 11:10 AM

> On May 23, 2019, at 12:53 PM,
internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Inter-Domain Routing WG of the IETF.
>
>        Title           : Revision to Capability Codes Registration
Procedures
>        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
non-problem.
>
> 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
benefit.
>
> I’d be interested in discussion of these options. Once these points
are settled IMO the draft is ready for last call.

John

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
   accepted."

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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>