Re: [core] Murray Kucherawy's No Objection on draft-ietf-core-sid-22: (with COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Murray,

thank you for your comments.

We now have a -24 out that addresses the ones we hadn’t already addressed in -23.

Details below.

Grüße, Carsten


> On 2023-10-26, at 09:10, Murray Kucherawy via Datatracker <[e-mail]> wrote:
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-core-sid-22: No Objection
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Focusing again on Section 6 (IANA Considerations), which has got to be the most
> complex one I've ever seen:

Indeed, and this section has been almost a decade in the making...

> * Please don't use BCP 14 keywords here, as this section isn't the place to
> discuss interoperability.  Lowercasing the ones you have should be fine.

The BCP 14 keywords here do mandate behavior that is a prerequisite for interoperability (many even are about specific artifacts of interoperation, such as SID files).

Section 6 of RFC 2119 says:

6. Guidance in the use of these Imperatives

  Imperatives of the type defined in this memo must be used with care
  and sparingly.  In particular, they MUST only be used where it is
  actually required for interoperation or to limit behavior which has
  potential for causing harm (e.g., limiting retransmisssions)  For
  example, they must not be used to try to impose a particular method
  on implementors where the method is not required for
  interoperability.

This makes us think we are well within the bounds set up by RFC 2119.

> * In 6.3.1, why is "policy of SID range" considered part of "contact
> information"?

Fixed in PR #166
https://github.com/core-wg/yang-cbor/pull/166
https://github.com/core-wg/yang-cbor/pull/166/commits/fb76e59

> * In 6.3.2, seems to me the first and last bullets both talk about sustainable
> operation and could be merged.

The first bullet is more about an instance in time, while the last bullet is indeed about sustainability.  We think it is a good idea to call the latter out explicitly and separately.

> * Also in 6.3.2, how do you imagine the designated expert evaluating "technical
> capacity" to operate a registry?  I note that Robert raised a similar concern.

We would expect the registrant to supply some information that will be persuasive to the DE; the text gives the DE leverage to ask for that.
The DE doesn’t have a crystal ball or a panopticon, so the accuracy of the assessment will be limited.
The effect of the mandate should be that potential registrants think about how to provide that capacity and get management buy-in to put measures into place.

> * Sections 6.4 and 6.5 create registries that are going to be complicated for
> the Designated Expert to work, and for the DE to present to the IESG proof that
> the process was followed if asked.  I have to trust that all this complexity is
> necessary.

We sure wish there would be a simpler way!

> * In 6.5.1, by "link", do you mean a URI?

Indeed.
Also fixed in PR #166
https://github.com/core-wg/yang-cbor/pull/166
https://github.com/core-wg/yang-cbor/pull/166/commits/fb76e59
(We think the remaining “link” is OK.)