Re: [netmod] [core] js review of draft-ietf-core-sid-12

Ivaylo Petrov <ivaylo@ackl.io> Wed, 01 July 2020 14:48 UTC

Return-Path: <ivaylo@ackl.io>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519DC3A0C29 for <netmod@ietfa.amsl.com>; Wed, 1 Jul 2020 07:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.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 HZ9CCh1qVKDX for <netmod@ietfa.amsl.com>; Wed, 1 Jul 2020 07:48:23 -0700 (PDT)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 D133E3A0C22 for <netmod@ietf.org>; Wed, 1 Jul 2020 07:48:22 -0700 (PDT)
Received: by mail-wm1-x334.google.com with SMTP id w3so11096949wmi.4 for <netmod@ietf.org>; Wed, 01 Jul 2020 07:48:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8z9I7kSmk6P72iubUtDPd6N3HBEo4ARywKBJnNObdGo=; b=XEus+SRmcqdSABTKk1FVs2T9BP9elrsP0S3kjWMexBoBuSkyY5poW6LL9lalCMdwLC oMGyzmpvuHqOCxn2Y7t1Aw/VBm3v1KCJKlVHe0WIq99lUidmmwct0GfOg1D29lu4Zw4N UdruVI1SFnR5+If6OdyMEmUUzlxdAIVmJ+y3bPo2Bv7bKU0zzKPVIYnU/UL/EPx7sCVf rfluSNQ1LMrhmSTT8xsimz9k96oLOcSPSQZnG3AKbSpOgiTIbrEygAE8p+GTv2+EHhJ6 qGbIBhewGw8iBWLIJ4aZccatkk4UjEr03EuE/JmVMo0wS3UtsvASJLCioqXGgVziZXKP LatA==
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; bh=8z9I7kSmk6P72iubUtDPd6N3HBEo4ARywKBJnNObdGo=; b=GE4XFNXsENddCIp0FugdoGDMcugzHzvQZwgbXI2n2c+vALAygdqqYRfCdw9nohI4F/ bk8imcMsTHE7dE/D18c8L9MjcMabM7vO4EbZ5qrMnZQD8q4HjQf2PjUF5euWqh4Tdj89 gnFABVoftGGINK9FlWFadIYmi5n6NPkAiosMALGtkI2JFCrlkjxPRdcUfwcADQSMdcL0 Ygqb2AD8aTtYjqA9G9rhrFxduog9PozlAgouk+r0kjO7Krc5KUyVK2IP+yLwCF3tIODh gy7TnhMNl6gnpM7ZAY4zgEggDTqUtELmw6aiAS7Hw4iUz90XoEmxMVnyeQ+9K6iQoD2C vCRA==
X-Gm-Message-State: AOAM532z1MsDd5U1YPM/qAp+k3AZ7e/zx/SIDG0c1lebBxnWgyC98EcL bMzKkIIz0VB/HxVzv/vEPa61cVWRrq6SB++J8dx8YA==
X-Google-Smtp-Source: ABdhPJyPVy/c2yEfNtg7TZmr/doYpMublZw7R+Ws4KLEHkgCegeHucV0anHy+ZRvODhDRvK+ufbFXeUdkn+/fl7lg2o=
X-Received: by 2002:a1c:7f87:: with SMTP id a129mr28196404wmd.10.1593614900811; Wed, 01 Jul 2020 07:48:20 -0700 (PDT)
MIME-Version: 1.0
References: <20200330213129.m2azrbeaxrtgivfc@anna.jacobs.jacobs-university.de> <CAJFkdRz445b4n86ug=v1ruYYWbDjwnEJwUNCZvEzENu_gMV0bg@mail.gmail.com> <20200415162054.s4bjcrienqvrytfz@anna.jacobs.jacobs-university.de> <CAJFkdRyVc0Ti6nsaWbNoqMH4GZU9qB3r0EQb0MtUoueEBma-Pg@mail.gmail.com> <20200623165938.trkunon5s6wwagdc@anna.jacobs.jacobs-university.de> <CAJFkdRymDNAy3j6suaxa7nRoRp4idOtNyqgv-jPUvtJLPWAvGA@mail.gmail.com> <20200624100814.7tik6xpa6pfewtil@anna.jacobs.jacobs-university.de>
In-Reply-To: <20200624100814.7tik6xpa6pfewtil@anna.jacobs.jacobs-university.de>
From: Ivaylo Petrov <ivaylo@ackl.io>
Date: Wed, 1 Jul 2020 17:47:54 +0300
Message-ID: <CAJFkdRzWSuju_ViTQxAh9dihgP2=Fn4C5t8NAP=zSKKCr64wEg@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Ivaylo Petrov <ivaylo@ackl.io>, core <core@ietf.org>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001275ec05a962620b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ZOtWpYc_fRTwF9QylW_qmq5t53Y>
Subject: Re: [netmod] [core] js review of draft-ietf-core-sid-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2020 14:48:28 -0000

