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

[Robert Wilton <[e-mail]>]

On 19/12/2017 20:54, Juergen Schoenwaelder wrote:
> On Tue, Dec 19, 2017 at 12:41:28PM -0800, Andy Bierman wrote:
>> 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 think this is not the intention. If a module is needed to satisfy
> imports, it has to be listed as part of the schema. So perhaps this is
> better?
>
>      If a module does not contain any configuration data and it is not
>      needed to satisfy any imports, then it MAY be omitted from the
>      schema for the configuration datastores.
One minor tweak, I think that "configuration" would be better than 
"configuration data" for consistency reasons.

Thanks,
Rob


>
> /js
>