Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-21: (with DISCUSS and COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Rob,

let me try to address your COMMENTs below.

All changes below are part of
https://github.com/core-wg/yang-cbor/pull/158

(I’m using a slightly abbreviated review cycle here because of the impending I-D deadline; co-authors/WG members please speak up if these changes are not good.)

Grüße, Carsten


> On 2023-10-19, at 13:15, Robert Wilton via Datatracker <[e-mail]> wrote:
> […]
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-core-sid/
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> You can regard all of these comments as non-blocking:
> 
> Minor level comments:
> 
> (3) p 4, sec 1.1.  Terminology and Notation
> 
>   *  schema-node path: A schema-node path is a string that identifies a
>      schema node within the schema tree.  A path consists of the list
>      of consecutive schema node identifier(s) separated by slashes
>      ("/").  Schema node identifier(s) are always listed from the top-
>      level schema node up to the targeted schema node and could contain
>      namespace information. (e.g. "/ietf-system:system-state/clock/
>      current-datetime")
> 
> BTW, is this definition the same or different to "6.5 Schema Node Identifier in
> RFC 7950"?

I’m afraid we haven’t quite achieved consistent terminology here.

The term “schema-node path” is defined but then actually not used in the text; its definition uses "schema node identifiers” for the individual path components.
7950’s schema node identifier is a full path.
The term “SID” is expanded as YANG Schema Item iDentifier (the numeric version); in RFC 9254 we simply use “name” as the equivalent text form; here we generally use “YANG name” to refer to these names.
I’m not sure the rules for when to place namespace qualifiers in name components are exactly the same between Section 3.3 of RFC 9254 and RFC 7950 (I think RFC 9254 names are related to the names in Section 4 of RFC 7951 instead).

So, given that it is not actually used in the text, I think the best approach here is to remove this definition (as well as "namespace-qualified form", which also isn’t used) and add one for "YANG name”, with “see also” added to Section 3.2 and 3.3, resp., of RFC 9254 (which is an informative reference).

Now in
204823c

> (4) p 15, sec 4.  ".sid" file format
> 
>         description
>           "Information about the used revision during the .sid file
>           generation of each YANG module that the module in
>           'module-name' imported.";
> 
> "revision used" rather than "used revision"?

Fixed in
45daff4

> 
> (5) p 15, sec 4.  ".sid" file format
> 
>         description
>           "Information about the used revision during the .sid file
>           generation of each YANG module that the module in
>           'module-name' imported.";
> 
> I suspect that this will potentially introduce an itneresting case in the
> future where updating the grouping in an imported module will need the SID
> files for all the importing SID files that use that grouping to be regenerated.
> "sid-file-version" would seem to handle this case nicely.

It would indeed be interesting to generate an example for this case.

> (6) p 19, sec 5.  Security Considerations
> 
>   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.
> 
> As a minor comment, and I'll leave it to the SEC ADs to decide whether they
> think that this may be issue, but I wonder if there is a small privacy
> consideration here that may be worth documenting?  

Absolutely.

> E.g., if SID files were
> fetched dynamically rather than by being fetched offline by a developer or
> being cached locally, then there is a possibility that tracking which SID files
> are being requested may indirectly leak information about which models are
> being used.

Indeed.  I have written draft-bormann-t2trg-deref-id [1] to collect related considerations [2].  I’d rather reference a more detailed elaboration of the issues instead of putting in something abbreviated here.  So I added a reference to [2] to the security considerations, now in
e5f4d48

[1]: https://www.ietf.org/archive/id/draft-bormann-t2trg-deref-id-01.html
[2]: https://www.ietf.org/archive/id/draft-bormann-t2trg-deref-id-01.html#name-privacy-considerations

> 
> (7) p 21, sec 6.3.2.  Allocation policy
> 
>   *  Technical capacity to ensure the sustained operation of the
>      registry for a period of at least 5 years.  If Private
>      Registrations are allowed, the period must be of at least 10
>      years.
> 
> This criteria may be hard to evaluate.  E.g., if a startup company was to ask
> for a mega-range then would it be refused because they may go bust?

The list gives the requesting organization a set of items to demonstrate.
Whether this has happened definitely is a matter of judgement.
I think the important thing here is that Joe’s bait and SID shop will need to explain how their operation can be sustainable.
Using open-source tools, websites maintained by very large entities (say, github), and legal provisions that handle leaving the business in an appropriate way can be part of that argument.

> (8) p 41, sec Appendix B.  SID auto generation
> 
>   Note also that RPC or action "input" and "output" data nodes MUST
>   always be assigned SID even if they don't contain data nodes.  The
>   reason for this requirement is that other modules can augment the
>   given module and those SIDs might be necessary.
> 
> Do you mean "data node" here or "schema node".  Specifically, the "input" and
> "output" nodes themselves are not data nodes because they don't appear in the
> data tree.  

Replaced by “YANG item”.
8d24e89

> I wasn't quite sure what your use case was that needed these.

The use case is Section 3.6 of RFC 8040.
Here YANG items are used for input and output.
We want to have SIDs for using YANG-CBOR with RESTCONF.
(CORECONF doesn’t use the YANG items for the input and output schema nodes.)

> (9) p 43, sec Appendix C.  ".sid" file lifecycle
> 
>                       Figure 4: SID Lifecycle
> 
> Your SID lifecycle had "Open specification" being added to the IANA registry
> for SID files, but your IANA policy in 6.4.2 is effectively RFC required, and
> doesn't obviously allow for stable allocation for modules not defined in RFCs.

We originally had a slightly more open-door view of what IANA could do here, but indeed that is now gone from 6.4.2.

Figure updated
e5578ee

> Nit level comments:
> 
> (10) p 18, sec 4.  ".sid" file format
> 
>             If the corresponding 'namespace' field is 'data',
>             then this field MUST contain a valid schema node
>             path.";
>         }
> 
> "schema node path" => "schema-node path"?

part of 
45daff4