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

[Carsten Bormann <[e-mail]>]

Hi Rob,

We have prepared an updated core-sid document at:

https://datatracker.ietf.org/doc/draft-ietf-core-sid/
https://www.ietf.org/archive/id/draft-ietf-core-sid-18.html
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-18.txt

> On 2021-07-13, at 17:59, Robert Wilton via Datatracker <[e-mail]> wrote:
> […]
> ----------------------------------------------------------------------
> 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.

We have toned down the need for allocating a new SID quite a bit; see updated appendix B.
The point of the text here is to say that existing allocations stay in place; the exceptions listed in Appendix B notwithstanding.

Now it seems to me that you are arguing for a more mechanistic rule: essentially a bijection between SIDs and (namespace, name) pairs.  This takes away the possibility to “optimize” the renaming of an identifier by keeping a SID, or a change in the semantics of a name by allocating a second SID.  But the rule would sure be simpler, and taking away some of the discretion now afforded in Appendix B by creating a simple mechanism.

(It would not be a very strict bijection — anyone can create a SID file for a module where one already exists, out of ignorance, malice, or technical reasons; the expectation is that owners of modules will want to make sure their SID file is prominent.)

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

We essentially removed submodules from the document (well, they are still in the term import list, because the parallel yang-cbor document needs to say:

>> Note that any structuring of modules into submodules is transparent to YANG-CBOR:
>> SIDs are not allocated for the names of submodules, and any
>> items within a submodule are effectively allocated SIDs as part of
>> processing the module that includes them.

).

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

We changed the ietf-sid-files module to use sx:structure (RFC 8791).
https://github.com/core-wg/yang-cbor/pull/116
(I don’t think we can validate the sid file example against the module after that change.
Can we?)

(The above is about the core-sid documents’s *use* of rc:yang—data migrating to sx:structure.
As far as showing sx:structure examples with encoding over in the yang-cbor document:
We plan to instead set up another follow-on document with such examples, rules for encoding metadata, etc.)

> (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?

The mega-range concept means there can be more than one such entity.
https://comi.space is a proof of concept for how such an entity could operate.
I’d expect at least one of the organizations in the YANG ecosystem to pick this up and become such an entity.
Whether IANA also wants to be such an entity (beyond its role for IETF modules), I don’t know.
To demonstrate that we are entirely on the safe side, I’ve also written a PoC for a organization-less approach (leveraging IANA PENs):
https://datatracker.ietf.org/doc/draft-bormann-core-yang-sid-pen/
I’m not sure we want to pursue this; the advantage is a low-threshold (and low-disclosure!) way to get a sizable SID space; the disadvantage is that we would lose people who otherwise would have used services such as comi.space that make the registrations much more useful to the community.

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

See above.
Do we still need text here, or is the text over in yang-cbor sufficient?

Grüße, Carsten