Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07
Andy Bierman <andy@yumaworks.com> Thu, 09 November 2017 17:44 UTC
Return-Path: <andy@yumaworks.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 BAC3D1287A3 for <netmod@ietfa.amsl.com>; Thu, 9 Nov 2017 09:44:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 mKJp626zAj8B for <netmod@ietfa.amsl.com>; Thu, 9 Nov 2017 09:44:34 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B669127B60 for <netmod@ietf.org>; Thu, 9 Nov 2017 09:44:27 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id r129so8150555lff.8 for <netmod@ietf.org>; Thu, 09 Nov 2017 09:44:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=trXjje9zTG6mp+VV0eZlk2IbmwrjE/tdXD+hRAVah3I=; b=L+/bLHEIEUglO6o7VhBSF7F9ckUbXjoQI9eUTWwKUn39NOe4ZjZHBJye6D6oLV+LXG v0fJHrmxvZFNhuqMr+yhi8MG3VJvoytMNgvSLHju2jRRnamGUKogJNmnCMGosc/HKvny PZ4bGkSVkfLgW8rl1S9fISB9YaeDAFBlR/CyTlmkSAHCnzGVt3qPnjSJYz6S2hNMiX4s uxL/gNXIOEQV4h/FftItwj32/Zyp6FeFksnbeT7iVyIFBu++zf/gny++hZV0eUpUcwLE n65zqXLCJ4bhV9i/OpURfwQ616181BJaWRvM6E/vk3r1m7B6cg/25OVGrLx6MZdd9mWf AWmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=trXjje9zTG6mp+VV0eZlk2IbmwrjE/tdXD+hRAVah3I=; b=Sk0lyFAPMNONjZwi089PgG3eAVkiTNae487KzNiLW7ckfiZY1K1HFBLspnQNvxTaj3 bXq54AiRnjEbw57jMIWoMvU/ZelggWLe+nlc8aJGeK3F9U6TEiGgiu/i6B+tIViS5bXB 3HnHXjgnqe4kXQgFtEhYKIdKklS++djGuJG5QWn/byetRhZ7N8A+n1XSsV4jWgCyBiBv SVNGPxVTOraYWeGmApEUcrou+c+EFJbGb0S696lpAK7+k8cnB6ZTrEUbf4cWGVUO57xV Zt7j+h5p8sfOWubq5W0Ouiz0vdfprQNc5BOMeWI5n4dbkkqsX1TtY/OiPyAcz70WZAEk zP4Q==
X-Gm-Message-State: AJaThX6IVez1NuCjOr8SunW86Zgydu+ulg5ilyo7Z/2/9jUanEiDAs8G AMLMr0KUi6O62hmUSkSHVWbNHm22a41Uah55ux2Hgg==
X-Google-Smtp-Source: AGs4zMYkTC4vhUgF7L6/rBON6SwzGh/i6fKI3aZo5k+gjn6HLWm9nnWpIxE/TbSRT4aYiJCmg/55sUVFkxgBUMFQUL0=
X-Received: by 10.25.23.165 with SMTP id 37mr522618lfx.202.1510249465360; Thu, 09 Nov 2017 09:44:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.214.9 with HTTP; Thu, 9 Nov 2017 09:44:24 -0800 (PST)
In-Reply-To: <1510247543.4067.4.camel@nic.cz>
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz> <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com> <87d14rjwdq.fsf@nic.cz> <CABCOCHTy2MLagXikkwwaOXM+b4-=Ho54wjZEsYsO7yHbxEdTfQ@mail.gmail.com> <1510247543.4067.4.camel@nic.cz>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 09 Nov 2017 09:44:24 -0800
Message-ID: <CABCOCHQ6+_r8mVVkQEbBUj2WqervdHXfF2UjLD0Tm6Sa0DFxCQ@mail.gmail.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>, Martin Bjorklund <mbj@tail-f.com>, Kent Watsen <kwatsen@juniper.net>
Content-Type: multipart/alternative; boundary="001a11401a04e800b5055d905a26"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/8uw5QvaTq50sKrLo21-dtzUuXy8>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07
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: Thu, 09 Nov 2017 17:44:38 -0000
On Thu, Nov 9, 2017 at 9:12 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > On Thu, 2017-11-09 at 08:34 -0800, Andy Bierman wrote: > > > > > > On Thu, Nov 9, 2017 at 7:37 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > > > Robert Wilton <rwilton@cisco.com> writes: > > > > > > >> > > > >>> 2. Sec 1. Introduction, page 4, paragraph starting "2. > > > >>> Implementation-time ...". This section states that it is a stable > as > > > >>> YANG library, and hence cannot change due to a server reboot. > However, > > > >>> YANG library doesn't appear to have that restriction, and hence > this > > > >>> doesn't seem to align with RFC 7895, introduction paragraph 2. > > > >> I don't know exactly under what circumstances YANG library can > change > > > >> after a reboot, but in such a case schema-mounts data might be > subject > > > >> to a change as well. I definitely think that the "run-time" case is > > > >> something else. > > > > A software upgrade could quite reasonably change YANG library > without a > > > > device reboot. Perhaps saying less is more precise: > > > > > > > > E.g. > > > > > > > > 2. Implementation-time: the mounted schema is defined by a > server > > > > implementor and is as stable as YANG library information. > Also, > > > > a client can learn the entire schema together with YANG > library data. > > > > > > > > > > It seems that neither 7950 nor 7895 defines how stable YANG library > data > > > is. The conclusion might be that it can change any time, which is IMO > > > hardly acceptable. > > > > > > Actually, the YANG library is allowed to change at any time. > > Clients use the module-set-id and the yang-library-change notification > > to keep their cached copy of the server's library up to date. > > Notifications are optional, so basically the client needs to check > module-set-id > before every operation, and even this may not be sufficient for avoiding > errors. > > The YANG data model was touted as a contract between the server and client > - and > it is a strange contract if the server can change it arbitrarily. > > The server can change the library according to the contract. It updates the module-set-id. In reality, there are no routers that change the module set at run-time. They are all mostly-monolithic firmware that need to reboot to change the YANG modules. Modular software is more complex to test, so it is not as common in embedded systems. Lada > Andy > > > > > > > > > Andy > > > > > > > > > > > > Or alternatively, you say that it is at least as stable as the YANG > > > > library information, and then list when it could change. > > > > > > > > > > > >> > > > >>> 3. Sec 2.1 Glossary of New Terms: "Schema" isn't actually defined > > > >>> anywhere (RFC 7950 doesn't define this). Should it be defined > here? > > > >>> The NMDA datastores draft had a similar issue and we choose to > define > > > >>> "datastore schema" instead. > > > >> I think the right place for defining the term "schema" (and "data > model" > > > >> as well) is the specification of YANG because it is desirable that > all > > > >> documents related to YANG use the same meaning. > > > > OK, 7950 doesn't define it today. Is that a problem? > > > > > > "Schema tree" and "schema node" are defined and used a lot in 7950, so > > > it might be good to define "schema" as well - meaning the schema tree > > > with all associated semantics. > > > > > > > > > > >> > > > >>> 4. Sec 3.2. paragraph 1. Same comment as 2 above also applies > here. > > > >>> The text "same management session" might be more clear as "same > client > > > >>> management protocol session". > > > >> Hmm, I wouldn't say this is more clear - it seems to indicate that > we > > > >> are managing the client. > > > > My issue is that "same management session" isn't really that clear to > > > > what it is referring to. Perhaps drop the "client" and have "same > > > > management protocol session"? > > > > > > This probably needs to be coupled somehow with YANG library stability - > > > if YANG library can change during a session, then schema mounts should > > > be permitted to change as well. > > > > > > > > > > > > > > >> > > > >> But it could also be that such rules are inappropriate in this > document and > > > >> rather belong to a protocol spec. > > > > I think that they are OK here if this draft defines the lifetime of > the > > > > schema. If it is just the same as YANG library, then perhaps this > could > > > > be left to the YANG library spec to specify? > > > > > > > >> > > > >>> 5. Sec 3.2. paragraph 2, last sentence: "are possible and such > needs" => > > > >>> "are possible, and as such, needs" > > > >> I actually don't understand neither this sentence nor what the > point of > > > >> such exceptions could possibly be. > > > > An example would presumably be where effectively the same data is > being > > > > mounted in a separate place. E.g. the list of physical interfaces > in an > > > > LNE may represent a subset of all physical interfaces in the device, > > > > that would also be present in the host model. > > > > > > Then I would say simply "..., its data will generally have no > > > relationship to the data of the parent, unless the data model > explicitly > > > states otherwise." > > > > > > OK, "data model" is another term that isn't defined, but to me it is > the > > > collection of YANG modules that define the schema. I think it's not > > > possible to say where the exception has to be stated, it can be > > > either in the parent or in the mounted module, or even elsewhere. > > > > > > >> > > > >>> 6. Sec 3.2 paragraph 5. Would it useful to state that even though > the > > > >>> schema is the same, the data is different and not necessarily > related. > > > >> I think this goes without saying, as it is also the case for a > single mount > > > >> point that is a list node - data in each entry is different. > > > > In Sec 3.2 paragraph 2, it clarifies that the mounted data is > generally > > > > separate from the parent data. For paragraph 5, I still that it is > > > > useful to state the equivalent that if a schema is mounted twice it > > > > doesn't mean the same data is mounted in both places. > > > > > > This should be absolutely clear to anybody who understands that we are > > > only constructing a schema because, e.g., multiple uses of the same > > > grouping in YANG also don't mean the same instance data. Unfortunately, > > > with schema mount this confusion arises again and again, maybe the term > > > "mount" is really misleading. > > > > > > ... > > > > > > >> > > > >>> 9. Structure of ietf-yang-schema-mount module: > > > >>> - Should "uri" under namespace be marked as "mandatory" so > that it > > > >>> doesn't appear to be optional in the tree diagram. > > > >> Yes, this is an omission. > > > >> > > > >>> - Should the "module" name be included under the namespace. > It seems > > > >>> that lots of other "module bindings" are done via the module name > rather > > > >>> than the namespace? > > > >> We need it exclusively for XPath, so it seems natural to stay close > to XML > > > >> namespaces. > > > > I was suggesting that it might be useful to add "module" in addition > to > > > > namespace. > > > > > > This is possible but redundant, I was thinking about replacing the URIs > > > with module names. It probably doesn't really matter unless the URIs > are > > > written by hand. > > > > > > Lada > > > > > > > > > > >> > > > >>> 10. Example A.3. This contains some features that are enabled. > Possibly > > > >>> it would be useful in the description to point this out, and state > that > > > >>> unless the features are listed they wouldn't be enabled. > > > >> Yes, we reuse the groupings from ietf-yang-library, and the idea is > to > > > >> apply the same semantics. And as you are saying below, it would be > more > > > >> straightforward to integrate it directly with YANG library. > > > >> > > > >>> My last general comment relates generally to the structure of the > > > >>> Iietf-yang-schema-mount. As Lada has pointed out previously, this > > > >>> module and YANG library bis could be more closely aligned (e.g. > along > > > >>> the lines of reusing module-sets for the "schema" list). It would > have > > > >>> been nice if this module could augment YANG library (so that you > can > > > >>> easily get the modules and schema mount information in a single > simple > > > >>> request), however that would put an undesired dependency delaying > > > >>> publishing this draft until YANG library bis is completed. > > > >> Of course I agree, but I think the priority should be to make > things as > > > >> simple and easy to understand as possible. They are complex enough > > > >> anyway. > > > > Thanks, > > > > Rob > > > > > > > > > > > >> > > > >> Thanks, Lada > > > >> > > > >>> Thanks, > > > >>> Rob > > > >>> > > > >>> > > > >>> On 20/10/2017 22:37, Kent Watsen wrote: > > > >>>> All, > > > >>>> > > > >>>> This starts a two-week working group last call on > > > >>>> draft-ietf-netmod-schema-mount-07. > > > >>>> > > > >>>> The working group last call ends on November 3. > > > >>>> Please send your comments to the netmod mailing list. > > > >>>> > > > >>>> Positive comments, e.g., "I've reviewed this document > > > >>>> and believe it is ready for publication", are welcome! > > > >>>> This is useful and important, even from authors. > > > >>>> > > > >>>> Could the authors, explicitly CC-ed on this email, > > > >>>> please also confirm one more time that they are > > > >>>> unaware of any IPR related to this draft. > > > >>>> > > > >>>> Thank you, > > > >>>> Netmod Chairs > > > >>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> 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 > > > > > > _______________________________________________ > > > 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 >
- [netmod] WG Last Call: draft-ietf-netmod-schema-m… Kent Watsen
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Jeff Tantsura
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Xufeng Liu
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Acee Lindem (acee)
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Juergen Schoenwaelder
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Dean Bogdanovic
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Andy Bierman
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Xufeng Liu
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Ladislav Lhotka
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Christian Hopps
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Ladislav Lhotka
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Ladislav Lhotka
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Ladislav Lhotka
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Andy Bierman
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Ladislav Lhotka
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Andy Bierman
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Juergen Schoenwaelder
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Ladislav Lhotka
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Juergen Schoenwaelder
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Lou Berger
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Ladislav Lhotka
- Re: [netmod] WG Last Call: draft-ietf-netmod-sche… Ladislav Lhotka