Subject: [Idr] Robert Wilton's No Objection on draft-ietf-idr-capabilities-registry-change-08: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 04 May 2020 02:40:34 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-idr-capabilities-registry-change-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This document is straight forward and easy to read and understand.  I had one
minor comment.

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

It might possibly be helpful to expand this paragraph slightly.

Because what was once "Reserved for Private Use" is now being reclassified to
something non private, I presume that there are no BGP implementations using
these capability codes that could be broken by this reclassification.  Hence,
on the assumption that these codes are not in fact being used for private use,
it might be helpful to state that in order to help justify why it is okay to
make this change.

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 4 May 2020 03:39:10 -0700

On May 4, 2020 at 5:40:34 AM, Robert Wilton wrote:

Rob:

Hi!

> Because what was once "Reserved for Private Use" is now being reclassified
> to something non private, I presume that there are no BGP implementations
> using these capability codes that could be broken by this reclassification.
> Hence, on the assumption that these codes are not in fact being used for
> private use, it might be helpful to state that in order to help justify why
> it is okay to make this change.

There *are* implementations using the code points on that range.  The
WG has carefully surveyed implementations and is deprecating the known
values (Table 2).

Thanks!

Alvaro.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 4 May 2020 10:51:48 +0000

Hi Alvaro,

> -----Original Message-----
> From: Alvaro Retana <[email-masked]>
> Sent: 04 May 2020 11:39
> To: Robert Wilton via Datatracker <[email-masked]>; The IESG
> <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>
> Cc: Susan Hares <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Robert Wilton's No Objection on draft-ietf-idr-capabilities-
> registry-change-08: (with COMMENT)
> 

Okay.  I think that it might be helpful for the document to state this, both for readers who do not have that background, or in future when that knowledge has been forgotten.

Regards,
Rob

---

From: John Scudder <[email-masked]>
Date: Mon, 4 May 2020 15:40:30 +0000

I have no objection to re-adding a few sentences to that effect.

—John

On May 4, 2020, at 6:51 AM, Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>> wrote:

[External Email. Be cautious of content]

Hi Alvaro,

-----Original Message-----
From: Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Sent: 04 May 2020 11:39
To: Robert Wilton via Datatracker <[email-masked]<mailto:[email-masked]>>; The IESG
<[email-masked]<mailto:[email-masked]>>; Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Cc: Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Robert Wilton's No Objection on draft-ietf-idr-capabilities-
registry-change-08: (with COMMENT)

Rob:

Hi!

This document is straight forward and easy to read and understand. I had
one
minor comment.

Because what was once "Reserved for Private Use" is now being
reclassified
to something non private, I presume that there are no BGP
implementations
using these capability codes that could be broken by this
reclassification.
Hence, on the assumption that these codes are not in fact being used for
private use, it might be helpful to state that in order to help justify
why
it is okay to make this change.

Regards,
Rob

Thanks!

Alvaro.