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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 19 Oct 2021 23:51:36 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-core-sid-16: No Objection

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/blog/handling-iesg-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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Based on the authors’ reply, I have now cleared one of my previous blocking
DISCUSS points (related to section 7.5.2 and other SDO / mega ranges see also
https://mailarchive.ietf.org/arch/msg/core/SyG1Ax5V2KmYM8v1_CFOmghpUs0/ ). I
have kept the previous DISCUSS points below for archive.

Please note that my COMMENT points are still unanswered as far as I can tell.

I hope that this helps to improve the document,

Regards,

-éric

== PREVIOUS DISCUSS ==

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

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