Then, what would be the difference between an optional and a mandatory data node?
In some RFC8795 implementations, the support or not support of a data node may also depend on the specific network-type so in this case the data node cannot be marked as not-supported Italo From: Andy Bierman [mailto:[email protected]] Sent: mercoledì 19 maggio 2021 19:35 To: Italo Busi <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [netmod] Question about optional data nodes in YANG On Wed, May 19, 2021 at 10:12 AM Italo Busi <[email protected]<mailto:[email protected]>> wrote: We have got a question about how to deal with YANG optional data nodes and in particular how can a client know which optional data node has been implemented by a server. We think that there is no issue with config=false data nodes. When the client retrieves a YANG tree from the operational datastore it will not get the data nodes that are not implemented by the server, as reported in section 5.3 of RFC8342: If no value is returned for a given node, then this implies that the node is not used by the device. Is our understanding correct? The server is expected to advertise a deviation for not-supported for every subtree it does not implement. https://datatracker.ietf.org/doc/html/rfc7950#section-7.20.3.2 deviation /base:system/base:daytime { deviate not-supported; } Andy The doubt we have is about the config=true data nodes. How can the client know whether the server supports the configuration of an optional config=true data node before trying to configure them and getting an error message? We understand that it is possible to know whether a YANG model or a feature of the YANG model (i.e. a group of data nodes) is supported by the server. The question is rather on specific data nodes with config=true. We have found scenarios where it could be useful to implement a sub-set of optional data nodes (profile) of an IETF standard YANG model, but it is not very clear how a client can understand which profile has been implemented by the server. Some examples of profiles of an IETF standard YANG model are provided in: https://datatracker.ietf.org/doc/html/draft-busi-teas-te-topology-profiles Thanks, Aihua and Italo _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
