Skip to main content

YANG Schema Item iDentifier (YANG SID)
draft-ietf-core-sid-18

Discuss


Yes

Francesca Palombini

No Objection

Erik Kline
John Scudder

No Record

Andrew Alston
Martin Duke
Paul Wouters
Warren Kumari

Summary: Has a DISCUSS. Needs one more YES or NO OBJECTION position to pass.

Robert Wilton Discuss

Discuss (2021-07-13 for -16)
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 (2021-07-13 for -16)
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.

Francesca Palombini Yes

Alvaro Retana No Objection

Comment (2021-07-13 for -16)
It caught my attention that the names of the editors in the module don't match the names of the document authors.  Is there a reason for that?

Erik Kline No Objection

John Scudder No Objection

Lars Eggert No Objection

Comment (2021-07-12 for -16)
Section 1. , paragraph 13, comment:
>    If the
>    meaning of an item changes, for example as a result from a non-
>    backward compatible update of the YANG module, a new SID SHOULD be
>    assigned to it.

Why is this not a MUST? When would it be OK to not use a new SID?

Section 4. , paragraph 21, comment:
>        reference
>          "[I-D.ietf-core-sid] YANG Schema Item iDentifier (YANG SID)";

Should the reference not be "RFC XXXX"? (Also below.)

Found terminology that should be reviewed for inclusivity:
 * Term "his"; alternatives might be "they", "them", "their".
 * Term "native"; alternatives might be "built-in", "fundamental",
   "ingrained", "intrinsic", "original".
See https://www.rfc-editor.org/part2/#inclusive_language for background and
more guidance.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1. , paragraph 2, nit:
-    unique identifier.  In both Network Configuration Protocol(NETCONF)
+    unique identifier.  In both Network Configuration Protocol (NETCONF)
+                                                              +

Section 3. , paragraph 1, nit:
> ANG module is optional but recommended to promote interoperability between d
>                            ^^^^^^^^^^^^^^^^^^^^^^
The verb "recommended" is used with the gerund form.

Section 4. , paragraph 32, nit:
> available value is entry-point and the the last available value in the range
>                                    ^^^^^^^
Two determiners in a row. Choose either "the" or "the".

Section 7.5.3. , paragraph 3, nit:
> istration. This process may be time consuming during a bootstrap period (ther
>                                ^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 7.5.3. , paragraph 3, nit:
>  will list the other allocations in it's description, and will be cross-post
>                                     ^^^^
Did you mean "its" (possessive pronoun) instead of "it's" (short for "it is")?

Section 7.5.3. , paragraph 3, nit:
>  module which references a module in an document which has not yet been adop
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Document references draft-ietf-core-yang-cbor-15, but -16 is the latest
available revision.

Document references draft-ietf-anima-constrained-voucher-11, but -12 is the
latest available revision.

These URLs in the document can probably be converted to HTTPS:
 * http://datatracker.ietf.org/wg/core/

Murray Kucherawy No Objection

Comment (2021-07-15 for -16)
Section 1:

It's a bit weird to have requirements language in an Introduction.

Section 7, generally:

Thanks for providing advice for the Designated Experts for each of the created registries.  This is a not-exactly-uncommon oversight.

Section 7.4.1:

* "The size of the registered SID block.  The size MUST be one million (1 000 000) SIDs." -- Seems a waste of a registry column if it's always this one value.  Maybe this should instead be the highest SID in the block?

* "The information associated to the Organization name should not be publicly visible in the registry, but should be available." -- Why not, and available how?

Section 7.5.2:

* "The maximum SID range size is 1000.  A larger size may be requested by the authors if this recommendation is considered insufficient." -- This is a contradiction.  Should "maximum" be "default"?

* "RFCs and by extension documents that are expected to become an RFC fulfill the requirement for "Specification Required" stated in..." -- I think you mean "RFC Required".

Roman Danyliw No Objection

Comment (2021-07-14 for -16)
I support the DISCUSS positions of Ben Kaduk, Éric Vyncke, and Rob Wilton.

** YANG module.  Typo. “list assignment-range”.  s/the the/the/

** Appendix B.  

Assignment of SIDs to YANG items can be automated, the recommended
   process to assign SIDs is as follows:

...
   4.  If the number of items exceeds the SID range(s) allocated to a
       YANG module, an extra range is added for subsequent assignments.

What’s the expected automated approach for adding extra ranges.  I was under the impression that getting more SIDs required an IANA request to allocate them them "YANG SID Range Registry"?

Zaheduzzaman Sarker (was Discuss) No Objection

Comment (2021-11-15 for -17)
Thanks for the addressing my DISCUSS in the -17 version of this document.

Éric Vyncke (was Discuss) No Objection

Comment (2021-10-19 for -16)
Thank you for the work put into this document.

Based on the authors’ reply, I have now cleared one of my previous blocking DISCUSS points (related to section 7.5.2 and other SDO / mega ranges see also https://mailarchive.ietf.org/arch/msg/core/SyG1Ax5V2KmYM8v1_CFOmghpUs0/ ). I have kept the previous DISCUSS points below for archive.

Please note that my COMMENT points are still unanswered as far as I can tell.

I hope that this helps to improve the document,

Regards,

-éric

== PREVIOUS DISCUSS ==

-- Section 3 --
As a YANG model can have several YANG modules, was there a discussion in the WG whether the SID range is assigned per module or per model ? The IANA section seems to refer to an allocation per RFC, i.e., per model and not per module.

-- Section 7.5.2 --
AFAIK, many YANG modules are not originating at the IETF (Open Config, vendor specifics modules, ...). How can those non-IETF modules get a SID as the two ways to get a SID are based on RFC (if I understand correctly this section).

== COMMENTS ==

I will let my OPS and Management AD to comment on the use of 'YANG schema' rather than 'YANG module' and about the word 'item' for many YANG-related concepts.

I know that Alex Pelov is an author but was there any discussion with LPWAN WG on this?

No need to reply but the use of ".sid" to qualify a file format reminded me of MS-DOS... ;-)

I am somehow concerned by having so many SIDs being generated as it requires being careful in generating them and having a scalability issue when using them as the 'mapping table' could become quite large.

-- Abstract --
Suggest to add the reason why using SID in constrained environments for people outside of CORE WG ;-)

