Re: [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: 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 D318A3A0C22 for <core@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=unavailable 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 IwKdqnjc8aAi for <core@ietfa.amsl.com>; Wed, 1 Jul 2020 07:48:23 -0700 (PDT)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 A9A3E3A0C1E for <core@ietf.org>; Wed, 1 Jul 2020 07:48:22 -0700 (PDT)
Received: by mail-wm1-x32e.google.com with SMTP id o8so22725529wmh.4 for <core@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=RbHq+2VTHlqTTg5FW3mnGfctDiKNHDejt9acDQlbn/ccAQH7iWVvFk5j+lE8SsnAKm 5zEJfnABICHoV4KebI+220JP+zwJW5LR5+Cxwszo2oOk5ysKy8mGZgTkaB6akfMwXE5h Xho+wkHovDp0CVHhHxxKKom35h0IXM4UHN7Hx6NjrpP0+QEG6XYm4NpLr9qIEcnKyS36 b1+WSu5N5HZNV9rwvaJ8UttF/sOn2ltk6u8fs5dcuuz2WUcOG5TgWRZkZog11xJ7SnLw H1qi7WZkvGFIPqFC+GIx4C8MJ7t/EISEAae9G/f6NkYJ5jR+jBTa/CZb8o5O4rZ93IoQ rvOQ==
X-Gm-Message-State: AOAM533SPXncYMgL30/7HVzWyTyU8l21k8xKB3FCdg7BJ//abM1hAsnr eDV9JF4U4zWTZedSEaS+CejhuhqubUYP7FhEEVQwYw==
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, 01 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/core/ybIibaMEYhglloXYCUtD8nKsBsQ>
Subject: Re: [core] js review of draft-ietf-core-sid-12
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: 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/> >
- [core] js review of draft-ietf-core-sid-12 Juergen Schoenwaelder
- Re: [core] js review of draft-ietf-core-sid-12 Ivaylo Petrov
- Re: [core] js review of draft-ietf-core-sid-12 Juergen Schoenwaelder
- Re: [core] js review of draft-ietf-core-sid-12 Ivaylo Petrov
- Re: [core] js review of draft-ietf-core-sid-12 Juergen Schoenwaelder
- Re: [core] js review of draft-ietf-core-sid-12 Ivaylo Petrov
- Re: [core] js review of draft-ietf-core-sid-12 Juergen Schoenwaelder
- Re: [core] js review of draft-ietf-core-sid-12 Ivaylo Petrov
- Re: [core] js review of draft-ietf-core-sid-12 Juergen Schoenwaelder
- Re: [core] js review of draft-ietf-core-sid-12 Ivaylo Petrov