Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

Martin Bjorklund <mbj@tail-f.com> Wed, 13 December 2017 07:41 UTC

Return-Path: <mbj@tail-f.com>
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 56A9D12700F; Tue, 12 Dec 2017 23:41:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 VpK9CdTRZIyg; Tue, 12 Dec 2017 23:41:51 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CBF40126C26; Tue, 12 Dec 2017 23:41:50 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 9C4AE1AE02BD; Wed, 13 Dec 2017 08:41:49 +0100 (CET)
Date: Wed, 13 Dec 2017 08:40:30 +0100
Message-Id: <20171213.084030.1399882156946529918.mbj@tail-f.com>
To: vladimir@transpacket.com
Cc: netmod@ietf.org, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <ba42f0ee-3926-071a-3611-199af31910aa@transpacket.com>
References: <b3159aa5-93e4-23eb-406e-083289a4767d@transpacket.com> <20171212.202001.1743562517319162368.mbj@tail-f.com> <ba42f0ee-3926-071a-3611-199af31910aa@transpacket.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/cIGl2--76-iofXR7QJZLI4egqnk>
Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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, 13 Dec 2017 07:41:53 -0000

Vladimir Vassilev <vladimir@transpacket.com> wrote:
> On 12/12/2017 08:20 PM, Martin Bjorklund wrote:
> 
> > Hi,
> >
> > Vladimir Vassilev <vladimir@transpacket.com> wrote:
> >>
> >> On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote:
> >>> On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote:
> >>>> Vladimir Vassilev <vladimir@transpacket.com> wrote:
> >>>>> On 11/15/2017 06:29 PM, Robert Wilton wrote:
> >>>>>
> >>>>>> I don't think that this is really a good idea.  You would end up
> >>>>>> returning server metadata in addition to the configuration.
> >>>>> Obviously RFC 7895 defines only config false; data and I was not
> >>>>> proposing a change to that. But I agree something has to be added to
> >>>>> complete the solution. Special purpose datastore identities can be
> >>>>> defined that return instance of yang-library data when read with
> >>>>> <get-data>. (Datastores with yang-library config false; only data not
> >>>>> represented in 'operational')
> >>>>>
> >>>>> Adding this special yang-library-datastore to the proposed
> >>>>> ietf-datastores container e.g.
> >>>>>
> >>>>> module: ietf-datastores
> >>>>> +--ro datastores
> >>>>> |  +--ro datastore* [name]
> >>>>> |     +--ro name          identityref
> >>>>> |     +--ro yang-library-datastore          identityref
> >>>>>
> >>>> I don't understand this proposal.  How would a client learn the
> >>>> library for <running>?  For <operational>?
> >>> My interpretation is that the client reads the datastores list from
> >>> <operational> and the list entries give you the identity of a separate
> >>> datastore that gives you the content of the yang library for that
> >>> datastore. (For each datastore, you have a separate datastore to
> >>> report its yang library.)
> >> Yes. The default value for yang-library-datastore leaf is
> >> ds:operational (the only possible one for the ds:operational
> >> datastore). This is backward compatible. If one needs different model
> >> for 'running', etc. then a new datastore identity has to be defined
> >> and set in place of the default value. Then this identity can be used
> >> to read the yang-library data with <get-data>.
> > Ah, ok.  This is a clever solution, but quite complicated.  It
> > requires several round trips for a client to learn all library
> > instances.  Also, w/o any changes, it is not clear which module-set-id
> > is sent in the capability, and a client must query all module-set-ids
> > in all (meta)datastores in order to just check if it has the latest
> > version or not.  It is also not clear how the existing notification
> > "yang-library-change" would work when there are multiple instances
> > involved.
> How about this?
> module: ietf-datastores
> ...
>   augment /yanglib:yang-library-change:
>     +---- datastore?   identityref

This has the same issue as augementing a datastore leaf-list into the
current /modules-state/modules list would have - old clients won't
understand this new node.


/martin