On Tue, Dec 19, 2017 at 12:31 PM, Martin Bjorklund <m...@tail-f.com> wrote:
> Hi Lou, > > Lou Berger <lber...@labn.net> wrote: > > Hi, > > These comments are based on my Shepherd review of this document and > > should be addressed as part of addressing any LC comments: > > > > 1) Considering the recent discussion on Library made me consider the > > general case of a module that is composed entirely of operational state. > > I think this case is subject to interpretation and therefore needs to > > be explicitly covered. For example section 5.3 states: > > > > The datastore schema for <operational> MUST be a superset of the > > combined datastore schema used in all configuration datastores except > > that YANG nodes supported in a configuration datastore MAY be omitted > > from <operational> if a server is not able to accurately report them. > > > > This could be read that a module that an operational state MUST be > > present (but presumably empty>?) in some other DS to be present in > > operational. I don't believe this is your intent, but it should be > > explicitly covered for the benefit of future readers. > > Ok. How about we add to the paragraph above a sentence: > > If a module does not contain any configuration data then it MAY be > omitted from the schema for the configuration datastores. > > I liked the old YANG library better. It allows a client to create of a list of all the modules/revisions/features/deviations that will be needed to match the schema tree used by the server. The compiler does not care if it is looking for a typedef vs. a data node. The YANG library details help the compiler find the correct definitions. Consider iana-crypt-hash that has only typedefs and features. Leaving this module out of the library can cause problems for a client. > I suspect that > > this also should translate to an explicit case in section 6.1 as well. > > I don't understand why that would be neeed. > > > 2) The abstract needs to mention that it updates RFC7950 (per idnits) > > Ok. > > > 3) A minor point, the document uses the terms boot and reboot. I > > suspect that these terms are intended to cover any full or partial, > > e.g., protocol, restart operation supported on a system - which may not > > include a full boot. I think the document needs to be clear on this > > point. Perhaps just add a definition, or note that full and partial > > restart operations are included when the document refers to boot and > reboot. > > RFC 6241 uses the same terms, so using them is at least consistent > with that document. I'm not sure I think they need to be defined in > this document. > > > /martin > > > > Andy > > > > > Thank you, > > Lou > > (As Shepherd) > > > > On 12/04/2017 09:35 AM, Lou Berger wrote: > > > All, > > > > > > This starts a second working group last call on > > > draft-ietf-netmod-revised-datastores. > > > > > > As this is a 2nd LC that is focused on changes since the last LC, it > closes in *one* week. The working group last call ends on December 11. > Please send your comments to the netmod mailing list. > > > > > > At this point, we're most interested in verifying that previous > comments are addressed since the last call on the -04 rev of the draft was > held. > > > > > > A summary of changes can be found at > > > https://mailarchive.ietf.org/arch/msg/netmod/ > DWtD12bGkBZabEygRfiwZfcnUU4 > > > > > > A diff can be found at > > > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&; > url1=draft-ietf-netmod-revised-datastores-04.txt&url2=draft-ietf-netmod- > revised-datastores-07.txt > > > > > > Comments along the of: I have reviewed this version of the document > and it addresses my previous comments would be particularly helpful. > > > > > > 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 >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
