Re: [netmod] Proposal for minimalist full NMDA support in schema mount

Lou Berger <lberger@labn.net> Fri, 23 February 2018 13:19 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 D7DFC12E047 for <netmod@ietfa.amsl.com>; Fri, 23 Feb 2018 05:19:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 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] 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 jVeGhGsalcsw for <netmod@ietfa.amsl.com>; Fri, 23 Feb 2018 05:19:05 -0800 (PST)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 E139212E045 for <netmod@ietf.org>; Fri, 23 Feb 2018 05:19:04 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 7386D215C48 for <netmod@ietf.org>; Fri, 23 Feb 2018 06:19:04 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id EDK01x00i2SSUrH01DK34P; Fri, 23 Feb 2018 06:19:04 -0700
X-Authority-Analysis: v=2.2 cv=M5g9E24s c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=LYxLP8SNtGR-Xs6CNKEA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 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:Cc:To:Subject:Sender:Reply-To: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=fk0mWo9FCSS9OpJmDotcO4e6bhmr+i/NHaAVtojqHtU=; b=QHEefQv3y2K5+Nv3VW8bYj2VT/ FN0UwqiZQQPW4H8oMaSjCfqzc6zxFksETJuoEaLC6qMI9vCo2ftdgPBDyhCw+gHntjwVHGZhCBy3K IIxQNEcBmPeoqJ5JHmlATlITx;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:38020 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from <lberger@labn.net>) id 1epDFc-002aVq-NE; Fri, 23 Feb 2018 06:19:00 -0700
To: Martin Bjorklund <mbj@tail-f.com>
Cc: rwilton@cisco.com, netmod@ietf.org
References: <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <61afc424-4131-2871-b752-59c086dd4727@labn.net> <20180223.135509.1022283362077802966.mbj@tail-f.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <d95dfc69-8a84-840f-8dd4-ee3b38bfbdd3@labn.net>
Date: Fri, 23 Feb 2018 08:18:57 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180223.135509.1022283362077802966.mbj@tail-f.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
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: 1epDFc-002aVq-NE
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]:38020
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/KztoX5gZCf3qIbRWLnjvGL03iyE>
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
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: Fri, 23 Feb 2018 13:19:07 -0000

Martin,


On 2/23/2018 7:55 AM, Martin Bjorklund wrote:
> Hi,
>
> Lou Berger <lberger@labn.net> wrote:
>> Martin/Rob,
>>
>>      Back when the topic was raised for the first time publicly
>> (Yokahama) and discussed in the WG [1] *any* solution would have been
>> workable.  At this point > 2 years later, do you really think it is
>> reasonable to do a rewrite of the solution ?
> I don't agree that this is a rewrite of the solution.  I want to keep
> the mountpoint statement.  I want to keep the two mechanisms inline
> and use-schema.  The only change we're talking about is alinging the
> read-only data that the server makes available with YLbis.
The requirement to use YL-bis is enough for me classifying the change as 
a rewrite.  The current draft is usable with both RFC7895 and YL-bis.  
This is a pretty major change, particularly for anyone working on a 
client or server implementation now, or who wants to soon.

>   This is
> quite trivial.
 From *your* perspective.  There are other's that disagree (See Dean's 
and Chris' mail - they don't want *any* changes and are perfectly happy 
with -08).

>   We have documented this in the pre09 branch, and this
> is imo ready to be published.
It would still need to go through normal working processing which would, 
hopefully, garner some review from some/any of the users or operator who 
contributed to the development of -08.   For example, in PRE09 I see 
some complexities in how mount points with different schema in different 
DS works that seem unnecessary,  also the recursive case is not 
documented - even if I'm wrong and all that is needed is better 
understanding (by me) or clarification (in the doc),  it still would 
need to addressed as part of normal WG processing.

Lou

