[core] Roman Danyliw's No Objection on draft-ietf-core-sid-23: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-core-sid-23: 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/about/groups/iesg/statements/handling-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:
----------------------------------------------------------------------

(ballot revised based on telechat discussions; revised again after IESG
Discussion at IETF 118)

When initially balloting as DISCUSS, I had hesitation about treating SID files
differently than the YANG modules (i.e., would be end up with a clear technical
specification).  After publication of the RFC, the former only lives in the
IANA registry while the latter stays in the RFC and also goes into an IANA
registry.  For new documents (that will include a YANG file and SID file), I
believe there should consistency on how these models are handled.

In the IESG Review discussion (thanks Carsten Bormann and Rob Wilton), I heard
that perhaps YANG modules should never have been put into the RFCs to begin
with.  However, no wholistic approach currently exists to remedy this
arrangement.  I also heard the need for a workflow of creating SID files for
already published RFCs without making a substantial number of -bis documents or
one massive RFC update.  Thanks for that perspective.  I’ve cleared based on
this second issue.

====
** Section 2.4
     Objective 2 requires
      that there is only one SID assigner for each module.

While neither Objective 2 or this text uses formal normative language, by my
read, Objective 2 does not “require” anything.  It suggests since (“SHOULD”) is
used.

** Section 2.4  Editorial.  The text goes through the trouble of introducing
“type-1”, “type-2”, etc.  However, this taxonomy is not used later in the
document.  Is it needed?

** Section 5. The Security Considerations helpfully point out the criticality
of retrieving the SID files from an authoritative source.  How would that work
for an entity outside of the IETF?  The requirements of a “mega-range”
allocations include a few requirements, but nothing explicitly says
distribution of SID files.  Could something be said?

** Section 5.
   Conceptually, SID files could be processed by less-constrained target
   systems such as network management systems.  Such systems need to
   take extra care to make sure that they are only processing SID files
   from authoritative sources, as authoritative as the YANG modules that
   they are using.

Thanks for flagging this as a security consideration.  Rob Wilton also
mentioned it in his ballot.  I’m a puzzled by this use case.  Is this
suggesting that “less constrained … systems” would download SID files based on
some kind of real-time input?  If so, this seems highly problematic because (a)
it could leak information to an outside party; and (b) seems like it could
cause a DDoS on the distributor of the SID files or even the system itself
(depending on the caching strategy). Is the use case here that the SID file
would be distributed “offline” by the system vendor or operator through
configuration making it more akin to the developer use case mentioned
previously?  I appreciate that CBOR is intended to be self-describing, but I’m
not sure how a network management system would be parsing arbitrary formats.

** Section 6.3.3.  “iana.org” is provided as a URL for IANA, but that value is
technically not a valid URL (as it is missing a schema).

** Section 6.5.3
   After Working Group Adoption, any modification of a ".sid" file is
   expected to be discussed on the mailing list of the appropriate
   Working Groups.  Specific attention should be paid to implementers'
   opinion after Working Group Last Call if a SID value is to change its
   meaning.  In all cases, a ".sid" file and the SIDs associated with it
   are subject to change before the publication of an internet draft as
   an RFC.

This text is here to bring clarity to an important issue, but it isn’t clear to
me what it is.  The text appears to be describing what is true for any
significant change to a WG document.

** Section 6.5.3
   Due to the difficulty in changing SID values during IETF document
   processing, it is expected that most documents will ask for SID
   allocations using Early Allocations [BCP100].   The details of the
   Early Allocation should be included in any Working Group Adoption
   call.
...
  In all cases, a ".sid" file and the SIDs associated with it
   are subject to change before the publication of an internet draft as
   an RFC.

-- I have no experience with early allocation of an IANA code point happening
concurrent with a WG adoption of a document.  Is that common?

-- What difficulty is expected in changing SID values?

-- Why is early allocation happening if the draft is not stable (which seems
unlikely at adoption time)?