[yang-doctors] 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: yang-doctors@ietf.org
Delivered-To: yang-doctors@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: Radek Krejčí <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/yang-doctors/sOUKQS0aq__FQv-ml13wqULvXEE>
Subject: [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-entity-07
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jan 2018 14:10:21 -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.
- [yang-doctors] Yangdoctors last call review of dr… Radek Krejčí
- Re: [yang-doctors] [netmod] Yangdoctors last call… Martin Bjorklund
- Re: [yang-doctors] [netmod] Yangdoctors last call… Radek Krejčí