Subject: [Idr] Fwd: New Version Notification for draft-scudder-idr-capabilities-registry-change-00.txt

From: "John G. Scudder" <[email-masked]>
Date: Thu, 2 Jul 2015 10:33:51 -0400

Hi Everybody,

I was looking at the registration procedures for Capability codes recently, and they are not what I would have picked if specifying Capabilities today. In order to revise the procedures, IANA  requires an RFC. Accordingly, I've written a very short Internet Draft and would like to propose it as a working group item. It's so short that I'll paste the entire meat of it here:

   [RFC5492] designates the range of Capability Codes 128-255 as
   "Reserved for Private Use".  Subsequent experience has shown this to
   be not only useless, but actively confusing to implementors.  BGP
   Capability Codes do not meet the criteria for "Reserved for Private
   Use" described in [RFC5226] S. 4.1.  An example of a legitimate
   "private use" code point might be a BGP community [RFC1997] value
   assigned for use within a given AS, but no analogous use of
   Capabilities exists.

   Accordingly, this document revises the registration procedures for
   the range 128-255, as follows, using the terminology defined in
   [RFC5226]:

   128-250: Standards Action

   251-254: Experimental Use

   255: Reserved

   The procedures for the ranges 1-63 and 64-127 are unchanged,
   remaining "IETF Review" and "First Come First Served" respectively.

That's it. Even with boilerplate and some explanatory text the whole thing comes to just over 3 pages. I'm not wedded to the exact ranges and policies I put in the document, I just needed something as a stake in the ground. I put in a section with my reasoning, though, and here's a little more:

Q: Why Standards Action?
A: we already have a decent-sized FCFS range. Standards Action precludes any risk of a "run on the bank" exhausting the number space. We can always reclassify it again in the future if we need to.

Q: Why Experimental Use?
A: There is a legitimate need for temporary code points to be used during internal development. It's better to have these come from an identifiable "swamp" than it is to have developers squat on random code points.

Q: Why Reserved?
A: No very compelling reason other than that reserving the all-ones value is kind of traditional and there doesn't seem to be a strong reason not to. It's true that the all-zeroes value is already reserved, so the need for reserving all-ones is questionable, but OTOH it also seems harmless to do it, especially given that again, we can always reclassify it in the future if needed. 

There are currently no registrations in the range 128-255, so hopefully this change should create no issues. However, if someone is currently squatting on a code point in this range, now would be a good time to come in out of the cold so we can consider grandfathering their usage if warranted. I think given the previous designation as "private use" it would be hard to fault anyone for having mistakenly made use of a number in this range. 

Thanks,

--John

> Begin forwarded message:
> 
> From: <[email-masked]>
> Subject: New Version Notification for draft-scudder-idr-capabilities-registry-change-00.txt
> Date: July 2, 2015 at 10:23:48 AM EDT
> To: John Scudder <[email-masked]>, John Scudder <[email-masked]>
> 
> 
> A new version of I-D, draft-scudder-idr-capabilities-registry-change-00.txt
> has been successfully submitted by John Scudder and posted to the
> IETF repository.
> 
> Name:		draft-scudder-idr-capabilities-registry-change
> Revision:	00
> Title:		Revision to Capability Codes Registration Procedures
> Document date:	2015-07-02
> Group:		Individual Submission
> Pages:		4
> URL:            https://www.ietf.org/internet-drafts/draft-scudder-idr-capabilities-registry-change-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-scudder-idr-capabilities-registry-change/
> Htmlized:       https://tools.ietf.org/html/draft-scudder-idr-capabilities-registry-change-00
> 
> 
> 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 "Standards Action",
>   "Experimental" and "Reserved".
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 2 Jul 2015 10:51:30 -0400

On Thu, Jul 02, 2015 at 10:33:51AM -0400, John G. Scudder wrote:
> I was looking at the registration procedures for Capability codes
> recently, and they are not what I would have picked if specifying
> Capabilities today. In order to revise the procedures, IANA  requires an
> RFC. Accordingly, I've written a very short Internet Draft and would like
> to propose it as a working group item. It's so short that I'll paste the
> entire meat of it here:

I'm supportive of this proposal.

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Fri, 03 Jul 2015 08:33:49 +0900

have read.  support adoption.

randy

---

From: <[email-masked]>
Date: Fri, 3 Jul 2015 08:29:26 +0000

> From: Randy Bush > Sent: Friday, July 03, 2015 1:34 AM
> 

+1

Please find below 1 comment 

> From: John G. Scudder > Sent: Thursday, July 02, 2015 4:34 PM
[...]
> There are currently no registrations in the range 128-255, so hopefully this
> change should create no issues.

There are no IANA registrations because they can't be: "128-255 	Reserved for Private Use 	IANA does not assign"
A priori there are no other non-official registries, so we can't really know (for sure) whether some code points are used.

> However, if someone is currently squatting
> on a code point in this range, now would be a good time to come in out of
> the cold so we can consider grandfathering their usage if warranted. I think
> given the previous designation as "private use" it would be hard to fault
> anyone for having mistakenly made use of a number in this range.

In the worst case where multiple people use the same code point, it seems also possible to register multiple use or even private use for such code point.

Given that the most probable code point (possibly) picked are likely to be 128 and 255, that's one more reason to have 255 reserved. To be on the extra safe side, I would propose to also have 128 reserved.

1 last question. IINM we would have the following registration policies:

"1-63 	IETF Review 	
 64-127 First Come First Served
 128-250: Standards Action
 251-254: Experimental Use
 255: Reserved"

Then let's suppose that a new STD track RFC ask the IANA for a code point. A priori such RFC is eligible for all ranges. Which range would the IANA (typically) pick the value from? One option is to pick in the "strongest" range. In which case, we introduce a (very low) probability of code point collision for the most "official" code points. I don't feel that this is desirable.
An option would be to move the FCFS policy to this 128-250 range, and use Standards Action for 64-127.

Thanks,
/Bruno
 
> > Subject: New Version Notification for
> > draft-scudder-idr-capabilities-registry-change-00.txt
> > A new version of I-D,
> > draft-scudder-idr-capabilities-registry-change-00.txt
> > has been successfully submitted by John Scudder and posted to the IETF
> > repository.
> >
> > 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.
> >
> > The IETF Secretariat
> >
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> 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.

---

From: "Thomas Mangin" <[email-masked]>
Date: Fri, 03 Jul 2015 10:28:23 +0100

Hello John,

If I understand your draft correctly ( it is a big assumption ) the new 
proposal would seem to make it much harder to experiment: Only allowing 
4 code for experimental use means that no more than 4 new features can 
be tested simultaneously by a single vendor ( and less if two or more 
vendors want to collaborate on a feature together ). This seems to me to 
be quite on the very low side, I would feel better if this number was to 
be raised.

Therefore I would like to know if the authors would consider raising the 
number from 4 and make a distinction between private for internal use 
only ( most likely going to be used by a single vendor ) and private for 
interop testing ( when two vendor who implemented the same draft may 
want to check all is fine before getting a code and going to production 
/ IANA allocation process).

I am also unsure if code 128 ( CISCO Route-Refresh ) and 131 ( CISCO 
multi-session ) are still found in production networks ( AFAIK it was 
the case a few years ago ), and if so, if this situation require 
formalising.

ExaBGP also use the following code in the 128+ range: 184, cumulus 
hostname draft; 185, operational draft. Would you expect me to relocate 
these code into the new 251-254 range ?

Other codes may be found in production “alive and kicking” in the 
128+ range too. I am not sure how much of a problem (if any) it is.

Sincerely,

Thomas

http://exa.net.uk/about/contact-us
On 2 Jul 2015, at 15:33, John G. Scudder wrote:

> Capabilities today. In order to revise the procedures, IANA  requires 
> an RFC. Accordingly, I've written a very short Internet Draft and 
> would like to propose it as a working group item. It's so short that 
> I'll paste the entire meat of it here:
>
> That's it. Even with boilerplate and some explanatory text the whole 
> thing comes to just over 3 pages. I'm not wedded to the exact ranges 
> and policies I put in the document, I just needed something as a stake 
> in the ground. I put in a section with my reasoning, though, and 
> here's a little more:
>
> Q: Why Standards Action?
> A: we already have a decent-sized FCFS range. Standards Action 
> precludes any risk of a "run on the bank" exhausting the number space. 
> We can always reclassify it again in the future if we need to.
>
> Q: Why Experimental Use?
> A: There is a legitimate need for temporary code points to be used 
> during internal development. It's better to have these come from an 
> identifiable "swamp" than it is to have developers squat on random 
> code points.
>
> Q: Why Reserved?
> A: No very compelling reason other than that reserving the all-ones 
> value is kind of traditional and there doesn't seem to be a strong 
> reason not to. It's true that the all-zeroes value is already 
> reserved, so the need for reserving all-ones is questionable, but OTOH 
> it also seems harmless to do it, especially given that again, we can 
> always reclassify it in the future if needed.
>
> There are currently no registrations in the range 128-255, so 
> hopefully this change should create no issues. However, if someone is 
> currently squatting on a code point in this range, now would be a good 
> time to come in out of the cold so we can consider grandfathering 
> their usage if warranted. I think given the previous designation as 
> "private use" it would be hard to fault anyone for having mistakenly 
> made use of a number in this range.
>
> Thanks,
>
> --John
>
>> Begin forwarded message:
>>
>> URL:            
>> https://www.ietf.org/internet-drafts/draft-scudder-idr-capabilities-registry-change-00.txt
>> Status:         
>> https://datatracker.ietf.org/doc/draft-scudder-idr-capabilities-registry-change/
>> Htmlized:       
>> https://tools.ietf.org/html/draft-scudder-idr-capabilities-registry-change-00
>>
>>
>> Abstract:
>> submission

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 10 Jul 2015 16:09:17 -0400

