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

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-core-sid-21: 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:
----------------------------------------------------------------------

Hi authors,

Apologies for putting yet another discuss on this document - I promise that I
support it and want to see it published - but there are a couple of process
related aspects for creating/managing SID files in drafts that I want to ensure
that the IESG is at very least aware of and happy with.

(1) p 23, sec 6.4.3.  Publication of the ".sid" file

   For a YANG module approved for publication as an RFC, a ".sid" file
   SHOULD be included in the Internet-Draft as a source code block.

I'm wondering if this is really the best approach.  I.e., I think to guarantee
that the SID file is correct at the point of pulication (e.g., if names of YANG
data nodes are changed using IESG review or later) will probably require the
RFC-Editor (or IANA) to run some tooling to regenerate it and ensure that it is
correct.  Hence for YANG modules that are not being directly used in
constrained environments then would it be better to ask IANA (if they are
willing, and if the tooling is easy) to generate it during AUTH-48?  Note, this
discussion will presumably require IANA's input.

(2) p 27, sec 6.5.3.  Recursive Allocation of YANG SID Range at Document
Adoption

   *  If the document is a published RFC, then the allocation of SIDs
      for its referenced YANG modules is permanent.  The Expert Reviewer
      provides the generated ".sid" file to IANA for registration.  This
      process may be time-consuming during a bootstrap period (there are
      over 100 YANG modules to date, none of which have SID
      allocations), but should quiet down once needed entries are
      allocated.

Would it not be easier just to go through all the published RFCs containing
YANG modules and allocate SID files for them?


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

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

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

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

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

(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.  I wasn't quite sure what your use case was that needed these.

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

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

Regards,
Rob