>
>> Are you really not
>> willing to live with a compromise that addresses the issue albeit in
>> way that you/some view as suboptimal?
>>
>> Keep in mind that we had lots of discussions on what is
>> optimal/preferred and there are/were different view points on this,
>> compromises were made that increased complexity for others and these
>> were accepted in interest of progressing *any* deployable solution.
> Yes.  I don't want to give up these compromises.  I know that others
> want to, and/or explore other solutions.  That's *not* what I'm
> proposing.
>
>
> /martin
>
>
>
>> Lou
>>
>> [1]
>> https://datatracker.ietf.org/meeting/interim-2016-netmod-01/session/netmod
>>
>> On 2/23/2018 4:36 AM, Martin Bjorklund wrote:
>>> Hi,
>>>
>>> Robert Wilton <rwilton@cisco.com> wrote:
>>>> Hi Lou,
>>>>
>>>> I think that this solution is inferior to the model presented in
>>>> pre-09.
>>> I agree.  Servers that are NMDA-compliant, or implements YANG Library
>>> bis will have to present schemas in two different structures,
>>> depending on where the schema is used, and clients will have to code
>>> for both.  With the solution in pre-09, there is just one structure.
>>> A single structure also has other benefits (apart from being simpler),
>>> e.g., if we augment it with the meta data that has been discussed
>>> recently, we can augment a single structure.
>>>
>>>
>>> /martin
>>>
>>>
>>>
>>>> I would prefer that we publish pre09 instead, potentially including
>>>> the -08 model in the appendix if that helps progress the document in a
>>>> more expedient fashion.
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>> On 22/02/2018 16:18, Lou Berger wrote:
>>>>> Hi,
>>>>>
>>>>> (I have a bunch of different roles WRT this work.  This mail is being
>>>>> sent as an individual - as chair, I fully support the previous chair
>>>>> statements on this draft.)
>>>>>
>>>>> Chris and I have come up with a proposal on how to provide full NMDA
>>>>> as part the existing schema-mount module.  Our motivation was to
>>>>> enable full NMDA support with *minimal* change to the model and
>>>>> disruption to the LC'ed work.  The key NMDA limitation, with -08, that
>>>>> we are aiming to address is the ability to support different mounted
>>>>> schema in different datastores for non-inline mount points. (See more
>>>>> detailed description below if interested full nuances of limitations
>>>>> of -08)
>>>>>
>>>>> What we came up with was  to simply add a (leaf)list to identify in
>>>>> which datastores a
>>>>> schema-mount schema is valid/present. This is somewhat similar to
>>>>> YL-bis schema/module-set. Specifically we're proposing (see below for
>>>>> full tree below):
>>>>>
>>>>>              +--ro schema* [name]
>>>>>                 +--ro name           string
>>>>> ADD          +--ro datastore*    ds:datastore-ref {revised-datastores}
>>>>>
>>>>> This approach has the advantages of supporting different mounted
>>>>> schema in different DSes, working with both NMDA and non-NMDA
>>>>> implementations, supporting all of the extensively discussed features
>>>>> of schema mount (including recursive mounts), and having minor/scoped
>>>>> impact on all dependent work.  The main downside is that it isn't the
>>>>> most optimal/compact solution possible if we were to base this work on
>>>>> YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all
>>>>> perspectives, but it is what was agreed to as sufficient by those who
>>>>> contribute to the WG discussion.
>>>>>
>>>>> In short, we see this as a solution to  addresses the raised last call
>>>>> issue with the minimal impact on -08 and dependent work -- which is
>>>>> what is appropriate given where we are in the process.
>>>>>
>>>>> So our/my question really is:
>>>>>
>>>>>       Is this a solution that you/all can live with?
>>>>>
>>>>> Note: optimization, design preference and perfect alignment with use
>>>>> or YL-bis are not part of our question as we both don't think that is
>>>>> the right question given where we are in the WG process.
>>>>>
>>>>> Lou (with ideas developed with Chris, and chair hat off)
>>>>>
>>>>> ======
>>>>> Details -- for those who want
>>>>> ======
>>>>> As background, my understanding/view is that the -08 version of the
>>>>> both NMDA and non-NMDA supporting implementations, but there are
>>>>> limitations in its NMDA applicability. Used with Yang Library,
>>>>> [rfc7895], only non-NMDA implementations can be supported.  When used
>>>>> with the revised Yang Library defined in
>>>>> [I.D.ietf-netconf-rfc7895bis-],  NMDA implementations  can be
>>>>> supported with certain limitations. Specifically, this document
>>>>> requires use of the now deprecated module-list grouping, and the same
>>>>> schema represented in schema list of the Schema Mount module MUST be
>>>>> used in all datastores.  Inline type mount points, which don't use the
>>>>> schema list,  can support different schema in different data stores
>>>>> not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
>>>>> YANG library under the inline mount point.
>>>>>
>>>>>       module: ietf-yang-schema-mount
>>>>>           +--ro schema-mounts
>>>>>              +--ro namespace* [prefix]
>>>>>              |  +--ro prefix    yang:yang-identifier
>>>>>              |  +--ro uri?      inet:uri
>>>>>              +--ro mount-point* [module name]
>>>>>              |  +--ro module        yang:yang-identifier
>>>>>              |  +--ro name          yang:yang-identifier
>>>>>              |  +--ro config?       boolean
>>>>>              |  +--ro (schema-ref)?
>>>>>              |     +--:(inline)
>>>>>              |     |  +--ro inline?       empty
>>>>>              |     +--:(use-schema)
>>>>>              |        +--ro use-schema* [name]
>>>>>              |           +--ro name
>>>>>              |           |       -> /schema-mounts/schema/name
>>>>>              |           +--ro parent-reference*   yang:xpath1.0
>>>>>              +--ro schema* [name]
>>>>>                 +--ro name           string
>>>>> ADD          +--ro datastore*    ds:datastore-ref {revised-datastores}
>>>>>                 +--ro module* [name revision]
>>>>>                 |  +--ro name                yang:yang-identifier
>>>>>                 |  +--ro revision            union
>>>>>                 |  +--ro schema?             inet:uri
>>>>>                 |  +--ro namespace           inet:uri
>>>>>                 |  +--ro feature*            yang:yang-identifier
>>>>>                 |  +--ro deviation* [name revision]
>>>>>                 |  |  +--ro name        yang:yang-identifier
>>>>>                 |  |  +--ro revision    union
>>>>>                 |  +--ro conformance-type    enumeration
>>>>>                 |  +--ro submodule* [name revision]
>>>>>                 |     +--ro name        yang:yang-identifier
>>>>>                 |     +--ro revision    union
>>>>>                 |     +--ro schema?     inet:uri
>>>>>                 +--ro mount-point* [module name]
>>>>>                    +--ro module        yang:yang-identifier
>>>>>                    +--ro name          yang:yang-identifier
>>>>>                    +--ro config?       boolean
>>>>>                    +--ro (schema-ref)?
>>>>>                       +--:(inline)
>>>>>                       |  +--ro inline?       empty
>>>>>                       +--:(use-schema)
>>>>>                          +--ro use-schema* [name]
>>>>>                             +--ro name
>>>>>                             |       -> /schema-mounts/schema/name
>>>>>                             +--ro parent-reference*   yang:xpath1.0
>>>>>
>>>>> We would expect that the revised-datastores feature would be used
>>>>> (perhaps required) for any implementation that supports
>>>>> ietf-datastores
>>>>> and yl-bis.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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