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

Robert Wilton <rwilton@cisco.com> Sun, 25 February 2018 18:38 UTC

Return-Path: <rwilton@cisco.com>
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 409C31270AE for <netmod@ietfa.amsl.com>; Sun, 25 Feb 2018 10:38:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 NJRKINPEVDJ6 for <netmod@ietfa.amsl.com>; Sun, 25 Feb 2018 10:38:14 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C26D124D6C for <netmod@ietf.org>; Sun, 25 Feb 2018 10:38:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10206; q=dns/txt; s=iport; t=1519583894; x=1520793494; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=3j8w91XVVTLiPJir5/GyDKESxuYA+7e/UP9ms20SNu8=; b=DXYCsKGuHWopg1cs32bVuLIDin/GU+HeXuH9904n8NFJV3ieQ3iOwMEC q8oWDMKXasXBDT6WbuKE0qi1BRwGh8+kH5i65GJZBQN1VKm6JMROiC5r0 jsgI+aCqXXaVVWGLwkv8cBeu0ghxU2HGR0GUxoTr0yTQE4migwyQVW0kP o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAAA8AZNa/xbLJq1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGENXAog1SKInSOVzJ7G5YFFIICChgLhEFPAoMMGAECAQEBAQE?= =?us-ascii?q?BAmsohSQBAQQBASEECwEFNgIJEAsOCgICERUCAicwBg0GAgEBF4R1EKsggW06h?= =?us-ascii?q?HSDboIUAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4gKgWYpgXZYNoMuAQGBLBo?= =?us-ascii?q?LAQEeP4JOgmUFkS6QMwmUIIIGhWaDP4c1iWeEaoQrK4JOgS8eOIFRMxoIGxU6g?= =?us-ascii?q?kOEWkA3ijeCOQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.47,393,1515456000"; d="scan'208";a="2282655"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Feb 2018 18:38:11 +0000
Received: from [10.61.197.158] ([10.61.197.158]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w1PIcBNP022348; Sun, 25 Feb 2018 18:38:11 GMT
To: Christian Hopps <chopps@chopps.org>
Cc: Martin Bjorklund <mbj@tail-f.com>, 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> <87woz2a3x1.fsf@chopps.org>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com>
Date: Sun, 25 Feb 2018 18:38:11 +0000
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: <87woz2a3x1.fsf@chopps.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/KY1ZPGdl-X8hQNb8J_1zpxMd7bo>
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: Sun, 25 Feb 2018 18:38:17 -0000

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

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