[core] Benjamin Kaduk's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-sid-16: Discuss

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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) I think there is a new security consideration with this work that is
important to document clearly -- not only do we define a new type of
identifier, but we define a file format and other mechanisms for
disseminating that information.  An entity that's processing
application/yang-data+cbor; id=sid information needs to ensure that the
.sid files (or other source of SID information) it uses for such
processing came from a trustworthy authority (or at least the same
source as the data file).  It would be possible for malicious
manipulation of .sid file contents to cause a message recipient to
mis-interpret the received message without any indication of such
tampering.

(2) Per §7.4.2, YANG SID range registries with public ranges MUST
include a reference to the ".sid" file for such ranges, but the
IANA-managed YANG SID range registry established by §7.5 does not, in
and of itself, make such a provision.  This function seems to be served
by the "IETF YANG SIG Registry" created by §7.6, so we may just need to
point to the one registry from the other in order to remain internally
consistent.

(3) There may be another inconsistency to look into; Section 7.6.2 says
that:

   *  If another ".sid" file has already allocated SIDs for this YANG
      module (e.g. for older or newer versions of the YANG module), the
      YANG items are assigned the same SIDs as in the other ".sid" file.

But we are supposed to allocate a new SID for a YANG item if its
semantics change in a revision of the YANG module.  Perhaps it's just
the "for older or newer versions of the YANG module" phrase that needs
tweaking?


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

The yangdoctors review mentioned the structure extension from RFC 8791,
and the authors (understandably) expressed reluctance to make such a
large change at this stage in the process.  I'll note that the DOTS WG
has recently completed work on a "bis" of RFC 8782, with primary aim of
replacing yang-data with structures and minimal other changes.  (A
yangdoctors review of a related document was sufficiently insistent that
structures are the right way to do this that the WG was convinced to put
in the effort.)

The yangdoctors review also asked why sid-file/module-name is optional,
which was tagged for follow-up.  I have the same question and am
interested in the outcome of the discussion amongst the authors.

If SIDs are supposed to be globally unique identifiers, the reference in
the YANG module to "namespace" identifiers for individual allocations is
puzzling to me.  The presence of a namespace would typically allow for
identifier reuse across namespaces (e.g., using the same SID integer value
for an identity and a data node within the same module).  I see how the
current list structure makes it easy to have a single flat list of all
identifier/sid mappings, but if the SIDs truly are globally unique, then
the "namespace" should not be a list key, and might be less confusingly
described as just indicating the type for which the SID is used.  (It
would also be possible to have separate lists for module SIDs, identity
SIDs, etc., but it's not clear that doing so is actually the right
approach.)

Section 1

   [...] 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.  A new SID MUST always be assigned if the new meaning
   of the item is going to be referenced using a SID.

That predicate seems in general unknowable ("you can't prove a
negative", etc.), so it's tempting to just require that if the old
semantics had a SID that the new semantics get one as well.

Section 4

If the scope of a sid-file-version-identifier resets when the module
revision is bumped, it seems highly unlikely that we'll need 64 bits of
identifier for it.

Section 5, 7.3

It's not entirely clear that we need to mention the
content-type/content-format in this document, as we only indicate use of
the JSON encoding for the .sid file and the use of SIDs in the
application/yang-data+cbor; id=sid case seems adequately described by
the existing treatment in draft-ietf-core-yang-cbor.

Section 7.4.1

I appreciate that the "mega-range" allocations are sized for the
appropriate SI prefix :)

   The information associated to the Organization name should not be
   publicly visible in the registry, but should be available.  This
   information includes contact email and phone number and change
   controller email and phone number.

Available to whom?

Section 7.5.2

   The size of the SID range allocated for a YANG module is recommended
   to be a multiple of 50 and to be at least 33% above the current
   number of YANG items.  This headroom allows assignment within the
   same range of new YANG items introduced by subsequent revisions.  The
   maximum SID range size is 1000.  A larger size may be requested by
   the authors if this recommendation is considered insufficient.  [...]

If there's a maximum size for a range, then asking for a larger one is
pointless.  Please reword to indicate the actual intent (maybe
s/maximum/typical expected/ or similar).

   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.

Section 7.6.3

   Early Allocations are made with a one-year period, after which they
   are expired.  [BCP100] indicates that at most one renewal may be
   made.  For the SID allocation a far more lenient stance is desired.

   1.  An extension of a referencing documents Early Allocation should
       update any referenced Early Allocations to expire no sooner than
       the referencing document.

   2.  The [BCP100] mechanism allows the IESG to provide a second
       renewal, and such an event may prompt some thought about how the
       collection of documents are being processed.

The first point is rather curious, since it can have no normative force
(this is not a BCP that would override BCP 100) and is merely a
continnation of how a more lenient stance is desired.  It's rather odd
to see it written in this way.  The second point seems to be the only
really useful part, and in practice this IESG approval of second (and
more!) renewals has become rather common, to the extent where a revision
of BCP 100 has been discussed to change the discussion of extensions for
early renewals.

   This is driven by the very generous size of the SID space and the
   often complex and deep dependencies of YANG modules.  Often a core
   module with many dependencies will undergo extensive review, delaying
   the publication of other documents.

Having many *dependencies* and taking a while shouldn't delay
publication of anything else; however, having many other modules
dependent on a core module would be likely to do so.

Appendix A

IIRC the mismatch between "[e-mail]" and the toplevel
"module-revision" of "2020-02-05" was noted by an earlier reviewer, but
I'll mention it here just in case I do not remember correctly.

NITS

Section 1

   SIDs are assigned permanently, items introduced by a new revision of
   a YANG module are added to the list of SIDs already assigned.  If the

comma splice

Section 5

        Each .sid file contains the mapping between the different
        string identifiers defined by a YANG module and a
        corresponding numeric value called YANG SID.";

singular/plural mismatch "numeric value called YANG SID"/"string
identifiers"