Re: [netmod] schema mount and YANG library

Ladislav Lhotka <lhotka@nic.cz> Tue, 19 December 2017 06:12 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 0E3C4126D46 for <netmod@ietfa.amsl.com>; Mon, 18 Dec 2017 22:12:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level:
X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-0.01, 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 3S46_9q1sygh for <netmod@ietfa.amsl.com>; Mon, 18 Dec 2017 22:12:04 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 A67111205F0 for <netmod@ietf.org>; Mon, 18 Dec 2017 22:12:03 -0800 (PST)
Received: from birdie2 (cst-prg-75-230.cust.vodafone.cz [46.135.75.230]) by mail.nic.cz (Postfix) with ESMTPSA id B849863AF3; Tue, 19 Dec 2017 07:12:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1513663921; bh=So4Dlt6wLL84vURqx8ldGIJsjmA2etqK7nGdgGwTL2k=; h=From:To:Date; b=Epq7TW+867d6k9ZTDpaqOLs882IvA6gfeNeTIKihXg6DKktquPhm2nUKW2aOk6SXV w7OGZU9+Z9s96HsCMvYndtCs/pC/oOq+R/0+bAJ7ShS+cHyHs4amoWBOvmFJr6G7HD TQFi8ekoqNV9vKrGV/hT+pV8RIoDT78JcrmO/Vec=
Message-ID: <1513663919.478.7.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Lou Berger <lberger@labn.net>, NETMOD WG <netmod@ietf.org>
Date: Tue, 19 Dec 2017 07:11:59 +0100
In-Reply-To: <30ba994a-96b5-880c-ea43-b67469933a94@labn.net>
References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/EzmFwA1VRqx69Oj02PsUhAvJo6k>
Subject: Re: [netmod] schema mount and YANG library
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: Tue, 19 Dec 2017 06:12:07 -0000

On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
> lada,
> 
>     See below.
> 
> 
> On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
> > Hi,
> > 
> > unfortunately, using an action for querying embedded YANG library data
> > (needed for the "inline" case of schema mount) doesn't work either
> > because now under NMDA actions can be used only on instances in the
> > <operational> datastore.
> 
> but the inline/embedded library would (only) be present in the in the
> operational datastore, so what's the issue?

Well, the issue is described in my initial mail of this thread: the current text
requires that every instance of an inline mount point contains the embedded YANG library. Tha latter is state data, so the above requirement cannot be satisfied if the mount point instance is in a configuration datastore.

> 
> > However, a good alternative seems to be a metadata annotation along the
> > lines of RFC 7952, for example with the alternative B of the newly
> > proposed YANG library schema:
> > 
> >      md:annotation schema-ref {
> >        type leafref {
> >          path "/yanglib:yang-library/yanglib:schema/yanglib:name";
> >        }
> >      }
> > 
> > In other words, all inline mounted schemas would be included in the
> > top-level YANG library, and mount point instances in all datastores
> > would be annotated with leafref pointing to the actual schema.
> > 
> > Unlike regular state data, it is IMO no problem to permit such
> > annotations in configuration datastores.
> > 
> > Opinions?
> 
> I'm not sure this will work for all architectures of LNEs as well as
> other possible future use cases.  In short, this seems *very* restrictive.

I don't understand, IMO it is not restrictive at all. What kind of restrictions
do you see?

Lada

> 
> Lou
> 
> > 
> > Thanks, Lada
> > 
> > Ladislav Lhotka <lhotka@nic.cz> writes:
> > 
> > > Hi,
> > > 
> > > the following text in sec. 3.2 of schema-mount-08 is wrong for traditional
> > > datastores, and even more so for NDMA:
> > > 
> > >    In case 1 ["inline"], the mounted schema is determined at run time:
> > > every
> > >    instance of the mount point that exists in the parent tree MUST
> > >    contain a copy of YANG library data [RFC7895] that defines the
> > >    mounted schema exactly as for a top-level data model.  A client is
> > >    expected to retrieve this data from the instance tree, possibly after
> > >    creating the mount point.  Instances of the same mount point MAY use
> > >    different mounted schemas.
> > > 
> > > An instance of the mount point in any *configuration* datastores cannot
> > > contain
> > > YANG library (being state data), and so the MUST cannot hold.
> > > 
> > > It is not clear to me how to repair this without considerable
> > > complications
> > > and/or a lot of handwaving. There is actually one good solution but it has
> > > impact on YANG library: the server could provide it in a reply to an
> > > operation,
> > > say "get-yang-library" rather than as state data. Then everything would be
> > > fine
> > > - this operation would turn into an action for the mount point, and it can
> > > be
> > > used equally well for config true and false mount points.
> > > 
> > > So my proposal is to move from YANG library as state data to an operation.
> > > It
> > > could be done along with changing the YANG library structure, so there
> > > will be
> > > little extra impact on implementations. 
> > > 
> > > Lada 
> > > 
> > > -- 
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> > > _______________________________________________
> > > 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