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

Ladislav Lhotka <lhotka@nic.cz> Mon, 26 February 2018 14:05 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 2AA01126E64 for <netmod@ietfa.amsl.com>; Mon, 26 Feb 2018 06:05:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 c3RCB5vfGFrT for <netmod@ietfa.amsl.com>; Mon, 26 Feb 2018 06:05:16 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E7CB3120725 for <netmod@ietf.org>; Mon, 26 Feb 2018 06:05:15 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 923CC1820414; Mon, 26 Feb 2018 15:02:05 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 1C9E318203F6; Mon, 26 Feb 2018 15:02:01 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Robert Wilton <rwilton@cisco.com>, Christian Hopps <chopps@chopps.org>
Cc: netmod@ietf.org
In-Reply-To: <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com>
References: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net> <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <87woz2a3x1.fsf@chopps.org> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com>
Mail-Followup-To: Robert Wilton <rwilton@cisco.com>, Christian Hopps <chopps@chopps.org>, netmod@ietf.org
Date: Mon, 26 Feb 2018 15:05:09 +0100
Message-ID: <87vaej4zje.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/84IrvQdZHbg8v8stgDZO0epClA0>
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: Mon, 26 Feb 2018 14:05:23 -0000

Hi Rob,

Robert Wilton <rwilton@cisco.com> writes:

> Hi Chris,
>
> I've got no desire or intent to try and slow down the NI and LNE drafts, 
> or any that depend on them.  I actually agree that this is critically 
> important that IETF gets modules standardized/finished so that everyone 
> can use them.
>
> However, ...
>
> YLbis has quite a different structure to YL.  The main part of this 
> change was to support NMDA, the other part of this change was to better 
> support things like SM, or YANG packages.
>
> I don't think that there is a clean, backwards compatible, way to go 
> from the YANG module in SM -08 to one that is going to work well with 
> YLbis and other YLbis extensions/augmentations that seem to be coming

I don't think this is true - all YANG modules that work with -08 should
work with pre-09.

> down the line.  Given what we know now, I believe that the correct 
> medium/long term structure for the SM YANG module, taking YLbis into 
> account, is the one proposed in pre09, because it directly augments the 
> YLbis structure, and hence any future augmentations to YLbis should 
> automatically extend to SM mounted schema as well.
>
> I think that the likely future technical issues with the -08 module will be:
> - supporting NMDA in a clean consistent way
> - adding in support for SemVer
> - additional capability reporting as an augmentation to YANG library
>
> So, if -08 proceeds as is, then it seems to me like one of three things 
> will need to happen:
> 1) Their will need to be a non backwards compatible update to the SM 
> model that is the same/similar to pre09.
> 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for 
> explicitly mounted schema.

An acceptable compromise for me would be to publish -08 and accept both
1 and 2 above. The benefits of doing so would be

- LNE/NI work won't be blocked

- some experience may be gained from the implementers that can improve
  the ultimate YLbis-based solution

- there will be more time to reconsider the design and presentation of
  the two concepts (inline and use-schema).

> 3) We accrue technical debt, implementations need to support two YL 
> module structures, the one in SM and the one in YLbis, and future 
> extensions need to augment both the SM structure and YLbis structure.

If we eventually do the right thing, then SM in the -08 form will be
abandoned along with the old YL.

Lada

>
> I don't like the idea of (2) or (3), but I don't know if others will 
> find (1) acceptable.
>
> But I do agree that we are just going round in circles on this:
> - Using the pre09 structure is not acceptable to some folks
> - Publishing a draft with both -08 and pre09 structure is liked by even 
> less folks.
>
> Perhaps publishing -08 is the only option.  My hope is that the WG will 
> support somebody subsequently doing solution (1), otherwise it seems 
> like a missed opportunity to get this right.
>
> Thanks,
> Rob
>
>
> On 24/02/2018 13:54, Christian Hopps wrote:
>> My position,
>>
>> It may be the case that there's even a better cleaner solution; 
>> however, it's simply too late for major modifications to this work 
>> that don't actually address functional failures.  The draft as 
>> proposed works for the people who need to get work done.
>>
>> We have multiple pending RFCs - MISREF on this document. These RFCs 
>> would have to be pulled from the RFC EDITOR queue, and reworked to be 
>> compliant again, and this very well could lead to discovering issues 
>> with your new proposal. Any new issues discovered in either the 
>> pending RFCs *or* in the new solution would then need to be worked out 
>> and fixed. Please recall that this actually occurred on the first 
>> round (i.e., doing the examples led to discovering problems with the 
>> drafts), so it's not unreasonable at all to assume this would happen 
>> again.
>>
>> Look this just isn't a simple change your proposing. It involves a 
>> large upheaval, killing the pending RFC status on multiple documents 
>> that the industry is waiting on. Please see this.
>>
>> Thanks,
>> Chris.
>>
>>
>> Martin Bjorklund <mbj@tail-f.com> writes:
>>
>>> 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
>>>
>>> _______________________________________________
>>> 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