Re: [netmod] schema mount and YANG library

Lou Berger <lberger@labn.net> Tue, 19 December 2017 12:49 UTC

Return-Path: <lberger@labn.net>
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 F03C012778E for <netmod@ietfa.amsl.com>; Tue, 19 Dec 2017 04:49:16 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 PE1tWRZPFd0c for <netmod@ietfa.amsl.com>; Tue, 19 Dec 2017 04:49:15 -0800 (PST)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 E8211126CD6 for <netmod@ietf.org>; Tue, 19 Dec 2017 04:49:14 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 569551E06F3 for <netmod@ietf.org>; Tue, 19 Dec 2017 05:49:14 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id nopA1w00P2SSUrH01opDb7; Tue, 19 Dec 2017 05:49:14 -0700
X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=W96Dgh_eZOHAMPlv3xAA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=RcY+YW69ba8nmUz6hbEo8o9YjDUg4MeA5RTjMujuU7g=; b=u+9/U3V4Jp3+EGky0xF8gY8O1C jNI6fuqTtLK31YFJnY0hSMpIyKFEi+E+xC2gDJLVgkyjmETiauQprXfv9uod5FUEcDmZiva4vojV9 yt0pRVpE5FQT8FcVPQxCQQ53c;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:39732 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <lberger@labn.net>) id 1eRHKY-0023Ot-M3; Tue, 19 Dec 2017 05:49:10 -0700
To: Ladislav Lhotka <lhotka@nic.cz>, NETMOD WG <netmod@ietf.org>
References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> <1513663919.478.7.camel@nic.cz> <1606e810770.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1513682591.2479.20.camel@nic.cz> <e8830510-e9ef-2179-8c83-763ce379777d@labn.net> <1513686995.2479.41.camel@nic.cz>
From: Lou Berger <lberger@labn.net>
Message-ID: <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@labn.net>
Date: Tue, 19 Dec 2017 07:49:08 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <1513686995.2479.41.camel@nic.cz>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Exim-ID: 1eRHKY-0023Ot-M3
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:39732
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hNqERU68Ew0ZWuxEXdNzSapKfkI>
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 12:49:17 -0000


On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
> On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
>> Hi Lada,
>>
>> On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
>>> On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
>>>> Lada,
>>>>
>>>>
>>>> On December 19, 2017 1:12:35 AM Ladislav Lhotka <lhotka@nic.cz> wrote:
>>>>
>>>>> 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.
>>>>>
>>>> That's not how I read the intent of the current text.  I don't see SM 
>>>> impacting which data stores information is presented.  Just like use of 
>>>> scheme mount doesn't transform RO configuration information into 
>>>> operational information.  I sent you a couple of sentences clarifying
>>>> this 
>>>> at one point, I'll dig up the proposed text and resend.
>>> Please do, this has to be discussed in the WG mailing list.
>> Agreed - that's why I asked to start this thread!
>>
>> Here's the original proposal:
>>
>>   How about at the end of the section [3.2] adding a new
>>   paragraph along the lines of:
>>
>>   It is important to note that both YANG Library and Schema
>>   Mount Modules contain only operational state data. As such,
> s/contain/define/
>
>>   the information in these modules should be retrieved by
>>   clients from operational data stores using the appropriate
> This is based on two assumptions:
>
> 1. For every configuration datastore there is a corresponding operational
> datastore.

well the text is revised below.  In any case, "these modules" refers to
yang library, and yes, I'm assuming YL is always and only in
operational.  If the revised text below isn't clear s/these/YANG Library/ -

>
> 2. For every mount point instance in any configuration datastore there is a
> corresponding mount point instance (with the same path) in an operational
> datastore.
>
> I think that neither of these has to be true in general.
agreed in general, but for inline, where YL is required, it must be true.

>
>>   protocol operations.
> In contrast, the substance of my proposal with metadata annotations is to be
> able to retrieve all schemas from a well-known location in *the* <operational>
> datastore, namely from the top-level YANG library.  
What about a schema that is based on dll that contains modules that
isn't loaded until a mount point is instantiated -- this is certainly a
valid approach for supporting LNEs, but would be precluded in this
approach.  I really don't think a top level approach works for all
inline (managed) types of mounts.

>
>> Given this discussion, we can generalize it further to:
>>
>>   The use of mount points does not impact the nature of the
>>   mounted data or in which data store information is made
>>   available. For example, mounted YANG Library modules contain
>>   only operational state data and, as such, the information in
>>   these modules is available from operational data stores using
>>   the appropriate protocol operations.
> The whole question here is whether and how we can locate the schema for an
> inline mount point in any configuration datastore.
Why is a mounted YL different than a top level YL?  What works for and
is sufficient for the normal case of YL shouldn't be impacted or
modified by SM -- at least that's how I thought we've been talking about
since SM was started.  Again, we never made any special provisions for
any other rw/ro/state data, assuming top level YL is not handled as
metadata, why start now?

I'm getting the impression that your argument may be more about if YL
should be treated as something other than operational data, is this wrong?

Thanks,
Lou

> Lada
>
>> Lou
>>
>>> Lada
>>>
>>>> Lou
>>>>>>> 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
>>>>>
>>