Re: [netmod] Proposal for minimalist full NMDA support in schema mount
Robert Wilton <rwilton@cisco.com> Mon, 26 February 2018 14:16 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 B155D120725 for <netmod@ietfa.amsl.com>; Mon, 26 Feb 2018 06:16:51 -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 HmoppFKqw2Da for <netmod@ietfa.amsl.com>; Mon, 26 Feb 2018 06:16:50 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E305127599 for <netmod@ietf.org>; Mon, 26 Feb 2018 06:16:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11986; q=dns/txt; s=iport; t=1519654609; x=1520864209; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=gOpFH2EJyZetPu4b4fSx7cEAlO24wqrJztACV4u4krU=; b=DEh2dMuZhbcpG+hI+ET6DkZR4gZXyUDFuXj6U/I6rf8a+HhW/kn3Rra3 jIKm2KoA8KdUVLkviOZHVXZ5yN1DKzbfQNehwU6Rzko10rASS0tzYGg7g tGtJVmWq98Dn1oW/lfesyJVJTTTOYYhbh0qxLdvpcUJNrg9Csgklr93mk E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CQAABnFpRa/xbLJq1SChkBAQEBAQEBAQEBAQEHAQEBAQGENXAog1SKInSOWTJ7G5YFFIICChgLhEFPAoMWGAECAQEBAQEBAmsohSMBAQEDAQEBIQQLAQU0AgIZCw4KAgIRFQICJzAGAQwGAgEBF4RtCBCqfoFtOoR0g3GCFAEBAQEBAQEDAQEBAQEBAQEBAQEYBYEPiAqBZimBdlg2gy4BAYEsGgsBAR4/gk6CZQWRLpAzCZQgggaFZoM/hzWJZ4RqhCsrgk6BLx44gVEzGggbFTqCQ4RaQDeKHoI5AQEB
X-IronPort-AV: E=Sophos;i="5.47,396,1515456000"; d="scan'208";a="2251020"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 14:16:29 +0000
Received: from [10.63.23.77] (dhcp-ensft1-uk-vla370-10-63-23-77.cisco.com [10.63.23.77]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w1QEGTEm025734; Mon, 26 Feb 2018 14:16:29 GMT
To: Christian Hopps <chopps@chopps.org>, 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> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com> <87vaej4zje.fsf@nic.cz>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <81c80358-75fa-d7a6-3ead-c1c1e6633e22@cisco.com>
Date: Mon, 26 Feb 2018 14:16:29 +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: <87vaej4zje.fsf@nic.cz>
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/vDuQVIJS8enUgIkuy4Z4kFTKUC4>
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:16:52 -0000
Hi Lada, On 26/02/2018 14:05, Ladislav Lhotka wrote: > 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. Sorry, I think that my point wasn't clear: I don't think that you can go from the ietf-yang-schema-mount YANG module defined in SM -08 to something like the ietf-yang-schema-mount YANG module defined in pre09 in a backwards compatible way. I.e. just following the "Updating a Module" in RFC 7950 chapter 11. In terms of the actual modules that are being mounted, I agree, all modules will work in both. > >> 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 Thanks, Rob > >> 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
- [netmod] Proposal for minimalist full NMDA suppor… Lou Berger
- Re: [netmod] Proposal for minimalist full NMDA su… Robert Wilton
- Re: [netmod] Proposal for minimalist full NMDA su… Martin Bjorklund
- Re: [netmod] Proposal for minimalist full NMDA su… Lou Berger
- Re: [netmod] Proposal for minimalist full NMDA su… Martin Bjorklund
- Re: [netmod] Proposal for minimalist full NMDA su… Lou Berger
- Re: [netmod] Proposal for minimalist full NMDA su… Robert Wilton
- Re: [netmod] Proposal for minimalist full NMDA su… Lou Berger
- Re: [netmod] Proposal for minimalist full NMDA su… Robert Wilton
- Re: [netmod] Proposal for minimalist full NMDA su… Ladislav Lhotka
- Re: [netmod] Proposal for minimalist full NMDA su… Lou Berger
- Re: [netmod] Proposal for minimalist full NMDA su… Juergen Schoenwaelder
- Re: [netmod] Proposal for minimalist full NMDA su… Christian Hopps
- Re: [netmod] Proposal for minimalist full NMDA su… Christian Hopps
- Re: [netmod] Proposal for minimalist full NMDA su… Juergen Schoenwaelder
- Re: [netmod] Proposal for minimalist full NMDA su… Christian Hopps
- Re: [netmod] Proposal for minimalist full NMDA su… Robert Wilton
- Re: [netmod] Proposal for minimalist full NMDA su… Christian Hopps
- Re: [netmod] Proposal for minimalist full NMDA su… Robert Wilton
- Re: [netmod] Proposal for minimalist full NMDA su… Ladislav Lhotka
- Re: [netmod] Proposal for minimalist full NMDA su… Robert Wilton
- Re: [netmod] Proposal for minimalist full NMDA su… Ladislav Lhotka
- Re: [netmod] Proposal for minimalist full NMDA su… Martin Bjorklund
- Re: [netmod] Proposal for minimalist full NMDA su… Christian Hopps
- Re: [netmod] Proposal for minimalist full NMDA su… Ladislav Lhotka
- Re: [netmod] Proposal for minimalist full NMDA su… Juergen Schoenwaelder
- Re: [netmod] Proposal for minimalist full NMDA su… Ladislav Lhotka
- Re: [netmod] Proposal for minimalist full NMDA su… Martin Bjorklund
- Re: [netmod] Proposal for minimalist full NMDA su… Kent Watsen
- Re: [netmod] Proposal for minimalist full NMDA su… Christian Hopps
- Re: [netmod] Proposal for minimalist full NMDA su… Ladislav Lhotka
- Re: [netmod] Proposal for minimalist full NMDA su… Ladislav Lhotka