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

[Carsten Bormann <[e-mail]>]

Hi Rob,

On 2023-03-17, at 15:09, Rob Wilton (rwilton) <[e-mail]> wrote:
> 
> Hi Carsten,
> 
> It is very close.  I agree with your strategy of doing any WG LC and publication request.    There is one point that wasn't clear to me in -20 that I would probably end up putting a DISCUSS on, but I presume that it is an oversight:
> 
> (1) p 9, sec 3.  ".sid" file lifecycle
> 
>                                               When the specification is
>   advanced to a final document, then status of the assignment is marked
>   with the module-revision (a YYYY-MM-DD) when the assignment is
>   finalized.
> 
> This text wasn't clear to me, since I interpreted this as a per SID module-revision, but the YANG module doesn't include such a field.  Was this idea dropped, or is the assignment logically done at the SID file level (which is also fine with me)?

This was indeed uncovered in the parallel repeat WGLC the chairs were running, and is fixed in the current editors' draft:

>> When the specification is advanced to a final document, then
>> the assignment is marked with a status of "stable".


> Whilst reviewing, I also had some other comments/clarifications, but I would think that you can treat these as regular, non-blocking, WG last-call comments:
> 
> Minor level comments:
> 
> (2) p 14, sec 4.  ".sid" file format
> 
>       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'.";
>            }
> 
> I think that this means that tooling (e.g., YANG Catalog) may want to track two versions of SID files for a module:
> (i) The latest published version, that only contains stable SIDs.
> (ii) The latest 'unpublished' version, that also contains the unstable SID assignments.
> 
> I don't know if you want to mention this in section 2, or you may decide that this is outside the scope of this specification, as per the last paragraph of section 2.

I think this is a good observation, which should fit well in Section 3.
I have added to the end of the fourth paragraph:

>> During the period of development, two variants of the SID file should
>> be made available by the tooling involved in that development: (1) a
>> "published" SID file with the existing stable SID assignments only, as
>> well as (2) an "unpublished" SID file that also contains the unstable
>> SID assignments.

Now in fd57279 in PR #

> (3) p 17, sec 4.  ".sid" file format
> 
>           description
>             "The status field contains information about the stability
>              of the allocation.  For each specific SID value, over time
>              it can only transition from unstable to stable,
>              and possibly from stable to obsolete.";
> 
> What happens to an unstable SID that is allocated during a development version, but ends up not being needed in the stable published version:
>  (i) Is it okay for this SID to just be deleted?
>  (ii) Is it okay for this SID to be assigned to a different stable path?
>  (iii) Or does this SID get moved to obsolete?
> 
> Actually, I see that there is some text in section 3 that covers this.  My understanding is that the answer to my questions are, 1. Yes, 2. Yes, 3. No.  

Those are the “if everything goes well” (a.k.a. process confabulation) answers.
I think there may be (undesirable) circumstances where SIDs go directly from unstable to obsolete.
Maybe the description under item/status is a little too strong.
I’m not sure that we should dwell too much on these realities.

> If so, then I think that you may want to expand that unstable is also allowed to be removed (i.e., become unallocated again), and hence potentially be used for a different YANG schema name/path.

That is indeed a good addition.

I expanded the sentence on “unstable” in §3 to:

>> These provisional assignments are marked with a status of "unstable",
>> so that they can be removed and the SID number possibly be reassigned
>> for a different YANG schema name/path later during development.

Thank you for these comments!

The WGLC ended yesterday and provided some good comments, so for the changes here and for the WGLC comments, there will be a -21 with a few more fine adjustments before the IETF last-call button is pushed again.
I hope the I-D moratorium doesn’t get in the way.

Grüße, Carsten


> 
> Regards,
> Rob
> 
> 
>> -----Original Message-----
>> From: iesg <[e-mail]> On Behalf Of Carsten Bormann
>> Sent: 01 March 2023 13:37
>> To: Rob Wilton (rwilton) <[e-mail]>
>> Cc: The IESG <[e-mail]>; [e-mail]; core-
>> [e-mail]; [e-mail] WG ([e-mail]) <[e-mail]>;
>> [e-mail]
>> Subject: Re: Robert Wilton's Discuss on draft-ietf-core-sid-19: (with DISCUSS
>> and COMMENT)
>> 
>> 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?