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

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

Robert Wilton has entered the following ballot position for
draft-ietf-core-sid-16: 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/iesg/statement/discuss-criteria.html
for more information about 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,

Thank you for this work, I believe that it likely to be useful, perhaps not
only for constrained devices, it may also turn out to be popular for streaming
telemetry.

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.