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

[Carsten Bormann <[e-mail]>]

Hi Rob,

after a bit of radio silence, I went ahead and submitted draft-ietf-core-sid-20.
My detailed responses to DISCUSS and COMMENTS are below.
As I mentioned, with all the changes since -16, my view is that the WG chairs should consider doing another working-group last call and then do another publication request.
But we still would like to know whether we will run into the same DISCUSS!

Grüße, Carsten

> On 2023-01-18, at 14:33, Robert Wilton via Datatracker <[e-mail]> wrote:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-core-sid-19: Discuss
> 
> […]
> ----------------------------------------------------------------------
> 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.

The status field we introduced in PR #141 is meant to cover (1) “stable” and (2) “unstable”.
(3) didn’t quite cross our minds; this is now covered with a third status value, “obsolete”.

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

Right.  So the authority is with the authors of the YANG module.
The need to keep “stable” assignments actually stable needs to be communicated to them.

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

We added a status indication for the whole file:

    leaf sid-file-status {
      type enumeration {
         enum unpublished {
           description
             "This .sid file is unpublished [RFC8407], also called
              a work-in-progress or workfile.
              This may be when it accompanies an unpublished YANG
              module, or when only the .sid file itself is
              unpublished.
              The 'item' list MAY contain entries with a status
              value of 'unstable'.";
         }
         enum published {
           description
             "This .sid file is published, for a published YANG
              module. The 'item' list MUST NOT contain entries with
              a status value of 'unstable'.";
         }
      }
      default published;
    }


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

We now have taken the position that SIDs actually stand for the schema name; no semantics implied.

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

This should have been fixed in -19.

> (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 have moved to sx:structure

We still can’t validate the result with the tools we have at hand.

We are also not quite sure whether we have incurred another level of JSON structure.
Handling this might involve stripping that extraneous level before calling it a SID file.
(We do not want to change the overall structure of the SID file at this late stage.)

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

Megarange 0 is IANA, for IETF managed modules.
We would like to have one or more organizations like comi.space [1] for handling small fish; those web sites could get a megarange.
Individuals would obtain ranges for specific modules from that organization.
Obviously, larger organizations would get their own megaranges.

[1]: https://comi.space/

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

“Submodule” currently occurs in:

The terms imported from RFC 7950 (needs to stay)

The YANG descriptions of “module”, “identity”, and “feature”

That sentence in Appendix C.

The YANG descriptions for “identity” and “feature” sound OK to me.
I’m not quite sure I understand the one for “module” — where do submodules enter this discussion?