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

From: Radek Krejčí <[email-masked]>
Date: Thu, 04 Jan 2018 06:10:21 -0800

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 same way it had to
implement the legacy YANG module (before NMDA).

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.

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Jan 2018 16:21:53 +0100 (CET)

Hi,

Radek Krejčí <[email-masked]> wrote:
> 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

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

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Radek Krejčí <[email-masked]>
Date: Tue, 9 Jan 2018 16:01:54 +0100

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