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: Idr [mailto:idr-bounces@ietf.org] On Behalf Of tom petch
> Sent: Thursday, May 23, 2019 6:33 PM
> To: idr@ietf.org; John Scudder
> Subject: 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. 

Since you asked...

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

Two months ago, I would have said go for "2.a. Make 1-238 all FCFS" but as of today, I think Tom as a point.

A few random comments:
- If an actor requests all the code points, we probably still have the ability to write an RFC and reclaim those code points. We also have one reserved code point which would allow for extensions (but with a higher incremental cost, and possibly raising the same question for the allocation policy)
- FCFS does have minimal sanity check: well-formed request, description of usage, not a duplicate
- IMHO, in general code points are for interop and not for one private actor. (though I don't expect this opinion to be shared, and this is debatable in the specific case of BGP capabilities (vs attributes)). Hence code point would be better with a specification of how it is used. I think my preferred registration policy would be "IETF WG document Required". This one is not proposed in RFC 8126. This is not a showstopper, but I would assume that there is a (good) reason for that. Alternatively "Specification Required" seems the closest, but requires a designated expert (IDR chairs + instruction to have an IETF WG document would be pretty close to "IETF WG document Required")
- Among the 3 proposed options, I can really live with any option, but I guess that I have a slight preference with 2.b or 2.c.

> > 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 understand the Con, but would feel that education, e.g. in this draft, should work. Altso, with an FCFS range anyone can make the request for the specification (including a chair/shepherd/anyone needing to implement/use), so we do not really have to rely on authors' assumptions.
But I'm speaking (weak) theory, while your "Con" reflects real experience. In theory there is no difference between theory and practice. In practice there is.

--Bruno 

> 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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.