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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Tue, 13 Jul 2021 08:59:06 -0700

Robert Wilton 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:
----------------------------------------------------------------------

Hi,

Thank you for this work, I believe that it likely to be useful, perhaps not
only for constrained devices, it may also turn out to be popular for streaming
telemetry.

There are a couple of points that I would like to see discussed and perhaps
addressed:

(1) I would like further discussion regarding whether SIDs are bound just to
the schema name, or the schema item definition.  The draft states that if the
definition is changed in a non-backwards-compatible (NBC) way then a new SID
SHOULD be allocated.  But I don't understand how this will work.  Given that
the .sid file would then contain exactly the same path but with different sids
assigned (for every time the meaning of the definition changes), then how do
consumers of the sid file know which sid to use for a given path (given that
there is no indication in the .sid file)?  Instead, I think that this is the
wrong way to be handling NBC changes, and SIDs should be bound only to the
schema path (i.e., the name of the item), and a new SID is only allocated if
the name/path changes, and otherwise the same SID is used, even if the
definition changes in a non-backwards-compatible way.

(2) I think that this document should be clearer as to the relationship between
SIDs and submodules (more details in the comment).

(3) This draft makes use of the rc:yang-data extension.  Was there any
discussion about using "YANG Data Structure Extensions" (RFC 8791) instead,
which is meant to be a cleaner formulation of the rc:yang-data extension, and
without the dependency on RESTCONF?  I would suggest that using RFC 8791 would
be preferable if possible.

(4) The policy in 7.4.2 for allocation a SID mega-range seems to aiming this
towards organizations rather than individuals.  The policy in 7.6 for the "IETF
YANG SID Registry" requires an RFC.  What is the mechanism if an individual or
open source project wanted to get SIDs assigned for some of their YANG modules?
 I.e., should we be defining a separate mega-range, managed by IANA, with just
Expert Review or Specification Required so that these modules could use SIDs
allocated?  Or do you envisage a separate entity taking up the responsibility
for coordinating this?

Regards,
Rob

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

1. Regarding the relationship between sids and submodules, I think is best
summed up by this comment in the appendix: "Note that ".sid" files can only be
generated for YANG modules and not for submodules."  I.e., I don't think that
sids should be allocated for the name of the submodule, and any items within a
submodule are effectively allocated sids as part of processing the module that
includes them.  This topic should be addressed early in the document, and
probably the existing references to submodule in the introduction and the YANG
module can be removed.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 13 Jul 2021 13:38:33 -0400

Robert Wilton via Datatracker <[email-masked]> wrote:
    > the schema name, or the schema item definition.

I'm not sure I understand the question.... I guess schema name is the leaf definition.

    > The draft states that if the
    > SHOULD be allocated.

True, I assume that this leads to a new YANG leaf name.

    > But I don't understand how this will work.  Given that

This is my understanding.

    > be preferable if possible.

I don't know of any such discussion, but I don't really understand the distinction.

    > towards organizations rather than individuals.

Yes, the idea being that "Zigbee" or "IEEE" or ... would allocate a mega-range.

    > The policy in 7.6 for the "IETF

    > allocated?  Or do you envisage a separate entity taking up the responsibility

My impression was that there would be a mega-range operated outside of IANA
for this (open source, non-RFC YANG module) kind of thing, but I think that
the energy for doing that may have waned.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 13 Jul 2021 18:52:17 +0000

Hi Michael,

Thanks.  Please see inline.

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Michael Richardson
> Sent: 13 July 2021 18:39
> To: Rob Wilton (rwilton) <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with
> DISCUSS and COMMENT)
> 
> 

The schema name (or path), is just the location to a data item definition (e.g., foo).

e.g.,
leaf foo {
  type string {
    len "1..10";
  }
}

The definition of foo could change, without changing the name.  E.g., a backwards-compatible change:

leaf foo {
  type string {
    len "1..20";
  }
}

Or the definition of foo could change in a non-backwards-compatible way.  E.g.,

leaf foo {
  type int32;
}

 RFC 7950 basically states that this is not allowed, but these sorts of changes happens anyway (e.g., vendors fixing bugs, or bugs in standard YANG models), and the YANG versioning work will allow these sorts of changes with appropriate mitigations.  https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-03

But in all these cases, no new SID should be allocated, or otherwise you will have two SIDs assigned to the same name/path.

> True, I assume that this leads to a new YANG leaf name.

Only if the author gives the definition a new name, and from a SID allocation POV, this is just a new item name in the schema, and hence needs a new SID.  I.e., the allocation of a new SID is related to a new item name, not because of changes in a definition.

> This is my understanding.

Okay, I think that the text that describes this need to be tweaked.

> I don't know of any such discussion, but I don't really understand the

The new RFC is effectively the "proper" way to do achieving this.

I think that is may be as simple as changing:

     import ietf-restconf {
       prefix rc;
       reference "RFC 8040: RESTCONF Protocol.";
     }

     rc:yang-data sid-file {
         uses sid-file;
     }

to

     import ietf-yang-structure-ext {
       prefix sx;
     }

      sx:structure sid-file {
         uses sid-file;
     }

> Yes, the idea being that "Zigbee" or "IEEE" or ... would allocate a mega-range.

Yes.

> the energy for doing that may have waned.

Okay.  If there is a lack of energy there, do you think that this is something that we should be asking IANA to manage (i.e., have this draft separate a separate mega-range for these other modules)?

Thanks,
Rob

---

From: Michael Richardson <[email-masked]>
Date: Tue, 13 Jul 2021 15:00:24 -0400

> RFC 7950 basically states that this is not allowed, but these sorts of
    > changes happens anyway (e.g., vendors fixing bugs, or bugs in standard
    > YANG models), and the YANG versioning work will allow these sorts of
    > changes with appropriate mitigations.
    > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-03

    > But in all these cases, no new SID should be allocated, or otherwise
    > you will have two SIDs assigned to the same name/path.

Encoding towards CBOR, the CBOR wouldn't care that much about the change in
type, as the CBOR is self-describing in that way.
So maybe it's okay if a new SID is not allocated.

Where it would be a problem is if the change was from a 1-based count to a
0-based count, both encoded as integers.  In that case, I really hope it
would go from "foo" to "foo-0" or something like that.

    > Only if the author gives the definition a new name, and from a SID
    > allocation POV, this is just a new item name in the schema, and hence
    > needs a new SID.  I.e., the allocation of a new SID is related to a new
    > item name, not because of changes in a definition.

I agree that we have a problem enforcing at the pyang sid generation place
that non-backwards compatible changes need new SIDs.  That sounds like a
tooling improvement, rather than a bug in the spec.

    > Okay.  If there is a lack of energy there, do you think that this is
    > something that we should be asking IANA to manage (i.e., have this
    > draft separate a separate mega-range for these other modules)?

So, we should have a second mega-range allocation, with a FCFS
considerations.  I would be in favour of that.
(It could also happen in a new document or via some other IESG action.)

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Jul 2021 12:14:39 -0700

On Tue, Jul 13, 2021 at 11:53 AM Rob Wilton (rwilton) <rwilton=
[email-masked]> wrote:

> >     > (1) I would like further discussion regarding whether SIDs are
> bound just
> > to
> > I'm not sure I understand the question.... I guess schema name is the
> leaf
> > definition.
>
> changes happens anyway (e.g., vendors fixing bugs, or bugs in standard YANG
> models), and the YANG versioning work will allow these sorts of changes
> with appropriate mitigations.
> But in all these cases, no new SID should be allocated, or otherwise you
> will have two SIDs assigned to the same name/path.
>
>

The "item" list is a bit odd because the namespaces (module, identity,
feature, data)
do not exactly align with the YANG terminology.  The draft should specify
what happens
if the namespace changes. It seems a new SID is needed and the old entry
(different namespace)
becomes obsolete.

   list item {
        key "namespace identifier";
        unique "sid";

A SID is bound to the {namespace, identifier} tuple.
The type of data node (e.g. container vs. leaf) does not impact this
mapping.
The data type (e.g. string vs int32) does not affect this mapping.

Andy

> >     > definition is changed in a non-backwards-compatible (NBC) way then
> a
> > new SID
> >     > SHOULD be allocated.
> >
> allocation POV, this is just a new item name in the schema, and hence needs
> a new SID.  I.e., the allocation of a new SID is related to a new item
> name, not because of changes in a definition.
>
> >
> >     > the .sid file would then contain exactly the same path but with
> different
> > sids
> >     > assigned (for every time the meaning of the definition changes),
> then
> > how do
> >     > consumers of the sid file know which sid to use for a given path
> (given
> > that
> >     > schema path (i.e., the name of the item), and a new SID is only
> allocated
> > if
> >     > which is meant to be a cleaner formulation of the rc:yang-data
> extension,
> > and
> >     > (4) The policy in 7.4.2 for allocation a SID mega-range seems to
> aiming
> > this
> >     > open source project wanted to get SIDs assigned for some of their
> YANG
> > modules?
> >
> >     > Expert Review or Specification Required so that these modules
> could use
> > SIDs
> something that we should be asking IANA to manage (i.e., have this draft
> separate a separate mega-range for these other modules)?
>
> Thanks,
> Rob
>
>
> >
> > --
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

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

> From: Michael Richardson <[email-masked]>
> Sent: 13 July 2021 20:00

Yes, but this isn't an issue specific to SIDs or the CBOR encoding.  This concern should be left to the core YANG specs.

With regular YANG, you have a problem if the client and server are using incompatible definitions of the schema nodes.  This is a known issue, and the solution to this problem is either not do this (e.g., as per RFC 7950 section 11 module update guidelines) or manage this is in a way that the client and server can handle the changes (which is the problem that the YANG versioning work is providing a solution for).

But at the end of the day, a SID is just a more efficient way of encoding the item name within a given module.  I.e., it allows one to use an integer instead of "module-foo:leaf-bar".  It cannot have any semantic beyond that.  If the item name changes then a new SID is allocated.  If the item name stays the same, but the definition changes, then the same SID is used.

Andy's comment also summed this up well.

> tooling improvement, rather than a bug in the spec.

I disagree.  The spec should only be binding the SID to the schema node name, not its definition.

Otherwise, you will end up with SID files that look like this (if the definition of the hostname has changed):

        {
          "namespace": "data",
          "identifier": "/ietf-system:system/hostname",
          "sid": 1752
        },
        {
          "namespace": "data",
          "identifier": "/ietf-system:system/hostname",
          "sid": 1879
        },
        {
          "namespace": "data",
          "identifier": "/ietf-system:system/hostname",
          "sid": 2011
        },

How does the server know what value to use when encoding it?  Does a client have to handle decoding all these SID values?  Noting that there is no extra information in the SID file to indicate how these should be processed differently.

>     >> > Expert Review or Specification Required so that these modules could
> use
>     >> > SIDs
>     >> My impression was that there would be a mega-range operated outside
> of
>     >> IANA

Thanks,
Rob