Re: [core] Éric Vyncke's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

> -----Original Message-----
> From: core <[e-mail]> On Behalf Of Éric Vyncke via
> Datatracker
> Sent: 14 July 2021 06:41
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: [core] Éric Vyncke's Discuss on draft-ietf-core-sid-16: (with DISCUSS
> and COMMENT)
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-core-sid-16: 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/iesg/statement/discuss-criteria.html
> for more information about 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:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document.
> 
> Please find below two blocking DISCUSS points (which are probably
> misunderstandings of mine), some non-blocking COMMENT points (but
> replies would
> be appreciated), and one nit.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> -- Section 3 --
> As a YANG model can have several YANG modules, was there a discussion in
> the WG
> whether the SID range is assigned per module or per model ? The IANA
> section
> seems to refer to an allocation per RFC, i.e., per model and not per module.

I presume that the allocation is done per module.

On this point, I think that it would be better to use the phrase "Rework YANG module" rather than "Rework YANG model" in the diagram in C.1.


> 
> -- Section 7.5.2 --
> AFAIK, many YANG modules are not originating at the IETF (Open Config,
> vendor
> specifics modules, ...). How can those non-IETF modules get a SID as the two
> ways to get a SID are based on RFC (if I understand correctly this section).
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> == COMMENTS ==
> 
> I will let my OPS and Management AD to comment on the use of 'YANG
> schema'
> rather than 'YANG module' and about the word 'item' for many YANG-
> related
> concepts.

This is a good point.  I missed it for this document, but planned to raise in my YANG CBOR encoding doc review.

This document talks about a schema-node path (pulling in the terms for schema node and schema tree from RFC 7950).  However, the SID file that has been generated does not seem to follow the schema tree, but instead, it leaves out any nodes in the schema tree that don't exist as data nodes, except for rpcs, actions, or notification nodes.   Specifically, I would not expect to see SIDs for 'case', 'choice', 'input' and 'output' nodes that exist in the YANG schema tree, but don’t exist in the YANG data tree.

So, I think that this document probably needs to:
 - Import "data node" from RFC 7950.
 - Update the description of the algorithm used to generate SIDs to indicate that the following "schema nodes" are elided from the 'schema path' that is generated ('choice', 'case', 'input', 'output'), but their child nodes are processed.  Or this could be stated in the reverse sense that SIDs should be defined for all data nodes and also "rpc", "notification", and "action" schema nodes.

This block of text in Appendix B also seems to be wrong:

   Note also that RPC or action "input" and "output" data nodes MUST
   always be assigned SIDs 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.

I don't think that you want to give "input" and "output" data nodes SIDs, because they don't appear in the data tree encoding, e.g., the YANG CBOR draft indicates that these are calculated relative to the RPC node itself, not the 'input' or 'output' nodes that don't appear in the data tree.

Thanks,
Rob


> 
> I know that Alex Pelov is an author but was there any discussion with LPWAN
> WG
> on this?
> 
> No need to reply but the use of ".sid" to qualify a file format reminded me of
> MS-DOS... ;-)
> 
> I am somehow concerned by having so many SIDs being generated as it
> requires
> being careful in generating them and having a scalability issue when using
> them
> as the 'mapping table' could become quite large.
> 
> -- Abstract --
> Suggest to add the reason why using SID in constrained environments for
> people
> outside of CORE WG ;-)
> 
> -- Section 4 --
> In addition to a reference to RFC 7951, why not simply adding that the the
> ".sid" file is encoded in JSON ?
> 
> -- Section 7.4.1 --
> Out of sheer curiosity, why using a decimal million rather than the usual
> power
> of 2 ? Again just out of curiosity ;-)
> 
> -- Section 7.5.3 --
> Suggest to either remove entries related to ietf-anima-constrained-voucher
> or
> move this I-D in the normative references section.
> 
> == NIT ==
> 
> -- Section 1 --
> Suggest to expand "YANG SID" again as the abstract is not really part of the
> document.
> 
> 
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core