Ladislav Lhotka <lho...@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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
