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

Éric Vyncke via Datatracker <noreply@ietf.org> Wed, 14 July 2021 05:41 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D40E23A103E; Tue, 13 Jul 2021 22:41:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann <cabo@tzi.org>, jaime@iki.fi, jaime@iki.fi
X-Test-IDTracker: no
X-IETF-IDTracker: 7.34.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= <evyncke@cisco.com>
Message-ID: <162624127733.15124.15333004711651272795@ietfa.amsl.com>
Date: Tue, 13 Jul 2021 22:41:17 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Vp9KdL5MCS6AS09l1X5Qr_Cfnds>
Subject: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-core?= =?utf-8?q?-sid-16=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jul 2021 05:41:18 -0000

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