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

[Carsten Bormann <[e-mail]>]

Hi Roman,

below please find an overview of how we have dealt with the COMMENTs still in the tracker; these changes are in the -24 revision of the draft (and those that weren’t already in -23 are detailed in https://github.com/core-wg/yang-cbor/pull/168 now).

Grüße, Carsten

> On 2023-11-08, at 14:38, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-core-sid-23: No Objection
> 
> ----------------------------------------------------------------------
> 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.

We went for “Objective 2 aims at having...”.

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

We think it is great for conversational use outside the document, so we kept it.
However, we also added expansions of the terms where they are used later in 6.4.3.

https://github.com/core-wg/yang-cbor/pull/167/commits/fcebeaa

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

Indeed, mega-range registries are not required to provide SID files (or the YANG files these go with).
We do say (6.3.2):

     -  Type: Public or Private

        o  Public Ranges MUST include at least a reference to the YANG
           module and ".sid" files for that YANG SID Range (e.g.,
           compare Section 6.4.3 for the IETF YANG SID registry).

        o  Private Ranges MUST be marked as “private"

… but this doesn’t mean the reference needs to go back to the mega-range operator.  Also, we require:

  *  Technical capacity to provide or refer to ".sid" files in a way
     that meets the security objective of data integrity for these
     files (see also Section 5).

We could define a Web API that all mega-range operators have to provide (about the only way this could be fully automatic), but today we don’t even require something like that of IANA.

I think the general issue of providing integrity-protected access to stable data files that go with specifications and registrations needs to be addressed between IETF, IANA, and third parties (see also the ongoing discussion about providing exported data files from RFCs and I-Ds as I do in an experimental way [1]).

[1]: <https://mailarchive.ietf.org/arch/msg/rfc-interest/u0JUp8Hw4DrMFF9Uv9XEArQDfNg>

In other words, I think we are as good here as we reasonably can be.

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

Possibly, for instance if they find (name) references to modules in a yang-library provided by a server.

> 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.

The YANG ecosystem provides enough ways to deal with management information for which model information is provided dynamically, so it does make sense to discuss this briefly in the security considerations.

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

(fixed in -23)

> ** 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.

Indeed.  The text is based on a development model where documents do not have a single transition from “fully fluid” to “frozen rock hard”, but go through various gelling levels; the attention requested here is desirable to minimize pain from gratuitous changes (changes that look exactly the same as those made for a good reason).

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

For SID ranges, it probably will be common to do an early allocation soon after the data model is sufficiently stable (certainly not *before* WG adoption).

We neglected to say that this is about the SID ranges, and that the details will include a view of when it may become time to request the early allocation.
So we propose to change:

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
+it is expected that most documents will ask for SID range allocations using Early
+Allocations {{BCP100}}. The details of the Early Allocation to be
+requested, including the timeline envisioned, should be included
in any Working Group Adoption call. Prior to Working Group Adoption, an internet
draft author can use the experimental SID range (as per
{{ietf-iana-sid-range-allocation-policy}}) for their SIDs allocations or

https://github.com/core-wg/yang-cbor/pull/168/commits/d2054ab

> -- What difficulty is expected in changing SID values?

Some hurt for people who place too much dependence on them not changing.
(On the other hand, we *want* people to implement from drafts, so we should strive to minimize that pain.)

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

We would start with an early allocation for the SID range, which probably can be stable unless the size of the module changes drastically.