Re: [core] Paul Wouters' No Objection on draft-ietf-core-sid-21: (with COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Paul,

thank you for these comments.

The changes proposed for addressing these are in
https://github.com/core-wg/yang-cbor/pull/161

Grüße, Carsten



> On 2023-10-23, at 21:14, Paul Wouters via Datatracker <[e-mail]> wrote:
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-core-sid-21: No Objection[…]
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-core-sid/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> The document states that SIDs for a name can never change, but then introduces
> "unstable SIDs" that do exactly that. It specifies SIDs can also be "withdrawn"
> which again goes against the Objectives carefully laid out earlier. Possibly
> the text can be made more clear and consistent with this respect?

In the introduction, I changed

OLD:
SIDs are assigned permanently.
NEW:
Once considered "stable", SIDs are assigned permanently.

Yes, there are a few editorial rounds that could be taken.

> Are the Editor: contacts neccessary? These are all email addresses of people
> at their dayjob, which are likely to be invalid within a few years.

We traditionally let the authors choose what contact information they want to provide.  Actually, the email addresses given here in the appendix have been quite stable over the last decade.  With the move to postalLine in the RFCXML format, maybe we should discuss new guidelines for author contacts in 7322bis.

>        Once a module is declared stable
> 
> Where is this process described? I see no normative reference for this.
> Without that, I cannot understand the process. Who or what defines a
> module to be stable?

“published” is almost a synonym, except that a module may be declared stable (e.g., by approving an RFC) before it actually is published.

The NETMOD WG has been grappling with the exact process they want to use for a while (there have been weekly calls about this subject since 2021!).  So I don’t think we have a really good reference here, but we can point to RFC 8407 (BCP 216), e.g., see Section 4.27.
I added a reference to Section 11 of RFC 7950 and Section 4.27 of RFC 8407 to Section 2.2.

Now
e2e9e80

>        While IANA ultimately maintains the registries that
>        govern SIDs for IETF-defined modules, various support
>        tools such as yangcatalog.org need to provide the support
>        to enable SID assignment and use for modules still in
>        IETF development. Developers of open-source or proprietary
>        YANG modules also need to be able to serve as such entities
>        autonomously, possibly forming alliances independent of the IETF,
>        while still fitting in the overall SID number space managed by
>        IANA. Obviously, this process has a number of parallels to the
>        management of IP addresses, but also is very different.
> 
> Does this text really belong in an RFC?

I believe it is appropriate for a section discussing objectives.

> For example the note the use of
> yangcatalog.org without it even being a reference?

The YANG community knows what that is and will appreciate having been given an example for a “support tool”.  However, this tool certainly is more ephemeral than the procedures defined here; I added a “at the time of writing” and made it an actual reference.

Now
e782917

> It would be best if the
> goal of this text was met by whatever IANA registration page text would
> be created.

But we are informing IANA about our objectives here, not v.v.

>        like ships in the night.
> 
> Replace this text with something international readers understand. I don't
> think I understand this.

OK, this is entrenched jargon in the IETF, but I agree it is jargon.
I find 15 RFCs that use this jargon (RFC 9262 being the latest), often without explanation (e.g., RFC 6180).

I replaced this by »without communicating (“like ships in the night”)«.

Now
0898ffc