On Wed, May 19, 2021 at 10:12 AM Italo Busi <[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]
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to