Thomas,

On Fri, Jul 03, 2015 at 10:28:23AM +0100, Thomas Mangin wrote:
> If I understand your draft correctly ( it is a big assumption ) the
> new proposal would seem to make it much harder to experiment: Only
> allowing 4 code for experimental use means that no more than 4 new
> features can be tested simultaneously by a single vendor ( and less
> if two or more vendors want to collaborate on a feature together ).
> This seems to me to be quite on the very low side, I would feel
> better if this number was to be raised.

While I also think that the number is a little low, there remain 64 code
points that are first-come, first-served.  Any experiment that proceeds to
the point of desired interop is probably ready for a real code point.

> multi-session ) are still found in production networks ( AFAIK it
> was the case a few years ago ), and if so, if this situation require
> formalising.

I would suggest that it would.  Since old BGP implementations tend to linger
for a *very* long time, these code points are effectively poisoned.

> hostname draft; 185, operational draft. Would you expect me to
> relocate these code into the new 251-254 range ?

Or the FCFS if you think the proposals are mature enough.

Alternatively, see RFC 7120.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 13 Jul 2015 16:38:59 -0400

Thomas,

Let me start by agreeing with the points Jeff made. More in-line below.

> On Jul 3, 2015, at 5:28 AM, Thomas Mangin <[email-masked]> wrote:
> 
> Hello John,
> 
> If I understand your draft correctly ( it is a big assumption ) the new proposal would seem to make it much harder to experiment: Only allowing 4 code for experimental use means that no more than 4 new features can be tested simultaneously by a single vendor ( and less if two or more vendors want to collaborate on a feature together ). This seems to me to be quite on the very low side, I would feel better if this number was to be raised.
> 
> Therefore I would like to know if the authors would consider raising the number from 4

I don't object to increasing it if there is WG consensus to do so. The number 4 reflects a starting point and was chosen according to my own judgement that on one hand, there is a need for a BGP developer to have the ability to have several features in development, but on the other hand, those features should really not be released from the lab still using experimental code points -- they should use an allocated code point. I see the use of "experimental" as virtually being limited to "give me a code point that's I can use to verify my implementation builds and runs in the lab, but at the same time can be marked as 'toxic' by my release tools to ensure that I do *not* accidentally release into the network any software that doesn't have a properly-allocated code point." It might even be reasonable for commercial test suites to verify that experimental code points are not in use, when doing validation tests.

> and make a distinction between private for internal use only ( most likely going to be used by a single vendor ) and private for interop testing ( when two vendor who implemented the same draft may want to check all is fine before getting a code and going to production / IANA allocation process).

I don't see the need for the distinction between these two. But then again, I don't see the value of 'private' code points at all in this context, only 'experimental' whose applicability is more limited than 'private'. You'll see in RFC 5226 'private use' has a defined meaning:

      Private Use - For private or local use only, with the type and
            purpose defined by the local site.  No attempt is made to
            prevent multiple sites from using the same value in
            different (and incompatible) ways.  There is no need for
            IANA to review such assignments (since IANA does not record
            them) and assignments are not generally useful for broad
            interoperability.  It is the responsibility of the sites
            making use of the Private Use range to ensure that no
            conflicts occur (within the intended scope of use).

            Examples: Site-specific options in DHCP [DHCP-IANA], Fibre
            Channel Port Type Registry [RFC4044], Exchange Types in the
            IKEv2 header [RFC4306].

An example in the BGP context is (RFC 1997-style) AS-specific communities. "The semantics of the final two octets may be defined by the autonomous system" is exactly what's meant by "private use". The thing is, although we do use Communities that way, we don't use Capabilities that way. I suppose we could introduce such a thing (composable pluggable BGP implementations with user-defined type codes) but so far, I'm not aware of such, and it's a bit of a stretch seeing user management of type codes being better than registered type codes. Such things haven't even caught on for UDP and TCP port numbers AFAIK, where it's a lot easier to manage.

