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

Martin Bjorklund <mbj@tail-f.com> Mon, 08 January 2018 15:23 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC64129C53; Mon, 8 Jan 2018 07:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBQgomRIrLpJ; Mon, 8 Jan 2018 07:23:37 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3B32912706D; Mon, 8 Jan 2018 07:23:37 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id CCE1C1AE0332; Mon, 8 Jan 2018 16:23:35 +0100 (CET)
Date: Mon, 08 Jan 2018 16:21:53 +0100 (CET)
Message-Id: <20180108.162153.18427707995478583.mbj@tail-f.com>
To: rkrejci@cesnet.cz
Cc: yang-doctors@ietf.org, draft-ietf-netmod-entity.all@ietf.org, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <151507502144.23798.1644071576333370968@ietfa.amsl.com>
References: <151507502144.23798.1644071576333370968@ietfa.amsl.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/rRbnU74HSrjcPKASOCZFct1A2ao>
Subject: Re: [netmod] Yangdoctors last call review of draft-ietf-netmod-entity-07
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Mon, 08 Jan 2018 15:23:39 -0000

Hi,

Radek Krejčí <rkrejci@cesnet.cz>; 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod