Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

Martin Bjorklund <mbj@tail-f.com> Mon, 25 September 2017 09:59 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 E865713334E for <netmod@ietfa.amsl.com>; Mon, 25 Sep 2017 02:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 28EKd4_FPDSD for <netmod@ietfa.amsl.com>; Mon, 25 Sep 2017 02:59:18 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9E9133344 for <netmod@ietf.org>; Mon, 25 Sep 2017 02:59:18 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 7E86A1AE02A7; Mon, 25 Sep 2017 11:59:16 +0200 (CEST)
Date: Mon, 25 Sep 2017 11:57:45 +0200 (CEST)
Message-Id: <20170925.115745.769022803919274339.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <1506006652.6428.57.camel@nic.cz>
References: <87mv5p783v.fsf@nic.cz> <9e3e2d36-f99e-aa9c-844a-d61b3ca20213@cisco.com> <1506006652.6428.57.camel@nic.cz>
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/s_gwOuHudHdDSHOWQQBJB76ENGQ>
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
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, 25 Sep 2017 09:59:20 -0000

Ladislav Lhotka <lhotka@nic.cz> wrote:
> Robert Wilton píše v Čt 21. 09. 2017 v 10:38 +0100:

[...]

> > Yes, I agree that this scenario is very likely, but I think that the 
> > solution here is just to not mark the leaf as mandatory.
> 
> But this makes the schema weaker, and implementors may think it needn't be
> implemented.

Whether the "mandatory" statement is present or not on a node has
nothing to do with what a device must implement.  "mandatory" does not
affect conformance.

As long as we don't have a more elaborate conformance mechanism, all
nodes in a module (modulo if-feature) must be implemented in order to
claim conformance to the module.  This said, there can be cases where
"implement" in reality translates to "never return", b/c the
conditions that would make the device instantiate the node are never
fulfilled.



/martin



> 
> > 
> > It is interesting to consider what "mandatory" exactly means in the 
> > <operational> datastore.  Given that the mandatory constraint may be
> 
> Yes, the semantics in the context of NM protocols is different from that of
> configuration datastores. But in the context of document (data tree) validation
> it is the same: the instance has to be present for a data tree to be valid. 
> 
> > violated in <operational>, then my interpretation is that it means that 
> > a correct implementation SHOULD always return a mandatory node (if it is 
> > in scope).  But a client has no way to force a device return this data 
> > (except perhaps shouting at the vendor :-), and so it seems that a 
> > robust client would need to be able to cope with the fact that the 
> > device is not behaving nicely and isn't returning the data regardless of 
> > any mandatory keyword specified in the schema.
> 
> I don't really share this view, it is IMO not much different from the situation
> when a vendor fails to implement a config node. Either way, the implementation
> doesn't conform to the data model.
> 
> One of the benefits of a data model is that an application can offload
> validation to an external tool, such as a generic YANG library, and then can
> rely on data being valid so that the application's code needn't be cluttered
> with all kinds of sanity checks.
> 
> I can imagine a tool collecting data from a number of devices that fails if a
> mandatory state data are absent.  
> 
> > 
> > To further expand on this, a device is required to ensure that 
> > configuration datastores are valid, and hence all mandatory constraints 
> > are enforced, or a config change would be rejected, but I don't think 
> > that many devices are going to validate operational. They will just
> > return the current state of the system back to the client, and let the 
> > client deal with any unexpected inconsistencies.
> 
> I could likewise expect the server to be prepared to deal with unexpected
> inconsistencies in config data. The data model is a contract, so it should be
> binding for both parties.
> 
> > 
> > Also, what about all the regular config false nodes in the schema that 
> > are not marked as mandatory?  Is a device always required to return 
> > those leaves (if they are in scope)?  If a device is never going to 
> 
> In terms of YANG, no.
> 
> > return those leaves then it should use a deviation to remove them, but 
> > is that actually required?
> > 
> > Is seems that possibly the most useful use of mandatory in the context 
> > of operational is for something like an IP address/prefix length 
> > pairing, i.e. to indicate that the data really doesn't make any sense 
> > unless both address and prefix are provided.
> > 
> > When the next version of YANG is specified, perhaps we should consider 
> > allowing an extra options to mandatory to that it only applies to the 
> > state datastores?  if so, we could add this to the YANG.Next issue tracker?
> 
> I believe the fundamental problem is that YANG was designed basically as a
> document-oriented schema language, and NMDA tries to make the same schema work
> for multiple different data trees. I am concerned this means a lot of complexity
>  and CLRs that will render the next version unusable.
> 
> Lada
> 
> > 
> > So, in conclusion, I think that the NMDA modelling advice for mandatory 
> > on config true nodes might be to only use it when the node is mandatory 
> > in configuration datastores.
> > 
> > If the WG isn't opposed, then I would suggested adding this to the NMDA FAQ.
> > 
> > Thanks,
> > Rob
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod