Re: [netmod] yang-data issues

Ladislav Lhotka <lhotka@nic.cz> Tue, 23 October 2018 07:07 UTC

Return-Path: <lhotka@nic.cz>
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 19403130EE3 for <netmod@ietfa.amsl.com>; Tue, 23 Oct 2018 00:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 CGpSyYoQRfP0 for <netmod@ietfa.amsl.com>; Tue, 23 Oct 2018 00:07:47 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2FF4130EA0 for <netmod@ietf.org>; Tue, 23 Oct 2018 00:07:46 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 86DF16060F; Tue, 23 Oct 2018 09:07:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1540278463; bh=/MUCzFWrgv3ZXsTgGPducZfVKL2fflSm1N4TffDM2cc=; h=From:To:Date; b=r01qmNHDxv3LZ4KOSWYsbwSTUvMxBAQe8mUdWzjCHuQHUNHMyNjuW75Zna823QpmP T9vywHq+YI83rmHQnNt4Gx228JFOr+Yw4q3AcCt3U5grEHeC5+k+8xX0xF8muDjaer BynNUiJMLsX9FDKC2eqFYISMg1OAIPooOHb7BgjQ=
Message-ID: <9636de74e2a088fa87dab9cadd43d09db23a2d89.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>, Kent Watsen <kwatsen@juniper.net>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Date: Tue, 23 Oct 2018 09:07:43 +0200
In-Reply-To: <CABCOCHT5NYseHZoqFR4FDV+0upePvQe=iUTwiuFAspcD-ejuWw@mail.gmail.com>
References: <20180911.104447.2165943059473950359.mbj@tail-f.com> <DAEC916E-564D-436E-8B34-6235BDC466AC@juniper.net> <CABCOCHT5NYseHZoqFR4FDV+0upePvQe=iUTwiuFAspcD-ejuWw@mail.gmail.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ymFN-z6EG6bveVRCvzO9WddkgHQ>
Subject: Re: [netmod] yang-data issues
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: Tue, 23 Oct 2018 07:07:50 -0000

On Mon, 2018-10-22 at 10:41 -0700, Andy Bierman wrote:
> 
> 
> On Sat, Oct 20, 2018 at 5:48 AM, Kent Watsen <kwatsen@juniper.net>; wrote:
> > Folks,
> > 
> > Can we get some quick replies to this email?
> > 
> 
> 
> At the last IETF there were people that said both yang-data and augment-yang-
> data extensions
> were needed and they wanted this work to be completed quickly.  Is that still
> the case?
> 
> 
> IMO, NMDA and yang-library-bis offer a better solution path (which has been
> brought up before).
> If there is a need for specialized datastores like "factory-default" then why
> not have
> an abstract datastore or abstract module-set? 

I agree, this has been my proposal all along. YANG should be able to cover such
uses out of the box. Extensions like yang-data only make the whole thing more
complicated.

Sometimes it it not even necessary to introduce an ad hoc datastore, a "schema"
entry from yang-library-bis could be sufficient.

> I do not think current YANG supports this
> approach very well (because modules used outside a server do not have yang-
> library)
> but that could probably be fixed with yang-instance-data

In many cases yang-library(-bis) can be used without the metadata provided by
yang-instance-data. For example, my yangson library uses YANG library data
(JSON) for specifying the complete data model:

https://yangson.labs.nic.cz/cmdline.html

Pyang uses NETCONF hello (XML) for the same purpose.

Lada

> 
> 
> > Kent // all hats
> > 
> > 
> 
> 
> Andy
>  
> > 
> > -----Original Message-----
> > From: netmod <netmod-bounces@ietf.org>; on behalf of Martin Bjorklund <
> > mbj@tail-f.com>;
> > Date: Tuesday, September 11, 2018 at 4:45 AM
> > To: "netmod@ietf.org"; <netmod@ietf.org>;
> > Subject: [netmod] yang-data issues
> > 
> > Hi,
> > 
> > The authors of draft-ietf-netmod-yang-data-ext have been discussing
> > the two remaining issues on this draft; the issue of whether a
> > yang-data structure must have unique top-level node names or not, and
> > the issue of the syntax for augment-yang-data.  We haven't been able
> > to find agreement with the current proposal, so I have a suggestion
> > for a slightly modified yang-data statement (which may have been
> > discussed before):
> > 
> > The idea is to encode a yang-data extension the same way as anydata,
> > i.e., as a container.  For example:
> > 
> >   yd:yang-data modify-subscription-datastore-error-info {
> >       description
> >         "This yang-data MAY be provided as part of a subscription's RPC
> >         error response when there is a failure of a
> >         'modify-subscription' RPC which has been made against a
> >         datastore.  This yang-data MUST be used if hints are to be
> >         provides back to the subscriber.";
> >       leaf reason {
> >         type identityref {
> >           base sn:modify-subscription-error;
> >         }
> >         description
> >           "Indicates the reason why the subscription has failed to
> >           be modified.";
> >       }
> >       uses hints;
> >     }
> > 
> > This would be encoded as:
> > 
> >   <modify-subscription-datastore-error-info>
> >     <reason>foo</reason>
> >     <period-hint>42</period-hint>
> >     ...
> >   </modify-subscription-datastore-error-info>
> > 
> > 
> > Since the structure is always encoded as a container, it follows that
> > it can have any data definition statement as substatement, with no
> > restriction on naming and type of statement.  An instance of this can
> > trivially be a complete instance document in XML w/o additional
> > context, works well with JSON, and can appear in an error-info
> > structure.
> > 
> > Such a structure can be augemented as:
> > 
> >   yd:augment-yang-data /sn:modify-subscription-datastore-error-info {
> >     leaf foo { ... }
> >   }
> > 
> > The drawback is that it forces the use of an extra container in the
> > encoding.  OTOH, most usages of current rc:yang-data follows this
> > pattern:
> > 
> >   rc:yang-data modify-subscription-datastore-error-info {
> >     container modify-subscription-datastore-error-info {
> >       ...
> >     }
> >   }
> > 
> > 
> > 
> > 
> > /martin
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7nlVu5dJaa8XsD0LRd0VTH301caVRUXGsa6L-UgXVRE&s=1o7vXH-j8Ha6xbJFTG1jjNzy9JQw7k-UWIqpeCr8qrk&e=
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67