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

Hi,

The somewhat limited protection against abuse of First Come First
Served is in Section 3.3 of RFC 8126:

   IANA always has the discretion to ask the IESG for advice or
   intervention when they feel it is needed, such as in cases where
   policies or procedures are unclear to them, where they encounter
   issues or questions they are unable to resolve, or where registration
   requests or patterns of requests appear to be unusual or abusive.

Should IANA not notice abusive requests for FCFS code points such that
enough were consumed to significantly constrain future assignments, I
assume some sort of special I* action would be taken to revoke the
assignments. That being said, I think that in this case the code point
space is so small that some reserved or IETF Review or similarly
restricted subrange should exist.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e3e3@gmail.com

On Thu, May 23, 2019 at 12:33 PM tom petch <ietfc@btconnect.com> wrote:
>
> ----- 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
> >
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr