Re: [netmod] Yangdoctors last call review of draft-ietf-netmod-entity-07

[Radek Krejčí <[e-mail]>]

Hi Martin,
you are right, now I see it. So, to me, the document is Ready.

Andy, text in RFC6087bis (Temporary non-NMDA Modules) should be changed since it seems to limit the temporary module to contain data nodes only.

OLD
    It contains the top-level config=false data nodes that would have been defined in a legacy YANG module (before NMDA).

NEW
    It contains the top-level config=false data nodes that would have been defined in a legacy YANG module (before NMDA) as well as the notifications, RPCs and actions that would refer such nodes.


Regards,
Radek



Dne 8.1.2018 v 16:21 Martin Bjorklund napsal(a):
> Hi,
>
> Radek Krejčí <[e-mail]> wrote:
>> Reviewer: Radek Krejčí
>> Review result: Ready with Issues
>>
>> The document itself and normative parts seem fine to me, the only issue I see
>> is with the ietf-hardware-state module in non-normative appendix A. It seems to
>> me that this temporary non-NMDA module does not conform to its purpose as
>> described in RFC6087bis. According to guidelines, such a module is intended to
>> provide state (config false) data in case the server does not implement NMDA
>> (to bridge the time period until NMDA is implemented). So such a server is IMHO
>> intended to implement both modules, foo and foo-state. The foo-state contains
>> "the top-level config-false data nodes that would have been defined in a legacy
>> YANG module" - so it's only the ro mirror of data nodes. But
>> ietf-hardware-state contains notifications, which are not the data nodes as
>> defined in RFC7950. I understand why the notifications were placed also into
>> the ietf-hardware-state - the module's description states that "If a server
>> that implements this module but doesn't support NMDA also supports
>> configuration of hardware components, it SHOULD also implement the module
>> 'ietf-hardware' ...", so it allows its standalone usage in case the server does
>> not support hw configuration. But in such a case, the server can implement
>> ietf-hardware with deviations on the config=true nodes.
> The problem with useing the notifcations defined in ietf-hardware in
> this case is that all leafrefs would be wrong; they'd point into a
> schema that is not implemented.
>
>> The same way it had to
>> implement the legacy YANG module (before NMDA).
> Before NMDA the leafrefs in the notifcations pointed to
> /hardware-state, and all config was defined with an if-feature, so a
> server did not have to use any deviations in this case.
>
>
>
> /martin
>
>
>
>> So I think that the notifications should be removed from ietf-hardware-state
>> and the module's description should change this way:
>>
>> OLD
>>
>>   If a server that implements this module but doesn't support NMDA
>>   also supports configuration of hardware components, it SHOULD
>>   also implement the module 'ietf-hardware' in the configuration
>>   datastores. The corresponding state data is found in the
>>   '/hw-state:hardware' subtree.
>>
>> NEW
>>
>>   If a server that implements this module but doesn't support NMDA,
>>   it MUST also implement the module 'ietf-hardware' in the
>>   configuration datastores. The corresponding state data is found
>>   in the '/hw-state:hardware' subtree.
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod