[Idr] draft-scudder-idr-capability-registry-change

[<[e-mail]>]

John, all

First, thanks for the effort to minimize collision.


TL ;DR     I'd mildly propose the (discussion of the) following change
OLD:

   128: Reserved

   129-238: First Come First Served
   239-254: Experimental Use

NEW:

   128-133: Experimental Use

   134-254: First Come First Served


Motivations:
1) Reserved --> Experimental Use

"Although it is not possible to know what code points implementors may have used, experience suggests 128 is a likely value.  For that reason, this document asks
   IANA to reserve that value, to minimize the risk of conflict with existing implementations. »

"Reserved" means reserved for future (special) uses. It does not seem to match with the motivation expressed (some risk of collision, i.e. mostly burnt already), although hypothetical.
One option would be to allocate the value to a name to be found.; but keeping its current usage would save one code point.

2) Experimental Use 239-254 --> 128-133
Although it is not possible to know what code points implementors may have used, there is a chance that they may have pick the low end or  high end of the range.
Keeping the low end range (128-133) for experimental avoid risk of collision with assigned code point.
As for the high end range (e.g. 239-254) the risk of collision is postponed to far in the future, if any. I would assume/hope that at this point in time, any current experiment would be either dead or use an official code point.


Finally, I agree that my reasoning is hypothetical (at best), so should only be taken as one opinion among many. Also, my last argument would also probably work to dismiss the need for this proposed change...

Thanks,
Best regards,
--Bruno


From: Idr [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, September 20, 2018 5:22 PM
To: Susan Hares; [e-mail]
Cc: 'idr'
Subject: Re: [Idr] 2 week WG adoption call - draft-scudder-idr-capability-registry-change (9/20/2018 to 10/4/2018)

1) Support WG adoption.

2)

> Please include comments on operational impacts on this proposal.

The main risk seems collision between future allocation and past usage. IMHO the document adequately covers this by calling for past usages, and given the remaining unallocated space in existing FCFS range (74-127)  (i.e. before we reach the collision range).

Also, that collision risk already exists as of today if we consider that "BGP Capability Codes do not meet the criteria for "Reserved for Private Use" described in [RFC5226<https://tools.ietf.org/html/rfc5226>] S. 4.1.". In this regards, the document improves the situation, so the faster the change, the better.

3) Please find below 2 nits and 1 minor comment


:s/ [RFC5226<https://tools.ietf.org/html/rfc5226>]/ [RFC8126<https://tools.ietf.org/html/rfc8126>]

----

OLD :

   128-238: First Come First Served



NEW :

   128: Reserved

   129-238: First Come First Served


(in order to be consistent with    IANA is requested to allocate value 128 as "Reserved".


---

"   Finally, we invite implementors who have used values in the range

   128-255 to contribute to this draft, so that the values can be

   included in the registry. »

+1
Recalling another thread (from John) some years ago, about whether one could ask for any value or only the next one/the one chosen by IANA...I don't remember its conclusion.
In order to handle post RFC publication contributions, may be we could add a text to ask IANA to allow for request with specific value in the range 129-238.

Thanks,
Regards,
--Bruno

From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Thursday, September 20, 2018 4:11 PM
To: 'idr'
Cc: [e-mail]
Subject: [Idr] 2 week WG adoption call - draft-scudder-idr-capability-registry-change (9/20/2018 to 10/4/2018)

Greetings all:

Based on the messages on the IDR list, there seems to be interest to start a 2 week WG adoption call for  draft-scudder-idr-capabilities-registry-change-02.txt.  The WG adoption call will go from 9/20/2018 to 10/4/2018.

You can obtain the document quickly by clicking on the link below:

https://datatracker.ietf.org/doc/draft-scudder-idr-capabilities-registry-change/

Please include comments on operational impacts on this proposal.

Susan Hares
Co-chair 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.

_________________________________________________________________________________________________________________________

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.