Subject: [core] Review of draft-ietf-core-sid-15

From: Francesca Palombini <[email-masked]>
Date: Wed, 24 Feb 2021 12:40:03 +0000

Thanks for the work on this document. I have reviewed it and have some comments. Please handle these comments together with the Last Call comments.

Chairs: I believe it would make sense to request a review from YANG Doctors for this document. Let me know if you need help setting that up.

Thanks,
Francesca

==

Section 1:

   SIDs are assigned permanently, items introduced by a new revision of
   a YANG module are added to the list of SIDs already assigned.  If the
   meaning of an item changes, for example as a result from a non-
   backward compatible update of the YANG module, a new SID should be
   assigned to it.

should or SHOULD? In general it is not clear to me when it makes sense for SID need to be re-registered and when they don't, maybe some examples would be useful.

==

Section 3:

   Each time a YANG module or one of its imported module(s) or included
   sub-module(s) is updated, a new ".sid" file MAY need to be created.

Maybe s/MAY need to/MAY. I assume this is application specific if the new .sid file is created or not, so you are leaving it somewhat optional, is that correct? Might be good to clarify.

==

Section 7: IANA is going to ask where to create the registries. Could this be under yang-parameters or does it need a new registry?

==

Section 7.4: Because the policy is expert review, I wonder if a change controller field should be added (see RFC 8126)

   When creating a new registry with Expert Review as the registration
   policy, in addition to the contact person field or reference, the
   registry should contain a field for change controller.  Having a
   change controller for each entry for these types of registrations
   makes authorization of future modifications more clear.

==

Section 7.5.3 Includes initial entries for the registry that are not consistent with the guideline: 

+  "Expert Review" [RFC8126] in case the ".sid" file comes from
            a YANG module from an existing RFC, or

since some of these points are registered from drafts. Should the WG do early allocation of those?

==

Nits

- expand acronyms on first use ( e.g. NETCONF, RPC, see https://www.rfc-editor.org/materials/abbrev.expansion.txt )