Ballot for draft-ietf-core-sid
Discuss
Yes
No Objection
Note: This ballot was opened for revision 16 and is now closed.
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".
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"?
Thanks for the addressing my DISCUSS in the -17 version of this document.
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.
Updated position for -20 (just for my tracking): (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)?
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?
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]
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/