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

Lou Berger <lberger@labn.net> Fri, 23 February 2018 12:45 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 1A07812D949 for <netmod@ietfa.amsl.com>; Fri, 23 Feb 2018 04:45:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 zDb2gKQCydd0 for <netmod@ietfa.amsl.com>; Fri, 23 Feb 2018 04:45:00 -0800 (PST)
Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C88124239 for <netmod@ietf.org>; Fri, 23 Feb 2018 04:45:00 -0800 (PST)
Received: from [::1] (port=48188) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from <lberger@labn.net>) id 1epCih-000177-Fo; Fri, 23 Feb 2018 15:44:59 +0300
To: Martin Bjorklund <mbj@tail-f.com>, rwilton@cisco.com
Cc: netmod@ietf.org
References: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net> <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <61afc424-4131-2871-b752-59c086dd4727@labn.net>
Date: Fri, 23 Feb 2018 07:44:53 -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.103628.1174590223555999274.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 - newdragon.webhostserver.biz
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com
X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/3iqtOqyGlOEL2kc168N8_UfRzmc>
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 12:45:02 -0000

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 ?  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.

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