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

[Martin Bjorklund <[e-mail]>]

Ladislav Lhotka <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod