Martin Bjorklund <[email protected]> writes:
> Hi Andy,
>
> Andy Bierman <[email protected]> wrote:
>> Hi,
>>
>> I have reviewed draft-07 and my previous comments about NMDA have been
>> addressed.
>>
>> This might be the most important sentence in the draft:
>>
>> sec. 5.3
>>
>> 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.
>>
>> The MUST implies that there is no need to design a YANG library that can
>> support
>> an implementation that violates this MUST (i.e., 1 schema tree for the
>> super-set)
>>
>> The MAY is troublesome because it completely contradicts the conformance
>> expressed
>> in each YANG module supported by the server. Any data node without any
>> if-feature-stmts is mandatory to implement.
>
> This is required for transition purposes; a server that wants to
> implement <operational> should not have to implement all modules at
> once (as applied config).
>
>> What about config=false subtrees within a config=true subtree?
>> Can they be omitted from <operational> as well, or does the draft just
>> intend to
>> omit the operational value of config=true nodes? Should be specific.
>
> The text says "nodes supported in a configuration datastore MAY be
> omitted from <operational>". So it is implicit that it only applies
> to config true nodes (since config false cannot be supported in a
> config ds). How about:
>
> OLD:
>
> 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.
>
> NEW:
>
> The datastore schema for <operational> MUST be a superset of the
> combined datastore schema used in all configuration datastores
> except that YANG "config true" nodes supported in a configuration
If this is about schema or data nodes, I suggest to state it
explicitly:
... "config true" schema/data nodes ...
> datastore MAY be omitted from <operational> if a server is not
> able to accurately report them.
>
>
>> Perhaps this draft does not need the MAY half of the sentence at all.
>> The YANG library can specify that it is for conformance-reporting, not
>> conformance-defining.
>
> I think we should keep the MAY, since the YANG library has to be
> designed to support this case.
Shouldn't the server add corresponding deviations to the schema for
<operational> in this case?
Lada
>
>
> /martin
>
>
>
>
>>
>>
>>
>>
>> Andy
>>
>>
>> On Mon, Dec 4, 2017 at 6:35 AM, Lou Berger <[email protected]> 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
>> > [email protected]
>> > https://www.ietf.org/mailman/listinfo/netmod
>> >
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
