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

[Carsten Bormann <[e-mail]>]

Hi Roman,

thank you for this review!
The changes I am proposing to address your comments are in

https://github.com/core-wg/yang-cbor/pull/162

Details are below.

Grüße, Carsten


> On 2023-10-25, at 03:41, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-core-sid-22: No Objection
> […]
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-core-sid/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ** 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.

s/requires that there is/aims at having/

Now
47c4565

> 
> ** 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 believe these terms (and its spelled-out forms) are useful terminology that can be used in discussing how to proceed with the development of a module.
The terminology is also used later in this document in 6.4.3 and 6.5.3.

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

Good point.

I added

* 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 {{security-considerations}}).

to 6.3.2.

Now
fa3d23c

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

We already added a pointer to the privacy considerations written up in draft-bormann-t2trg-deref-id; maybe we should point to the security considerations as well.

Now
0352d10

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

This is less of a fully fleshed out use case than a reminder that if you do anything slightly innovative here, you need to take the same care about SID files you take about YANG modules.

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

It sure can *parse* YANG-CBOR without a SID file; it just won’t know what YANG names the YANG SIDs stand for, just as it wouldn’t know what the YANG names mean without a YANG module.

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

Now
6548405

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

Yes.  We could say »any modification of a ".sid” file is a significant change to the document«, but then people would ask what we mean with this…

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

Well, not exactly “with adoption”, but the adoption should be done in the knowledge of what early allocations are going to come after adoption.

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

That depends on how heavily implemented the draft specification will be, and what trail of desirable constraints on the final SID allocation this produces.

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

It indeed should only happen once the draft reaches a state like “implementation draft” (a state that the standards process does not explicitly call out, but may be part of the WG process).
(WGs might differ in how far the milestones of document adoption and blessing a document as an implementation draft will be apart.)