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

Radek Krejčí <rkrejci@cesnet.cz> Thu, 04 January 2018 14:10 UTC

Return-Path: <rkrejci@cesnet.cz>
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 832B512D86B; Thu, 4 Jan 2018 06:10:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?b?UmFkZWsgS3JlasSNw60=?= <rkrejci@cesnet.cz>
To: <yang-doctors@ietf.org>
Cc: draft-ietf-netmod-entity.all@ietf.org, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.68.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151507502144.23798.1644071576333370968@ietfa.amsl.com>
Date: Thu, 04 Jan 2018 06:10:21 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/v80gW7Vr5gV5K3uIY5-JhhMoqsM>
Subject: [netmod] Yangdoctors last call review of draft-ietf-netmod-entity-07
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jan 2018 14:10:22 -0000

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.