[core] Robert Wilton's Discuss on draft-ietf-core-sid-19: (with DISCUSS and COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-core-sid-19: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Updated discuss comments based on -19.

I think that my main concern is still how permanent or transient allocated SIDs
are, particularly when YANG modules are being developed.

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.

Regards,
Rob

Previous discuss comments:

There are a couple of points that I would like to see discussed and perhaps
addressed:

(1) I would like further discussion regarding whether SIDs are bound just to
the schema name, or the schema item definition.  The draft states that if the
definition is changed in a non-backwards-compatible (NBC) way then a new SID
SHOULD be allocated.  But I don't understand how this will work.  Given that
the .sid file would then contain exactly the same path but with different sids
assigned (for every time the meaning of the definition changes), then how do
consumers of the sid file know which sid to use for a given path (given that
there is no indication in the .sid file)?  Instead, I think that this is the
wrong way to be handling NBC changes, and SIDs should be bound only to the
schema path (i.e., the name of the item), and a new SID is only allocated if
the name/path changes, and otherwise the same SID is used, even if the
definition changes in a non-backwards-compatible way.

(2) I think that this document should be clearer as to the relationship between
SIDs and submodules (more details in the comment).

(3) This draft makes use of the rc:yang-data extension.  Was there any
discussion about using "YANG Data Structure Extensions" (RFC 8791) instead,
which is meant to be a cleaner formulation of the rc:yang-data extension, and
without the dependency on RESTCONF?  I would suggest that using RFC 8791 would
be preferable if possible.

(4) The policy in 7.4.2 for allocation a SID mega-range seems to aiming this
towards organizations rather than individuals.  The policy in 7.6 for the "IETF
YANG SID Registry" requires an RFC.  What is the mechanism if an individual or
open source project wanted to get SIDs assigned for some of their YANG modules?
 I.e., should we be defining a separate mega-range, managed by IANA, with just
Expert Review or Specification Required so that these modules could use SIDs
allocated?  Or do you envisage a separate entity taking up the responsibility
for coordinating this?

Regards,
Rob


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. Regarding the relationship between sids and submodules, I think is best
summed up by this comment in the appendix: "Note that ".sid" files can only be
generated for YANG modules and not for submodules."  I.e., I don't think that
sids should be allocated for the name of the submodule, and any items within a
submodule are effectively allocated sids as part of processing the module that
includes them.  This topic should be addressed early in the document, and
probably the existing references to submodule in the introduction and the YANG
module can be removed.