Re: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-07

[Andy Bierman <[e-mail]>]

On Tue, Dec 19, 2017 at 12:31 PM, Martin Bjorklund <[e-mail]> wrote:

> Hi Lou,
>
> Lou Berger <[e-mail]> 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> >
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>