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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 13 Jul 2021 22:41:17 -0700

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

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

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.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 14 Jul 2021 11:04:50 +0000

> -----Original Message-----
> From: core <[email-masked]> On Behalf Of Éric Vyncke via
> Datatracker
> Sent: 14 July 2021 06:41
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [core] Éric Vyncke's Discuss on draft-ietf-core-sid-16: (with DISCUSS
> and COMMENT)
> 

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.

> ways to get a SID are based on RFC (if I understand correctly this section).

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

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Jul 2021 11:15:11 -0400

> ways to get a SID are based on RFC (if I understand correctly this section).

{Speaking as an interesting party who has a SID dependancy in
draft-ietf-anima-constrained-voucher, and who are doing interop next week
during the hackathon...}

The original intention was that there would be multiple providers of SIDs via
mega-range allocations (7.4), and that most major entities would allocate
that way.  I see no reason why larger vendors couldn't allocate that as well.
Section 7.4 is Expert Review.

The authors originally operated a web interface, and were hoping to hand that
to IANA and/or secretariat.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Jul 2021 22:56:59 +0200

> to IANA and/or secretariat.

That interface is still there:

https://comi.space

I just got myself a SID range of 1000 SIDs at 1010000.
Obviously, this second megarange needs to be in the megarange registry.

Grüße, Carsten

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 14 Jul 2021 21:05:03 +0000

Thank you Michael for your reply as I did not realize the usefulness of section 7.4.

The YANG SID mega-range registry would indeed be OK for Open Config and major vendors. As a mega-range is 1.000.000 (roughly 2**20) entries for a 63-bit value, this leaves 2**40 mega-ranges, basically infinite. With this huge amount of mega-ranges, I wonder whether FCFS would not have been enough or at least I hope that the expert will be very lenient to allow a new mega-range.

I will remove this blocking DISCUSS point tomorrow (getting late here).

My other DISCUSS point about a range per RFC or per module is still unclear though as there can be multiple modules per RFC (hence the text is inconsistent).

-éric

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Jul 2021 15:58:21 -0700

> That interface is still there:

What is the official plan to assign ranges to each IETF YANG module?
(Sorry if this is a different draft).

Looking through this WEB site, the SID assignments seem very ad-hoc and
manually derived,
and extremely prone to human error.  I am not worried about hackers
tampering with the SID files as much as the administration of the
micro-ranges
to be sloppy and poorly done.

Hopefully there will be tools that detect overlapping assignment errors
and tools that automatically assign ranges to a module and record the
assignment in an official database. A "SID Lookup" tool would also help
developers and operators debug implementations.

> Obviously, this second megarange needs to be in the megarange registry.
Andy