Hi Juergen,

Thanks for those clarifications :) For the CORECONF vs CoMI point, I saw no
opposition to only using CORECONF, therefore my plan is to use [1] and
rename CoMI to CORECONF everywhere except for the draft name, which I do
not intend to change.

I tried to rephrase the text about instance-identifiers. Now the
terminology section contains a definition of namespace-qualified form that
works for any usable schema node and the schema-node-path uses that one
now. The latest version can be seen here [2]. The text in the YANG module
reads:

```
    description
      "A schema-node path string for use in the
       YANG SID registry. This string additionally follows the following
rules:

       o  The leftmost (top-level) data node name is always in the
          namespace-qualified form.
       o  Any subsequent schema node name is in the namespace-qualified form
          if the node is defined in a module other than its parent node, and
          the simple form is used otherwise. No predicates are allowed.

       This format is intended to support the YANG 1.1 ABNF
       for a schema node identifier, except module names
       are used instead of prefixes.";
    reference
      "RFC 7950, The YANG 1.1 Data Modeling Language;
       Section 6.5: Schema Node Identifier;";
```

I plan to submit the new version tomorrow or the day after.

Best regards,
Ivaylo

[1]: https://github.com/core-wg/comi/compare/coreconf-only
[2]:
https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-sid&url2=http://core-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.txt



On Wed, Jun 24, 2020 at 1:08 PM Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, Jun 24, 2020 at 09:56:11AM +0200, Ivaylo Petrov wrote:
> > Hi Juergen,
> >
> > Thank you very much for your new comments! Please find my answers below.
> >
> > On Tue, Jun 23, 2020 at 6:59 PM Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > On Wed, Jun 10, 2020 at 11:16:47AM +0200, Ivaylo Petrov wrote:
> > >
> > > > > - Is it CoRECONF or CORECONF? And I find the term CORECONF
> confusing.
> > > > > > >   We have two protocols called NETCONF and RESTCONF and now we
> add
> > > > > > >   another protocol called CoMI and we call CoMI together with
> YANG
> > > > > > >   CBOR and SIDs CORECONF?
> > > > > > >
> > > > > > >   1) NETCONF  + YANG + XML      serialization + path naming ->
> ?
> > > > > > >   2) RESTCONF + YANG + XML|JSON serialization + path naming ->
> ?
> > > > > > >   3) CoMI     + YANG + CBOR     serialization + SID naming  ->
> > > CORECONF
> > > > > > >
> > > > > > >   We do not have a term for 1) and 2) and then we have a term
> for
> > > 3)
> > > > > > >   which, however, looks more like the protocol names used in
> 1) and
> > > > > > >   2). This comment is not specific to this ID, but the
> asymmetry
> > > > > > >   showed up while reading the SID document, I had to look at
> other
> > > IDs
> > > > > > >   to understand how things are named. And the SID document says
> > > > > > >
> > > > > > >    YANG is a language designed to model data accessed using
> one of
> > > the
> > > > > > >    compatible protocols (e.g.  NETCONF [RFC6241], RESCONF
> > > [RFC8040] and
> > > > > > >    CoRECONF [I-D.ietf-core-comi]).
> > > > > > >
> > > > > > >   Then I read the CoMI abstract. It first says CoMI is "a CoAP
> > > > > > >   Management Interface", it then says "The complete solution
> > > composed
> > > > > > >   of CoMI, [I-D.ietf-core-yang-cbor] and [I-D.ietf-core-sid] is
> > > called
> > > > > > >   CORECONF." and finally it states that "CORECONF extends the
> set
> > > of
> > > > > > >   YANG based protocols, NETCONF and RESTCONF, with the
> capability
> > > to
> > > > > > >   manage constrained devices and networks.". So I am confused,
> is
> > > > > > >   CORECONF a protocol as stated in this document? Or is CoMI a
> > > > > > >   protocol? (What is then the difference between a "Management
> > > > > > >   Interface" and a management protocol?) I am not sure whether
> I
> > > get
> )> > > > > >   to review comi, hence I mention my confusion here as I hit
> it
> > > while
> > > > > > >   reviewing the sid document.
> > > > > > >
> > > > > >
> > > > > > [IP]: Currently this is indeed somewhat confusing. The proposed
> > > change
> > > > > from
> > > > > > Michael Richardson was to at least have CORECONF in the title of
> the
> > > CoMI
> > > > > > document. I am wondering if that might still leave some of the
> > > confusion.
> > > > > > For me the simple solution is in this document to refer to CoMI,
> not
> > > > > > CORECONF and let CoMI draft define what CORECONF actually is.
> Unless
> > > you
> > > > > > think this will still not resolve the issue, this is going to be
> my
> > > way
> > > > > > forward.
> > > > >
> > > > > Avoiding CORECONF in this document helps to limit the problem. If
> CoMI
> > > > > is the name of the protocol, I would hope we do not need CORECONF
> at
> > > > > all. But then CORECONF is all over the place in
> > > > > draft-ietf-core-comi-09.txt, it actually looks like the protocol is
> > > > > called CORECONF and not CoMI. I really believe this terminology
> > > > > confusion needs to be resolved in the WG so the WG actually knows
> and
> > > > > agrees on the name of the technology they standardize.
> > >
> > > I am not sure whether this got resolved...
> > >
> >
> > [IP]: You are right - I realized that omission and I have started a
> > discussion (so far not many opinions on it though) here [1] focusing
> mostly
> > on this point. I have proposed 3 options for a way forward - use only
> > CORECONF, use only CoMI or find good enough reason to have the clearly
> CoAP
> > part have a name (CoMI) and CoMI + Content format to be called CORECONF.
> I
> > currently don't see a reason for having both CoMI and CORECONF as names,
> so
> > I would rather go with one of the other two options. I will try to see if
> > in the past people were more in favour of one or the other. I believe
> > Carsten would prefer CORECONF and at the top of my head I don't remember
> > anyone voicing any preferences, but I will check that and propose it as
> the
> > default way forward if there are no replies in the next 6-7 days.
> >
> > [1]:
> https://mailarchive.ietf.org/arch/msg/core/x9RJkfnQgW0Rp3LmHd2CkbOA4DY/
>
> Something like this
>
>   | protocol | model. lang. | data encoding   |
>   |----------+--------------+-----------------|
>   | NETCONF  | YANG         | XML             |
>   | RESTCONF | YANG         | XML, JSON, CBOR |
>   | CORECONF | YANG         | CBOR            |
>
> I can easily explain to others. So far we have managed without
> creating additional names for the rows. If we talk about data models,
> we talk about 'YANG models' and they are ideally for a large part
> agnostic to the protocol(s) and encoding(s) used. If we talk about
> protocol specifics, well we have a name for it. Data encoding (or
> representation) aspects ideally are protocol agnostic as well - at
> least for protocols that can deal with different encodings. One could
> add a naming dimension (path vs SIDs) but as long SIDs are only used
> as an optimization by the CBOR encoding, this may not be necessary.
>
> > > > > - This description makes little sense to me:
> > > > > > >
> > > > > > >   typedef sid-file-version-identifier {
> > > > > > >     type uint64;
> > > > > > >     description
> > > > > > >       "Optional attribute that gives information about the .sid
> > > file
> > > > > > >        version.";
> > > > > > >   }
> > > > > > >
> > > > > > >   This is a type definition. Why does the description talk
> about an
> > > > > > >   optional attribute? The type should not state whether
> something
> > > > > > >   using the type is optional or not. (And I would prefer to
> avoid
> > > > > > >   'attribute', better use YANG defined terms or just describe
> that
> > > > > > >   this type represents a version number for a SID file.)
> > > > > > >
> > > > > >
> > > > > > [IP]: I believe now it should be more clear.
> > > > >
> > > > > Yes. I wonder though, is this a simple linear counter? Or can it be
> > > > > anything as long as newer > older is satisfied? Or is this just a
> tag
> > > > > that needs to match and it does not imply any order semantics?
> > > > >
> > > >
> > > > [IP]: The intention was to be newer > older without any implied
> > > semantics. I
> > > > rephrased the text to capture this.
> > > > Old:
> > > >            "Optional leaf that specifies the version number of the
> .sid
> > > > file.
> > > >           .sid files and the version
> > > >           sequence are specific to a given YANG module revision.
> > > >           This number starts at zero when there is a YANG module
> update.
> > > >           This number can distinguish updates to the SID file which
> are
> > > the
> > > > result of
> > > >           new processing, or the result of reported errata.";
> > > > New:
> > > >            "Optional leaf that specifies the version number of the
> .sid
> > > > file.
> > > >           .sid files and the version sequence are specific to a given
> > > YANG
> > > >           module revision. This number starts at zero when there is
> a new
> > > > YANG
> > > >           module revision and increases monotonically.  This number
> can
> > > >           distinguish updates to the .sid file which are the result
> of
> > > new
> > > >           processing, or the result of reported errata.";
> > >
> > > The YANG versioning aims at supporting version histories that are more
> > > complex than just a simple linear history. Hence, a simple linear
> > > order of the sid version number may have limitations.
> > >
> >
> > [IP]: The .sid file history is linked to a YANG file version and is
> > supposed to mostly/only fix errors in the generation. Any change in the
> > YANG file version (be it linear or nonlinear) is expected to reset the
> .sid
> > file version to 0. Please let me know if you believe that this is still
> not
> > going to work well in some cases or if you think that the text is not
> clear
> > enough.
>
> OK. If the sid number space is scoped by the YANG module version, then
> there does not seem to be a problem (i.e., if I update a YANG module,
> then the sid number space for that version of the YANG module resets
> to 0).
>
> > > >   s/Identifies a schema-node path string/A schema-node path"
> > > > > > >
> > > > > > >   It is a bit confusing to define a schema-node path by way of
> > > > > > >   reference to an instance identifier. I understand that you
> borrow
> > > > > > >   the namespace encoding from the way JSON encode instance
> > > identifiers
> > > > > > >   but this type really represents what RFC 7950 calls an
> absolute
> > > > > > >   schema node identifier, no? Is the term schema-node path
> actually
> > > > > > >   needed or is it the same as absolute schema node identifier?
> Or
> > > is
> > > > > > >   the difference between the two how namespaces are
> represented?
> > > > > > >
> > > > > >
> > > > > > [IP]: I might have misunderstood something, but my understanding
> is
> > > that
> > > > > > the prefix related to a module could be changed during an import,
> > > whereas
> > > > > > here we really want to use the module name as a more stable
> > > identifier.
> > > > > The
> > > > > > difference between absolute schema node identifier and
> schema-node
> > > path
> > > > > is
> > > > > > that we mandate the use of module name and not prefix as defined
> in
> > > RFC
> > > > > > 7950.
> > > > >
> > > > > Well, what you model here is an absolute schema node path, except
> that
> > > > > prefixes are replaced by module names. Note that refering to
> > > > > instance-identifier as defined in RFC 7951 has the problem, the RFC
> > > > > 7951 definition of an instance-identifier also includes prefixes
> > > > > instead of module names.
> > > > >
> > > >
> > > > [IP]: I might be misunderstanding your statement or the text in RFC
> 7951,
> > > > but if I read sec 6.11. from RFC 7951 correctly,
> > > >
> > > > The leftmost (top-level) data node name is always in the
> > > > namespace-qualified form.
> > > >
> > > >
> > > > In sec 4 of RFC 7951 the namespace-qualified form seems to only use
> the
> > > > module name and not the prefix. My impression seems to be supported
> also
> > > by
> > > > the example in this section. Due to this I believe the current text
> is
> > > > actually correct.
> > >
> > > In an ideal world, the definitions in this document would depend on
> > > the YANG specification and not on some other encoding rules. And I
> > > think what you are dealing with are absolute-schema-nodeid with the
> > > additional rule that prefix values in the node-identifier production
> > > are module names.
> > >
> > > The way the instance-identifier type has been defined is a bit
> > > problematic since it is rather XML encoding specific. Hence to get
> > > what you want, you have to import the JSON specific solution. If we
> > > ever do YANG 2.0 and factor out the XML specific things from the core
> > > language, this will likely be addressed. Note that the instance
> > > identifier includes predicates in square brackets, which I think your
> > > schema-node-path does not need.
> > >
> >
> > [IP]: I believe I see your point. My understanding is that you would
> prefer
> > this document to not depend on the JSON encoding, but rather define that
> > encoding in this document using as a basis the YANG specification. That
> > would be fine for me, simply let me know if I understood you correctly.
> >
>
> Yes, this is what I wanted to say in much more complicated words. ;-)
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>