[core] Roman Danyliw's Discuss on draft-ietf-core-sid-22: (with DISCUSS and COMMENT)

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

Roman Danyliw has entered the following ballot position for
draft-ietf-core-sid-22: 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/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/



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

** Section 6.4.3

   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.

Can the basis for this decision be explained.  Why isn't the authoritative
source of the SID's coming from the RFC?


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

(ballot revised based on telechat discussions)

** 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)?