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

[Ladislav Lhotka <[e-mail]>]

Martin Bjorklund píše v Po 25. 09. 2017 v 11:57 +0200:
> 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

Section 5.6 in RFC 7950 describes conformance but I think it neither states nor
implies what you are saying. Specifically (in 5.6.5):

   A server implements a module if it implements the module's data
   nodes, RPCs, actions, notifications, and deviations.

But what does "implements the module's data nodes" exactly mean? My
interpretation is that if a node is optional, then it may or may not be
implemented.

> "implement" in reality translates to "never return", b/c the
> conditions that would make the device instantiate the node are never
> fulfilled.

Right, if a node is optional (with no default) then it may not exist in the data
tree (hence is never returned), and the client isn't able to tell whether it is
internally implemented or not.

Lada

> 
> 
> 
> /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
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67