-- Section 4 --
In addition to a reference to RFC 7951, why not simply adding that the the ".sid" file is encoded in JSON ?

-- Section 7.4.1 --
Out of sheer curiosity, why using a decimal million rather than the usual power of 2 ? Again just out of curiosity ;-)

-- Section 7.5.3 --
Suggest to either remove entries related to ietf-anima-constrained-voucher or move this I-D in the normative references section.

== NIT ==

-- Section 1 --
Suggest to expand "YANG SID" again as the abstract is not really part of the document.

Andrew Alston No Record

Martin Duke No Record

Paul Wouters No Record

Warren Kumari No Record

(Benjamin Kaduk; former steering group member) (was Discuss) No Objection

No Objection (2021-12-08)
Thanks for (largely) addressing my previous Discuss points!

Following up on what was previously my discuss point (3), I still see
MUST-level guidance to the expert in §7.5.2 to ensure that YANG items
are assigned the same SIDs as in any other ".sid" file that has
allocated SIDs for the YANG module in question.  It seems prudent to
qualify that on the YANG items having the same semantics as the already
allocated SIDs and/or refer to the discussion in Appendix B from this
location.

Section 7.4.3

   For a YANG module approved for publication as an RFC, a ".sid" file
   SHOULD be included in the Internet-Draft as a source code block.
   This ".sid" file is to be extracted by IANA/the expert reviewer and
   put into the YANG SID Registry (Section 7.5) along with the YANG
   module.  The ".sid" file MUST NOT be published as part of the RFC:
   the IANA Registry is authoritative and a link is to be inserted in
   the RFC.

Following up the "SHOULD be included in the I-D" with "is to be
extracted and put into the YANG SID registry" leaves some ambiguity
about what happens if the SHOULD is ignored (i.e., the ".sid" file is
not in the draft).  I think the intent is that something is created and
still goes into the YANG SID registry, but that might be worth
clarifying.

I'm also a bit ambivalent about using "MUST NOT" for "don't include the
".sid" file in the RFC" -- it's generally the right thing to do, but
who's it supposed to be binding on?  With no enforcement mechanism, it
might be easy to overlook, and what's the remedy if that happens?  It
also precludes any exceptional circumstance where we do feel a need to
put the file contents in the RFC.

Appendix A

The ruby one-liner provided to extract JSON from Figure 3 is really
evocative of the things people like to complain about perl code for.
I don't really know any Ruby, but have to ask if the quoting+escaping
is up to best practices for secure coding, and whether "\n" is going to
properly match line endings on all OSes.

[the following is retained from my previous ballot position]

Section 7.4.2

   In case a SID range is required before publishing the RFC due to
   implementations needing stable SID values, early allocation as
   defined in [BCP100] can be employed.  As specified in Section 4.6 of
   [RFC8126], RFCs and by extension documents that are expected to
   become an RFC fulfill the requirement for "Specification Required"
   stated in Section 2 of [BCP100], which allows for the early
   allocation process to be employed.

While the first bit of this is all true, the registry here doesn't use
the "Specification Required" policy for any range, and early allocations
are available for the "RFC Required" range.  So we should probably tweak
or remove the second sentence.
[ed. the response to my previous ballot position pointed to PR 103 but I
am failing to find a change that addressed this comment]