[core] Review comments on draft-ietf-core-sid-19

["Rob Wilton (rwilton)" <[e-mail]>]

Hi,

Because I am holding a discuss on draft-ietf-core-sid, I was asked to review the latest version, primarily to see if it addresses my discuss concerns.

I still have discuss level concerns with the permanence or non-permanence of allocated SIDs, particularly when a new YANG module is being created.  I've updated the discuss ballot with the same text but have included it here along with other review comments on the -19 version of the draft.

In particular, I think that it would be helpful for the allocated SIDs to be split into two (maybe three) lists:
(1) Permanent allocations that MUST never change once allocated (e.g., if the schema path changes, the old entry is retained and no reallocated).
(2) Temporary allocations that could change, e.g., when a file is being developed (either using a separate temporary SID range, or part of the permanent SID space allocated to the module).
(3) The optional third section could be obsolete SIDs.  I.e., ones that cannot be reallocated to a different path, but software generating a mapping between SIDs and schema paths should be able to just ignore them.  Alternatively, rather than having a different section, entries could be marked with an obsolete flag in the permanent section instead.

When IETF drafts containing YANG modules are being developed or updated then the authors can decide whether new SIDs are allocated from the permanent or temporary sections depending on how stable they think parts of the model are.  But authors would only ever be allowed to renumber temporarily assigned SIDs.

I also think that having a global flag on the SID file would be helpful to define whether the file is the canonical SID file produced with permission of the module controller (owner) or generated by a third party.  This meta data may help consumers of SIDs understand their permanence.   Of course, there is not guarantee that the generated meta-data will necessarily be correct.


Moderate level comments:

(1) p 10, sec 4.  ".sid" file format

     structure sid-file:
       +-- module-name            yang:yang-identifier
       +-- module-revision?       revision-identifier

I would strongly encourage also allowing a revision label here, which may be a more meaningful revision identifier for a module. Alternatively, you could possibly use something like type revision-date-or-label from draft-ietf-netmod-yang-module-versioning


(2) p 22, sec 6.4.3.  Publication of the ".sid" file

   For a YANG module approved for publication as an RFC, a ".sid" file
   SHOULD be included in the Internet-Draft as a source code block.
   This ".sid" file is to be extracted by IANA/the expert reviewer and
   put into the YANG SID Registry (Section 6.5) along with the YANG
   module.  The ".sid" file MUST NOT be published as part of the RFC:
   the IANA Registry is authoritative and a link is to be inserted in
   the RFC.

This does depend on how good the tooling is that the authors are using (e.g., if the SID files can automatically be updated and included into the draft text), but perhaps storing a reference to the current SID file would be better than embedded the file in the draft directly.


(3) p 38, sec Appendix A.  ".sid" file example

   @u = %{[^"\n]*}; @q = @u + '"'
   puts ARGF.read.gsub(/^(#@q(#@q#@q)*#@u) *\n +(#@q)/, "\\1\\3")

Please use https://datatracker.ietf.org/doc/rfc8792/ instead.



Minor level comments:

(4) p 4, sec 1.1.  Terminology and Notation

   *  schema-node path: A schema-node path is a string that identifies a
      schema node within the schema tree.  A path consists of the list
      of consecutive schema node identifier(s) separated by slashes
      ("/").  Schema node identifier(s) are always listed from the top-
      level schema node up to the targeted schema node and could contain
      namespace information. (e.g. "/ietf-system:system-state/clock/
      current-datetime")

Perhaps module-name rather than namespace?  Normally with namespace I would naturally think of the XML namespace, and I don't think that is what you mean here?  Or move the "namespace-qualified form" description up and reference that.  I also note that you use namespace is other places in the draft, and it would probably be helpful to define what namespace means in this document (if not the same as the XML namespace referenced in RFC 7950).


(5) p 5, sec 2.  Objectives

   *  keeping an assignment regime that keeps short (2..4 byte) SIDs
      readily available for the applications that would benefit from
      them while at the same time employing the vast 63-bit SID space to
      facilitate permissionless actions.

Is this accomplished via the use of mega-ranges, and the first range allocated to IETF RFCs?


(6) p 5, sec 2.  Objectives

   *  maintaining some locality in the assignment of SIDs so the
      efficiencies of the SID delta mechanism can be fully employed.

Do you need a reference to the SID delta mechanism?


(7) p 5, sec 2.1.  Technical Objectives

   *Objective 1* (MUST):  any 63-bit unsigned integer is either
      unassigned as a SID or immutably maps to EXACTLY one YANG name.
      Only the transition from unassigned to that immutable mapping is
      defined.

Do you mean "YANG Name" here, or would "Schema Path" be more appropriate?


(8) p 7, sec 2.4.  Parties and Roles

   module controller:
      The owner of the YANG module, i.e., the controller about its
      evolution.

Why not call them the "module owner" rather than controller?


(9) p 19, sec 6.3.2.  Allocation policy

   If a size of the allocation beyond 1 000 000 is desired, the
   organization must demonstrate the sustainability of the technical
   approach for utilizing this size of allocation and how it does not
   negatively impact the overall usability of the SID allocation
   mechanisms; such allocations are preferably placed in the space above
   4 295 000 000 (64-bit space).

Given the 63-bit SID space is so vast, I think that it may be wise to reserve some bits at the top for future innovation.  E.g., you could start by limiting the SID allocation to only the lower 48 bits, which would still leave space for 281 million mega ranges but keeps 15 or 16 bits free for future innovation, and the space could always be allocated back to SIDs if needed.


(10) p 20, sec 6.4.2.  Allocation policy

   *  The range of 0 to 999 (size 1000) is subject to "IESG Approval" as
      defined in [RFC8126]; of these, SID value 0 has been reserved for
      implementations to internally signify the absence of a SID number
      and does not occur in interchange.

I'm not sure whether IESG Approval is really helpful here (specifically, I don't know if the IESG will be qualified to know whether a particular allocation is a good use of this space).  Hence, I would suggest that it would be better to make this Standards Action or IETF review and explain under what circumstances this space could be used/allocated (presumably where a small SID is particularly helpful or would improve encoding efficiency).


(11) p 26, sec 6.5.3.  Recursive Allocation of YANG SID Range at Document Adoption

   *  If the document is an unprocessed Internet-Draft adopted in a WG,
      then an Early Allocation is performed for this document as well.
      Early Allocations require approval by an IESG Area Director.  An
      early allocation which requires additional allocations will list
      the other allocations in its description, and will be cross-posted
      to the any other working group mailing lists.
   *  A YANG module which references a module in a document which has
      not yet been adopted by any working group will be unable to
      perform an Early Allocation for that other document until it is
      adopted by a working group.  As described in [BCP100], an AD
      Sponsored document acts as if it had a working group.  The
      approving AD may also exempt a document from this policy by
      agreeing to AD Sponsor the document.

I think that this entire process depends on whether the target of the YANG module is likely to be used for constrained devices, and also how sensitive the consumers of the module are to the SIDs changing (e.g., perhaps some implementations will include permanently allocated SIDs as source code constants) or rely on them for interoperability.  For modules that are not specifically targeted to where SIDs are being used, and no-one is requesting them, then delaying the allocation as late as possible in the standardization process, i.e., specifically, once the draft has IESG approval, may be most pragmatic.  Prior to that, in some cases, no SID file will be necessary, or in other cases, SIDs could be assigned from some temporary space so that they can be renumbered once approved.


(12) p 38, sec Appendix B.  SID auto generation

Is this section of the document still normative rather than informative?  It may be helpful to be explicit.


(13) p 39, sec Appendix B.  SID auto generation

     If the meaning of an item changes, a new SID
   MAY be assigned to it; this is particularly useful to allow the new
   SID to identify the new structure or semantics of the item.

I don't think that we should be allowing or recommending this.  Either an allocated SID should be stable for a given schema path, or it isn't stable, in which case it could change for any reason (e.g., renumbering between draft revisions).


(14) p 39, sec Appendix B.  SID auto generation

     If the
   YANG data type changes in a new revision of a published module, such
   that the resulting CBOR encoding is changed, then implementations
   will be aided significantly if a new SID is assigned.

Perhaps 'may be aided' rather than 'will be aided significantly'.  My concern here is creating a tension, or expectation, between authors and consumers of modules under development in SDOs (particularly the IETF).  As per my previous comment, I think that this should just come down to whether an allocated SID is permanent or not.  Allowing renumbering of non-permanent SIDs to be customized to minimize churn is okay, but I don't think that this should be the expectation or the norm.


(15) p 39, sec Appendix B.  SID auto generation

   In case of an update to an existing ".sid" file, an additional step
   is needed that increments the ".sid" file version number.  If there
   was no version number in the previous version of the ".sid" file, 0
   is assumed as the version number of the old version of the ".sid"
   file and the version number is 1 for the new ".sid" file.  Apart from
   that, changes of ".sid" files can also be automated using the same
   method described above, only unassigned YANG items are processed at
   step #3.

I presume that this should be very rare.  I.e., given that a particular YANG revision is immutable, then requiring an updated version of a SID file for the same revision of the YANG module should presumably only be done if there was a mistake in the previously generated SID file for that revision.  I would suggest moving the text about SID files being tied to a specific module-revision above this paragraph that seems to cover more of a corner case, and perhaps emphasise that this is only needed/used to fix errors in SID generation.


(16) p 39, sec Appendix B.  SID auto generation

   Already existing items in the ".sid" file should not be
   given new SIDs.

This text seems to somewhat conflict with was stated in the previous paragraph that allowed for this.


(17) p 41, sec Appendix C.  ".sid" file lifecycle

   The following Activity diagram summarizes the update of a YANG module
   and its associated ".sid" file.

It might be helpful for the IANA registration to reference section 6.5.



Nit level comments:

(18) p 0, sec: abstract 

   YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit
   unsigned integers used to identify YANG items, as a more compact
   method to identify YANG items that can be used for efficiency and in
   constrained environments (RFC 7228).  This document defines the
   semantics, the registration, and assignment processes of YANG SIDs
   for IETF managed YANG modules.  To enable the implementation of these
   processes, this document also defines a file format used to persist
   and publish assigned YANG SIDs.

the registration -> registration

Regards,
Rob