Subject: [core] Benjamin Kaduk's No Objection on draft-ietf-core-sid-18: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 08 Dec 2021 11:57:10 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-sid-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-sid/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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]