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

On Tue, Jul 13, 2021 at 11:53 AM Rob Wilton (rwilton) <rwilton=
40cisco.com@dmarc.ietf.org> wrote:

> Hi Michael,
>
> Thanks.  Please see inline.
>
> > -----Original Message-----
> > From: iesg <iesg-bounces@ietf.org> On Behalf Of Michael Richardson
> > Sent: 13 July 2021 18:39
> > To: Rob Wilton (rwilton) <rwilton@cisco.com>; The IESG <iesg@ietf.org>;
> > draft-ietf-core-sid@ietf.org; core-chairs@ietf.org; core@ietf.org
> > Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16:
> (with
> > DISCUSS and COMMENT)
> >
> >
> > Robert Wilton via Datatracker <noreply@ietf.org> wrote:
> >     > (1) I would like further discussion regarding whether SIDs are
> bound just
> > to
> >     > 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 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.
>
>

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

> >
> >     > The draft states that if the
> >     > definition is changed in a non-backwards-compatible (NBC) way then
> a
> > new SID
> >     > SHOULD be allocated.
> >
> > 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.
>
> >
> >     > 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.
> >
> > This is my understanding.
>
> Okay, I think that the text that describes this need to be tweaked.
>
>
> >
> >     > (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.
> >
> > I don't know of any such discussion, but I don't really understand the
> > distinction.
>
> 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;
>      }
>
>
>
>
> >
> >     > (4) The policy in 7.4.2 for allocation a SID mega-range seems to
> aiming
> > this
> >     > towards organizations rather than individuals.
> >
> > Yes, the idea being that "Zigbee" or "IEEE" or ... would allocate a
> mega-range.
>
> Yes.
>
> >
> >     > 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?
> >
> > 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.
>
> 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
>
>
> >
> > --
> > ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> > ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> > ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
> >
> >
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT
> consulting )
> >            Sandelman Software Works Inc, Ottawa and Worldwide
> >
> >
> >
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>