> I am also unsure if code 128 ( CISCO Route-Refresh ) and 131 ( CISCO multi-session ) are still found in production networks ( AFAIK it was the case a few years ago ), and if so, if this situation require formalising.

Even if they are no longer in use (one would hope they are now using 2 or 68, respectively) they should probably be registered as "deprecated" for the reason Jeff mentioned. 

> ExaBGP also use the following code in the 128+ range: 184, cumulus hostname draft; 185, operational draft. Would you expect me to relocate these code into the new 251-254 range ?

In general I think the right thing to do is, use experimental codes when developing, use registered codes when an experiment becomes mature enough to want to use it in the network. If the experiment is standardized sometimes the semantics will remain the same and the type code can continue, in other cases the semantics will change and a new type code will have to be allocated and the old one deprecated. I'm sure our perspectives differ somewhat because I've spent years in environments where there's a high cost to deprecate or change a code point. You have probably got an enviably low cost to do this with ExaBGP.

In the end, the answer to your question is, do what is in your users' (and the Internet's) best interests. 

> Other codes may be found in production “alive and kicking” in the 128+ range too. I am not sure how much of a problem (if any) it is.

Ask yourself whether the outcome would be acceptable if those codes find themselves trying to interoperate with some other implementation using that type code for a different specification. It's hard to see the outcome being anything desirable. Whether it would be a disaster or merely annoying is anyone's guess, but I can see no reason to run the risk when doing so is completely unnecessary.

Regards,

--John

---

From: "Thomas Mangin" <[email-masked]>
Date: Tue, 14 Jul 2015 09:14:23 +0100

Hello John,

> I don't object to increasing it if there is WG consensus to do so. The number 4 reflects a starting point and was chosen according to my own judgement that on one hand, there is a need for a BGP developer to have the ability to have several features in development, but on the other hand, those features should really not be released from the lab still using experimental code points -- they should use an allocated code point.

I appreciate that 4 is a sensible pick, but I would feel constrained by it. With two code already being used by ExaBGP current implementation (once migrated), I would need to be careful in picking what I shall implement next when I rather like to not have to worry about it.

> I don't see the need for the distinction between these two.

Fair enough. if no one else does think it is worth it, I am happy to drop this distinction.

> Even if they are no longer in use (one would hope they are now using 2 or 68, respectively) they should probably be registered as "deprecated" for the reason Jeff mentioned.

It seems we all agree.

> In the end, the answer to your question is, do what is in your users' (and the Internet's) best interests.

I appreciate my enviable position and will change the codes in the new range for everyone’s benefit. And simply as ExaBGP users can change one line in the code to restore compatibility.

Thomas

---

From: John Scudder <[email-masked]>
Date: Tue, 14 Jul 2015 10:58:29 -0400

> I appreciate that 4 is a sensible pick, but I would feel constrained by it. With two code already being used by ExaBGP current implementation (once migrated), I would need to be careful in picking…

OK, what's a good number? 5? 7? 11? 13? 127? Pick a value and I'll update the draft and we can see what the rest of the WG thinks. Keep in mind though that anything we allocate to this range becomes "toxic" and can't easily be repurposed in the future, unlike the rest of the registry. To me, that suggests a bias for keeping the experimental range smallish.

--John

---

From: "Thomas Mangin" <[email-masked]>
Date: Tue, 14 Jul 2015 16:18:50 +0100

> On Jul 14, 2015, at 4:14 AM, Thomas Mangin 
> <[email-masked]> wrote:
>> I appreciate that 4 is a sensible pick, but I would feel constrained 
>> by it. With two code already being used by ExaBGP current 
>> implementation (once migrated), I would need to be careful in picking 
>> what I shall implement next when I rather like to not have to worry 
>> about it.
>
> OK, what's a good number? 5? 7? 11? 13? 127? Pick a value and I'll 
> update the draft and we can see what the rest of the WG thinks. Keep 
> in mind though that anything we allocate to this range becomes "toxic" 
> and can't easily be repurposed in the future, unlike the rest of the 
> registry. To me, that suggests a bias for keeping the experimental 
> range smallish.

I agree with keeping the range small. As I do not like prime numbers, 
and PI my favourite number is too small, it would then seem that 42 
would be the obvious answer .. which I assume we should really write 4^2 
or 16 ..  :-)

More seriously anything between 8 and 16 would be fine with me, 12 would 
be 5% (rounded).

Anyway, if/when we are getting toward the last 20 capabilities code, I 
assume it will be time to write a draft to extend the numbering space to 
two bytes anyway. IP, ASN, Capability .. p

Thomas