Subject: [core] Genart last call review of draft-ietf-core-sid-15

From: Linda Dunbar via Datatracker <[email-masked]>
Date: Tue, 16 Mar 2021 10:34:09 -0700

Reviewer: Linda Dunbar
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-core-sid-15
Reviewer: Linda Dunbar
Review Date: 2021-03-16
IETF LC End Date: 2021-03-17
IESG Telechat date: Not scheduled for a telechat

Summary:
This document introduces the globally unique 63-bits integers to identify YANG
items which include data nodes, RPCs, their associated inputs/outputs,
notifications, YANG modules, submodules, and features.

Major issues:
- One of the benefits of YANG is its explicit naming and human-understandable
notations. It will be a nightmare if all the YANG items are represented by
integers. YANG items being represented by integers will be worse than the TYPE
values in the TLVs. At least, the TLV types are in the context of the protocols
and their messages. - It will be a tremendous amount of work to map all YANG
items to globally unique integers. - YANG has been widely deployed without the
numbering system. Which environment will need the integer representations? Who
will validate the numbers used? How to validate the YANG modules represented by
those "integers"?

- SID can be mistaken as Segment Identifiers (SID). Suggest using a different
name.

Minor issues:

Nits/editorial comments:

Best Regards,
Linda Dunbar

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 16 Mar 2021 18:59:08 +0100

Hi Linda,

> On 2021-03-16, at 18:34, Linda Dunbar via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Linda Dunbar
> Review result: Not Ready
> 

These are all questions that were valid before this document was written.
The document now shows that this can be done, without any of the disadvantages you cite.

There never will be a need to map *all* YANG identifiers to YANG SIDs, as YANG-CBOR is designed to allow string identifiers as well (you can use YANG-CBOR entirely without using YANG SIDs).  But where encoding and lookup efficiency is important, YANG SIDs are the way to go, and the process for allocating and using them that we arrived at after years of discussion (including several rounds with IANA) makes them very much workable.

> - SID can be mistaken as Segment Identifiers (SID). Suggest using a different

Indeed, that’s why they are called “YANG SIDs”.

Grüße, Carsten

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Mar 2021 12:36:47 -0700

> will validate the numbers used? How to validate the YANG modules

My initial reaction to this work was that it would never fly in the wild.
But the CORE WG has developed tools and solved many of the problems with
YANG SID.

There is a great deal of trust required in the tooling and procedures used
to manage the mapping of
YANG identifiers to globally unique integers.  These numbers are not
intended for
human usage (much like OID strings in SNMP).  If the client and server do
not agree
on the YANG-to-SID mapping, then the protocols will not work (same as OIDs
in SNMP).
I think the administration plan makes sense, but it is still unproven,
especially the
delegated subrange name assignments.

The mapping files are independent of the YANG modules so there is no need
to alter
any YANG module to use YANG SID.  There is a lot of work creating mapping
files instead. ;-)
The mappings are not used in YANG modules at all. They are only useful to
generate an
efficient binary message encoding for YANG data.  (Only. The delta-SID
encoding is extremely efficient
and really needed right now.)

Andy

- SID can be mistaken as Segment Identifiers (SID). Suggest using a
> different
> name.
>
> Minor issues:
>
> Nits/editorial comments:
>
> Best Regards,
> Linda Dunbar
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>