Re: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"

Andy Bierman <andy@yumaworks.com> Tue, 23 July 2019 18:52 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 7B64B120864 for <core@ietfa.amsl.com>; Tue, 23 Jul 2019 11:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Level:
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 4vd4l8t3M8HA for <core@ietfa.amsl.com>; Tue, 23 Jul 2019 11:52:33 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 69A97120860 for <core@ietf.org>; Tue, 23 Jul 2019 11:52:28 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id v24so42147143ljg.13 for <core@ietf.org>; Tue, 23 Jul 2019 11:52:28 -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=z9jBCJkrqvpwKhNCPTMb+PVWfg6KcHjI5Yhz46Zc40o=; b=h/5i9j6r2kBVcsEmi43zVLOptgGlwjGpNWwMsfkNksIIMDFs7W3JyFOFp3Z/oYNBVf fEyywhCSMz0/aQONNMkAeDSsqvvdV+he8CqBPjg4eRYbHpqk2lXbre+mhJ/9vqJ2PPab BHsvG0i/r/YuM6oRNkmRp6Ai3N+DfTiJJsS7HHgK8gEF2v20e0h1ZcMTZGI9mhtl4LUb rCkIitku7W6p2/wSNV9JuL065dvRw/RZ0myBgruhOIV8Qt7hMJMdphl80oFZiy5VjIF9 TduT+ZmK6+IVmRG91mPu0R1r5L6dDLkjv6EB3Ml6nQVDv6IIpOxKv2cZeuWlUwez97lR 2rPQ==
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=z9jBCJkrqvpwKhNCPTMb+PVWfg6KcHjI5Yhz46Zc40o=; b=P787dZW1oBUWR59TUQCcIlIFHUu/PKn4dXT46LThBKwLln/in9OrO2XNh55Afck7JP ZYYU518PjZxQtocKXdFxsxrHGfHhDUzHFytaIP3ZegVSCmQQ8dbLPlGiw7eBN9ccEW1t DcSVnATinbMnZnv/8RIAd5DZ0/mEFX+73zQwhjYOBNxqOB54i2+9by48UY9kg2CmKUy2 0jvIHB3P32hpfl+c9hN0r5qkhoGUX8tIf7DCoPGPTL6C8tkNzDctqziTJntBeNkiiZzk qOx42Qdux5qWk4Er9IoVqqn5OXxHrrWku8Rgszh0fRiWvkrxMGFx0F0+Beh4uak51sFM vdZg==
X-Gm-Message-State: APjAAAUAorLSAUOdKMzbiFf1vobHkO2WjgbH/f8sPXv1OFl0PsK+zXAL jo3zjFL5FctDi+GSz2ug0e6UMF4jPNQ0t6OML2J0/g==
X-Google-Smtp-Source: APXvYqwy3xiWwqzHCXG46UtvQx3BaRsFL0OCqJ8iDjlc/wBIgPQncyKojZRnJzka9MUSWzJIyiJcUvMOrYCnwXaAdeo=
X-Received: by 2002:a2e:9657:: with SMTP id z23mr39311886ljh.116.1563907946479; Tue, 23 Jul 2019 11:52:26 -0700 (PDT)
MIME-Version: 1.0
References: <156285914934.12002.9400408827321248683.idtracker@ietfa.amsl.com> <CABCOCHSfqxMueiagm29zXNOJyAOS3A_-O0YonMPcRAr10d8Ykg@mail.gmail.com> <BL0PR06MB5042F6FBD47E8C3757D620C29ACF0@BL0PR06MB5042.namprd06.prod.outlook.com> <BL0PR06MB5042A438CE8CFD5F2B3796FC9AC70@BL0PR06MB5042.namprd06.prod.outlook.com> <CABCOCHRfgS5nXYNwASjPCAFJ9dtNQ5ayc+=O9EbzaaMp-EEuGw@mail.gmail.com> <BL0PR06MB50420C236A19D766E12337549AC70@BL0PR06MB5042.namprd06.prod.outlook.com>
In-Reply-To: <BL0PR06MB50420C236A19D766E12337549AC70@BL0PR06MB5042.namprd06.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 23 Jul 2019 11:52:14 -0700
Message-ID: <CABCOCHQq3Q1w-GCG9v2GFwzr=iv58Qq+jeCi-3edDPBABUqxPw@mail.gmail.com>
To: Michel Veillette <Michel.Veillette@trilliant.com>
Cc: Core <core@ietf.org>, Carsten Bormann <cabo@tzi.org>, ivaylo petrov <ivaylo@ackl.io>
Content-Type: multipart/alternative; boundary="0000000000009c916f058e5db139"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Rn-28tsUp0xs_rT2-lbbGhyU618>
Subject: Re: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"
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, 23 Jul 2019 18:52:37 -0000

On Tue, Jul 23, 2019 at 10:13 AM Michel Veillette <
Michel.Veillette@trilliant.com> wrote:

> Hi Andy
>
>
>
> To evaluate the need, or not,  of a compact version of ietf-yang-library,
> I have created a simple example containing:
>
> - one datastore
>
> - one schema
>
> - one module set
>
>
>
> The module set contains the following YANG modules:
>
> - ietf-interfaces
>
> - ietf-ip
>
> - ietf-system
>
> - iana-hardware
>
> - my-upgrade-module
>
> - ietf-yang-types
>
> - ietf-inet-types
>
>
>
> Following is this YANG library implemented using ‘ietf-yang-library’ and
> encoded in CBOR.
>
> The resulting size is 642 bytes without any location URIs which are
> optional.
>
>
>
> {
>
>   2368 : {
>
>     +8 : [
>
>       {
>
>         +21 : "set1",
>
>         +10 : [
>
>           {
>
>             +4 : "ietf-interfaces",
>
>             +6 : "2018-02-20",
>
>             +5 : "urn:ietf:params:xml:ns:yang:ietf-interfaces"
>
>           },
>
>           {
>
>             +4 : "ietf-ip",
>
>             +6 : "2018-02-22",
>
>             +5 : "urn:ietf:params:xml:ns:yang:ietf-ip"
>
>           },
>
>           {
>
>             +4 : "ietf-system",
>
>             +6 : "2014-08-06",
>
>             +5 : "urn:ietf:params:xml:ns:yang:ietf-system",
>
>             +2 : ["ntp", "timezone-name", "dns-udp-tcp-port"]
>
>           },
>
>           {
>
>             +4 : "iana-hardware",
>
>             +6 : "2018-03-13",
>
>             +5 : "urn:ietf:params:xml:ns:yang:iana-hardware"
>
>           },
>
>           {
>
>             +4 : "my-upgrade-module",
>
>             +6 : "2019-07-23",
>
>             +5 : "http://mydomain.com/yang/my-upgrade-module",
>
>             +2 : ["ftp", "coap", "scheduled"]
>
>           }
>
>         ],
>
>         +1 : [
>
>           {
>
>             +2 : "ietf-yang-types",
>
>             +4 : "2018-02-20",
>
>             +3 : "urn:ietf:params:xml:ns:yang:ietf-yang-types"
>
>           },
>
>           {
>
>             +2 : "ietf-inet-types",
>
>             +4 : "2013-07-15",
>
>             +3 : "urn:ietf:params:xml:ns:yang:ietf-inet-types"
>
>           }
>
>         ]
>
>       }
>
>     ],
>
>     +30 : [
>
>       {
>
>         +2 : "schema1",
>
>         +1 : ["set1"]
>
>       }
>
>     ],
>
>     +5 : [
>
>       {
>
>         +1 : "unified",
>
>         +2 : ["schema1"]
>
>       }
>
>     ],
>
>     +4 : "mySensorDataModel"
>
>   }
>
> }
>
>
>
> The same YANG library implemented using ‘ietf-constrained-yang-library’
> required 183 bytes.
>
>
>
> {
>
>   2368 : {
>
>     +8 : [
>
>       {
>
>         +21 : 1,
>
>         +10 : [
>
>           {
>
>             +4 : 1500,
>
>             +6 : h'20180220'
>
>           },
>
>           {
>
>             +4 : 1600,
>
>             +6 : h'20180222'
>
>           },
>
>           {
>
>             +4 : 1700,
>
>             +6 : h'20140806',
>
>             +2 : ["ntp", "timezone-name", "dns-udp-tcp-port"]
>
>           },
>
>           {
>
>             +4 : 2200,
>
>             +6 : h'20180313'
>
>           },
>
>           {
>
>             +4 : 1005100,
>
>             +6 : h'20190723',
>
>             +2 : ["ftp", "coap", "scheduled"]
>
>           }
>
>         ],
>
>         +1 : [
>
>           {
>
>             +2 : 1100,
>
>             +4 : h'20180220'
>
>           },
>
>           {
>
>             +2 : 1150,
>
>             +4 : h'20130715'
>
>           }
>
>         ]
>
>       }
>
>     ],
>
>     +30 : [
>
>       {
>
>         +2 : 1,
>
>         +1 : [1]
>
>       }
>
>     ],
>
>     +5 : [
>
>       {
>
>         +1 : "unified",
>
>         +2 : [1]
>
>       }
>
>     ],
>
>     +4 : h'9D373F629E20'
>
>   }
>
> }
>
>
>
> The mandatory namespace field in the original ietf-yang-library, useless
> for CoREconf, is the main contributor of this increase in size. Assuming
> that a real device have at least 5 time more YANG modules, we can estimate
> that the non compact version of the YANG library will be around 3 to 4 kB,
> the compact version will be slightly less than 1kB.
>
>
>

So what is the size difference if just the XML namespace is removed?



> Can we archive the same result with a deviation module instead of a
> complete module replacement?
>
>
>


Yes


   deviation
/yanglib:yang-library/yanglib:module-set/yanglib:module/yanglib:namespace {
      deviate replace {
         mandatory false;
      }
   }

You could also replace the type-stmt for key leafs you want to change, but
this seems like overkill.
This data will not change very often. The /yang-library/content-id leaf can
be polled or yang-library-change
notification can be used. YoT devices will probably have modules hard-wired
into firmware so
this data can be cached on the client (using content-id).


Regards
>
> Michel
>
>
Andy


>
>
> *From:* Andy Bierman <andy@yumaworks.com>
> *Sent:* 22 juillet 2019 20:33
> *To:* Michel Veillette <Michel.Veillette@trilliant.com>
> *Cc:* Carsten Bormann <cabo@tzi.org>
> *Subject:* Re: [core] The CORE WG has placed
> draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"
>
>
>
> Hi,
>
>
>
> I don't think it is needed because the client is supposed to know the SID
> mappings outside of YANG library.
>
> This library is likely to be very static on a YoT device. Maybe changing
> once per firmware upgrade.
>
> It does not really need optimized retrieval.
>
>
>
> I prefer to keep the models the same between NC/RC and CORECONF.
>
> The YANG to CBOR solution should include ways to make the message encoding
> more efficient.
>
> That way, the same application logic can use whatever protocol operations
> are needed, instead of special CORECONF models.
>
>
>
>
>
> Andy
>
>
>
>
>
> On Mon, Jul 22, 2019 at 5:23 PM Michel Veillette <
> Michel.Veillette@trilliant.com> wrote:
>
> Hi Andy
>
>
>
> About “draft-veillette-core-yang-library”, should we postpone the working
> group adoption of this draft to get more time to work on a different
> solution?
>
>
>
> I raising this topic because the current CoMI draft (
> https://tools.ietf.org/html/draft-ietf-core-comi-07#section-6
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-core-comi-07%23section-6&data=02%7C01%7C%7C2489ae00202046b470fc08d70f05624c%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636994388123365593&sdata=UF0b3Tg6AFTojtId%2BfWjqzwS06UmnFD2TBa9%2B%2Ffkr3o%3D&reserved=0>)
> have a mandatory reference to it. We either need to change the content of
> CoMI or commit to bring ietf-constrained-yang-library to life.
>
>
>
> Regards,
>
> Michel
>
>
>
> *From:* Michel Veillette
> *Sent:* 15 juillet 2019 10:37
> *To:* Andy Bierman <andy@yumaworks.com>om>; IETF Secretariat <
> ietf-secretariat-reply@ietf.org>
> *Cc:* draft-veillette-core-yang-library@ietf.org; core-chairs@ietf.org;
> Core <core@ietf.org>
> *Subject:* RE: [core] The CORE WG has placed
> draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"
>
>
>
> Hi Andy
>
>
>
> I effectively see some values in supporting the module names.
>
> However, these names should be optional leaves and not mandatory keys.
>
> Simply augmenting the existing “ietf-yang-library” will increase its size,
> which makes this solution even less friendly to constrained devices and
> networks.
>
>
>
> Hope to see you in MTL to discuss these changes,
>
> Michel
>
>
>
> *From:* Andy Bierman <andy@yumaworks.com>
> *Sent:* 12 juillet 2019 17:16
> *To:* IETF Secretariat <ietf-secretariat-reply@ietf.org>
> *Cc:* draft-veillette-core-yang-library@ietf.org; core-chairs@ietf.org;
> Core <core@ietf.org>
> *Subject:* Re: [core] The CORE WG has placed
> draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"
>
>
>
>
>
>
>
> On Thu, Jul 11, 2019 at 8:32 AM IETF Secretariat <
> ietf-secretariat-reply@ietf.org> wrote:
>
>
> The CORE WG has placed draft-veillette-core-yang-library in state
> Call For Adoption By WG Issued (entered by Carsten Bormann)
>
> The document is available at
> https://datatracker.ietf.org/doc/draft-veillette-core-yang-library/
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-veillette-core-yang-library%2F&data=02%7C01%7C%7C2489ae00202046b470fc08d70f05624c%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636994388123365593&sdata=r0Q%2F%2BiyhhWFRFeGUI0n0IXUVjk9m%2BcXSxyQfvDGtSUs%3D&reserved=0>
>
>
>
>
>
> I do not know if there is a clear problem statement presented and agreed
> upon by the CORE WG yet.
>
> The YANG Library (RFC 8525) is used by a server to provide a client with
> details about the YANG modules
>
> that are implemented in the server.
>
>
>
> The draft proposed for adoption is a cut-and-paste-and-replace version of
> this RFC.
>
> The strings used as list keys (e.g., /yang-library/module/name) are
> replaced by SID values.
>
> Other key leafs such as /yang-library/schema/name are replaced by int8
> leafs instead of strings.
>
>
>
> IMO there are better solution approaches, considering that this data
> structure will be
>
> relatively static, and there is a caching mechanism built into RFC 8525 to
> reduce
>
> retrieval of the entire YANG library.
>
>
>
> It does not seem realistic that a server would have only SIDs installed
> and no way to get the module names.
>
> This is a short list, unlike the list of YANG data nodes. So it should be
> OK to simply augment the existing module
>
> with SID values.  If the list key replacements are really needed, then a
> deviation module could be used by CORECONF
>
> (e.g. deviate replace {type-stmt}) instead of a replacement module.
>
>
>
> I agree it will be important for a CORECONF client to determine the YANG
> library details for each server.
>
> This could be offline data or directly retrievable from the server. The
> solution need to be resolved by the WG.
>
> I support the problem statement by not this solution.
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> Comment:
> Till 2019-07-18
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&data=02%7C01%7C%7C2489ae00202046b470fc08d70f05624c%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636994388123375588&sdata=bDB3hCRSWLR%2BTWigUMmLlTSndkumQc469l46HjE%2BgPI%3D&reserved=0>
>
>