Subject: [Idr] I-D Action: draft-ietf-idr-capabilities-registry-change-04.txt

From: [email-masked]
Date: Thu, 23 May 2019 02:53:02 -0700

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

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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-capabilities-registry-change-04
https://datatracker.ietf.org/doc/html/draft-ietf-idr-capabilities-registry-change-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-capabilities-registry-change-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: John Scudder <[email-masked]>
Date: Thu, 23 May 2019 10:10:35 +0000

Hi All,

On May 23, 2019, at 12:53 PM, [email-masked]<mailto:[email-masked]> wrote:

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.

Thanks,

—John

---

From: tom petch <[email-masked]>
Date: Thu, 23 May 2019 16:33:05 +0000

----- Original Message -----
From: "John Scudder" <jgs=[email-masked]>
Sent: Thursday, May 23, 2019 11:10 AM

> On May 23, 2019, at 12:53 PM,
[email-masked]<mailto:[email-masked]> wrote:
> 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:
> 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.
> 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.
> 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

> —John

------------------------------------------------------------------------
--------

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 23 May 2019 12:46:15 -0400

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
 [email-masked]

---

From: John Scudder <[email-masked]>
Date: Thu, 23 May 2019 18:15:23 +0000

On May 23, 2019, at 7:33 PM, tom petch <[email-masked]<mailto:[email-masked]>> wrote:

I think that’s more of an e.g. than it is an i.e., the other option being “Reserved”. Between those two, my own preference is for “Reserved” since doesn’t burden anyone with the (admittedly minor in the grand scheme) work of deciding which range to request a number from.

—John

---

From: <[email-masked]>
Date: Fri, 24 May 2019 09:49:59 +0000

> 
> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of tom petch
> Sent: Thursday, May 23, 2019 6:33 PM
> To: [email-masked]; 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]
> 
> > I’d be interested in discussion of these options. 

Since you asked...

> Once these points

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.

> additional administrative overhead without returning any concrete

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 
 
> needs for, say, the next decade.

_________________________________________________________________________________________________________________________

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.