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
>