Re: [core] Éric Vyncke's No Objection on draft-ietf-core-sid-22: (with COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Éric,

thank you for your comments.

We now have a -24 out that addresses the ones we hadn’t already addressed in -23, the changes are also in https://github.com/core-wg/yang-cbor/pull/169 .

Details below.

Grüße, Carsten


> On 2023-10-26, at 15:00, Éric Vyncke via Datatracker <[e-mail]> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-core-sid-22: No Objection
> […]
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-core-sid/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-shmoo-hackathon-07

:-)


> […]
> 
> # COMMENTS
> 
> ## Intended status
> 
> While I do like the intent of this draft, I am only uneasy about the intended
> status of "proposed standard", many mechanisms may face issues when put in real
> live: from global SID meta-range assignments to SID generation and use. Having
> an 'experimental' status would probably be better suited (and there is nothing
> wrong about an experimental I-D).

As usual, there are several components in this document, some of which are very much intended as proposed standards for interoperation (SID files), some of which are binding actors generating and acting on Standards-Track documents to a certain behavior (which can be on the spectrum between proposed standard and BCP).
We believe Proposed Standard provides the closest document category overall.

> ## YangCatalog.Org
> 
> As the previous YC.O liaison, please note that YC.O development efforts have
> culminated and there won't be any new features added to YC.O in the foreseeable
> future. I.e., even if there were plans 2-3-4 years ago to add SID features,
> this time has passed as this I-D was not published as a RFC. I.e., do not rely
> on YC.O.

Right.  yangcatalog.org always was meant as an example, but maybe it was time to remove this particular example.

https://github.com/core-wg/yang-cbor/pull/169/commits/261b376

> ## Section 1
> 
> `At the time of writing,` this won't age well. Please state "2023" or something
> similar.

Well, the time of writing doesn’t age (much, I hope) any more.
People who want to know when that was can look at the header.
“At the time of writing” combines the assignment of a date with an explanation of the reason for having that date, so we’d like to stick to that phrase.

> What is meant by `Once considered "stable"` ? This should be defined here or a
> forward reference to section 3 added.

We are in the introduction, which is by nature a grand forward reference to the rest of the document.
So, I’m happy we created curiosity here :-)
I would prefer to limit forward references from an introduction to a passage describing the structure of the document, which we don’t have (and, I believe, don’t need).

> ## Section 2.1
> 
> `immutably maps to EXACTLY one YANG name` what about the same YANG name but in
> a different revision ? AFAIK CBOR favours adjacent integers when doing
> compression, i.e., the same YANG name in different YANG module revision should
> not be immutable for compression sake. The text goes further on this topic.
> Moreover, AFAIK, a YANG name may change of type among revisions and may break
> interoperation (there is a good reason why YANG modules have a revision tag).

There are several potential objectives here.
Rob Wilton has constantly reminded us that we can’t have 100 % on all of them.
We opted to focus on the stable, simple bidirectional mapping between YANG names and SIDs — this means that SIDs cannot normally buffer the YANG model from the detrimental effects of changing YANG names (or the semantics assigned to them) during revisions.

> ## Section 2.2
> 
> `objective 3* (MUST):  the SID management system is independent from any module
> versioning.` see my comment above.

Similar response — we indeed have achieved this, but at the cost of not being able to enjoy a potential shielding function to mitigate (even gratuitous) changes to YANG names.

> ## Section 2.4
> 
> The types 1-2-3 could be better presented by defining them one by one rather
> than being distributed into several paragraphs.

We employ the literary device of an arc of suspense…

Seriously, we smeared this over six paragraphs, and the benefit is that each definition can take advantage of the detail of the previous one.
Since I otherwise like the exposition, I’d rather leave it alone.

> ## Section 3
> 
> What is meant by 'final' in `When the specification is advanced to a final
> document` ?

Section 3 indeed leaves this open; a definition specific to the IETF/IANA process is detailed in 6.4.3.
(The document has to cover both that process, which is nailed down to sufficient detail, and vendor or consortia processes that may place their own emphasis on process details.)

Since we are still in the process of explaining the lifecycle in Section 3, too much detail would detract from that explanation.

> ## Section 6.4.3
> 
> Thanks for updating this section from -21 to -22 (probably based on Rob
> Wilton's review). It is much clearer albeit I do not like too much the use of
> the term "team" in an IETF document (matter of taste -- no need to reply).

Noted (for the next I-D…)

> Now, this is also a drastic change in the I-D IMHO, should it go through
> another IETF Last Call ? I will trust the responsible AD on this topic.

For the authors, it maybe feels less drastic, as it mostly spells out what the DE “team” (sorry) has to do, also now being specific about type-1/2/3 (it does successfully get rid of the inadvisable approach of including the .sid file in the I-D).
I am personally happy with the transparency we had for this change, but I’ll also defer to the responsible AD.

> ## References
> 
> RFC 8792 should probably be normative as it is required to understand the
> appendix.

You are right.

https://github.com/core-wg/yang-cbor/pull/169
https://github.com/core-wg/yang-cbor/pull/169/commits/6944fc0