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

Andy Bierman <andy@yumaworks.com> Tue, 13 July 2021 19:14 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7053A0F49 for <core@ietfa.amsl.com>; Tue, 13 Jul 2021 12:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level:
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M_dcq7FZloY for <core@ietfa.amsl.com>; Tue, 13 Jul 2021 12:14:53 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19AE73A0F41 for <core@ietf.org>; Tue, 13 Jul 2021 12:14:52 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id a18so31588991ljk.6 for <core@ietf.org>; Tue, 13 Jul 2021 12:14:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jxR1HBlu6JjH6FoCbYA6ZZbpb/YlOUqu1YvcAr9/bLc=; b=AUMB6OWYaJIFQ6H6iVfZU72wHbIs4ltt31X8l/m+LekyMHEaeFpMnEfcXknNw4kT6+ yVhM+SlmY/FkS3DFc/bMknNT+If+B3nMnHf6J1K7z/TIXh6I1ZeQA00/C5iZQRsiwEyq OamGC8clcoCy/rrZB7mBzpl8M1PWxISLvg6UcGtri1o2WjbgYu2GcEcOW3gKll0rIwEj 7wfN+iF8zZlgSgZ0/Ovhf5gn5agh/TDrlGHie8EKWa/QgyNxndbPA47+7QIg/TQwCCbc XFSeEBsnsTafWYcb9yotObKrL1ePS6DsU0Mq7N3yLjbKQYjqsTuYQAZkAnZVUPkSMR3x 4g4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jxR1HBlu6JjH6FoCbYA6ZZbpb/YlOUqu1YvcAr9/bLc=; b=HUqFCnvdtGOj/g/AZG8uUZhdV0cqjCFUL2pqGxjlBKd+M4meeMODwKO1Vmtl5FUbEr 4P9b9g3sbZlLcqv+tyUj6qNUrARgyKOWzc5kEYotTu3xpoOQx3kXQ0u6eB/nw4iVM8wK X4Wgqz6cDXioAG6cW50vBgVoXSen1tc/CQnTp0prBVSQociN9MAgXI3TdquHcjYuD55l Phoa5c+UNau2Rdf0tORutGaQ5uNrVSwUSaYgbA/SEKkEpSMdgAzmKtITGuZxBF6MRtoV N67e48h8IcZ7OEyBWQDq/diWBQpT2BcK3dqo028pG8sPCZGJbgL7FKWxVygblLjrtevl c9xw==
X-Gm-Message-State: AOAM531v3kCWmdtYIvnX60erKBBafPHG5rz7KnBSQV/PZK+tzkqkklHD NsxSr5Yl9GP8Crvxe68axeUhBG8qUPkjnamIe6wcgQ==
X-Google-Smtp-Source: ABdhPJyd3rpeOBRMQujn2iMMw1uSaXClE8p0UrMJDDskIVtC8esP7FXS0xl8PsXCUPomj/wSgIKEABKgK2/gH1v3Gg8=
X-Received: by 2002:a2e:a546:: with SMTP id e6mr3547874ljn.43.1626203690033; Tue, 13 Jul 2021 12:14:50 -0700 (PDT)
MIME-Version: 1.0
References: <162619194652.5730.10916340155265302741@ietfa.amsl.com> <26411.1626197913@localhost> <DM4PR11MB54388A5B0C2305C66A39EE2BB5149@DM4PR11MB5438.namprd11.prod.outlook.com>
In-Reply-To: <DM4PR11MB54388A5B0C2305C66A39EE2BB5149@DM4PR11MB5438.namprd11.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 13 Jul 2021 12:14:39 -0700
Message-ID: <CABCOCHS3-VdeG3P25B4KfQhw=0Tu5V13_MSoBGUifTXFSiBSwg@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, The IESG <iesg@ietf.org>, "draft-ietf-core-sid@ietf.org" <draft-ietf-core-sid@ietf.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, "core@ietf.org" <core@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000046f96d05c7060ddc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/qzL_BcIi4ztTFHk7XcNTvstt4F8>
Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Tue, 13 Jul 2021 19:14:59 -0000

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>om>; The IESG <iesg@ietf.org>rg>;
> > 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
>