On Thu, Nov 9, 2017 at 9:12 AM, Ladislav Lhotka <lho...@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 <lho...@nic.cz> wrote: > > > Robert Wilton <rwil...@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 mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
