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

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-core-sid-22: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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

Thank you for the work put into this document. I still have fond memories about
this document when I was its shepherding AD for a while (replacing Francesca
during her leave) ;-)

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Jaime Jimenez for the *refreshed* shepherd's detailed
write-up including the WG consensus even of the justification of the intended
status could be more detailed.

Other thanks to Stephen Farrell, the IoT directorate reviewer (at my request),
please consider this IoT-dir review:
https://datatracker.ietf.org/doc/review-ietf-core-sid-21-iotdir-telechat-farrell-2023-10-06/
(thanks for the follow-up email messages on the use of the overloaded term
'identities')

Other thanks to Brian Haberman, the Internet directorate reviewer (at my
request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-core-sid-21-intdir-telechat-haberman-2023-10-13/
(and the SID collision is indeed unfortunate)

I hope that this review helps to improve the document,

Regards,

-éric

# 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).

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

## Section 1

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

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

## 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).

## Section 2.2

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

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

## Section 3

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

## 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).

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.

## References

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