Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07

[Ladislav Lhotka <[e-mail]>]

On Thu, 2017-11-09 at 08:34 -0800, Andy Bierman wrote:
> 
> 
> On Thu, Nov 9, 2017 at 7:37 AM, Ladislav Lhotka <[e-mail]> wrote:
> > Robert Wilton <[e-mail]> 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.

Lada

> 
> 
> 
> 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
> > >>>> [e-mail]
> > >>>> https://www.ietf.org/mailman/listinfo/netmod
> > >>>> .
> > >>>>
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67