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

[Carsten Bormann <[e-mail]>]

Hi Rob,

> On 2023-12-15, at 11:29, Robert Wilton via Datatracker <[e-mail]> wrote:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-core-sid-23: No Objection

Thank you again for clearing the DISCUSSes, and for the COMMENTs below.

The changes below went into -24; they are also detailed in

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

Details below.

Grüße, Carsten

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> You can regard all of these comments as non-blocking (against -23):
> 
> 1. I think that the security reference to "The security and privacy
> considerations in Sections 5 and 6 of [I-D.bormann-t2trg-deref-id] apply." is
> somewhat dubious, since it would create a normative reference and block this
> doc and we don't know what they will eventually say.  Perhaps change this text
> to make this a softer recommendation, i.e., rather than they saying that they
> apply, say something like "please also see I-D.bormann-t2trg-deref-id for
> further considerations that may be applicable"?  This may then allow it the
> reference to bormann-t2trg-deref-id to be informational rather than normative
> (but I've not checked other usages).

We used your sentence (almost) literally, plus some text giving enough context:

>> SID files are identified with and can employ _dereferenceable
>> identifiers_, i.e., identifiers that could lead implementations in
>> certain situations to automatically perform a remote access the target
>> of which is indicated at least partially by those identifiers.
>> This can give an attacker information from and/or control over such
>> accesses, which can have security and privacy implications.
>> Please also see {{Sections 5 and 6 of -deref-id}}
>> for further considerations that may be applicable.

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

> 2. The type-1, type-2, type-3 developers are not referenced very much in the
> doc, and I wonder whether referencing by name wouldn't be more helpful for most
> readers, e.g., SID-guiding, SID-oblivious, SID-aware).

We kept the type-x classification but added the expansion (almost) everywhere it is being used.

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

> 3. The text in section 6.4.3, seems to be mostly written about drafts that are
> creating new YANG modules, and hence allocating new SID files.  There doesn't
> appear to be any text about new revisions of existing published YANG modules
> that would presumably also need to take into account any previously published
> SID file for that module previously published in IANA.

Indeed.

We introduced the term “reference SID file” and used it in an additional paragraph:

>> For YANG modules that are revisions of previously published modules,
>> any existing published SID file needs to serve as reference SID file
>> for the tool, either during generation of the revised draft (type-1,
>> type-2) or during generation of the final SID file (type-3).

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