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

[Andy Bierman <[e-mail]>]

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.



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
>