Re: [netconf] Should a NETCONF server implement YANG Library 1.1 if it does not support NETCONF NMDA?

[Jernej Tuljak <[e-mail]>]

On 01/07/2021 16:58, Andy Bierman wrote:
>
>
> On Thu, Jul 1, 2021 at 7:32 AM Jernej Tuljak <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 01/07/2021 14:25, Andy Bierman wrote:
>>
>>
>>     On Thu, Jul 1, 2021 at 1:36 AM Vladimir Vassilev
>>     <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>
>>         On 30/06/2021 10.33, Jernej Tuljak wrote:
>>         > Hi,
>>         >
>>         > I have a relatively simple question, stated in the subject.
>>         >
>>         > I cannot find any concrete text that would advise against,
>>         prohibit or
>>         > encourage such a thing, but is ietf-yang-library@2019-01-04
>>         intended
>>         > to be used in such a way; to be implemented in a non-NMDA
>>         NETCONF server?
>>         >
>>         > How should a NMDA enabled NETCONF client handle a situation
>>         where
>>         > :yang-library:1.1 capability is advertised by the NETCONF
>>         server, but
>>         > ietf-netconf-nmda module is not (assuming that the client
>>         is also
>>         > capable of acting as a legacy client)?
>>
>>         IMO all NETCONF servers that implement :yang-library:1.0
>>         implement NMDA
>>         where "all datastores have exactly the same schema". Those
>>         servers can
>>         trivially implement :yang-library:1.1. I am not aware of any
>>         formal
>>         requirement for such implementation to also implement
>>         ietf-netconf-nmda
>>         - e.g. <get-data>.
>>
>>
>>     Correct.
>>     If module A does not import or even mention module B,
>>     then it safe to assume that there is no requirement to implement B
>>     if A is supported.
>>
>>     It is trivial for the server to support the new YANG library, and
>>     at least 2 implementations
>>     use the same approach even if NMDA is enabled.
>
>     I'm more interested in the case where the server does not support
>     NMDA but implements YANG Library 1.1. I'd like to see a concrete
>     example of the server's <hello> message and content of a response
>     to a client's <get> request on /ietf-yang-library:yang-library
>     data tree branch for this case.
>
>
>
> I don't understand why there would be any confusion about <get> processing
> of config=false data nodes, or why such data nodes under the 
> /yang-library subtree would be special.

I'd like to see what you consider to be a sane response to a query on 
that branch, if the server does not support NMDA. I would also like to 
see how the server properly announces its support for YANG Library 1.1, 
if it does not support NMDA.

>
>
>     We have seen different approaches used in the wild and none of
>     them make much sense to us. The intention of YANG Library 1.1
>     seems to be pretty clear - to announce NMDA datastore schema
>     compliance. I do not see how it can be used in a different context
>     so an example would be appreciated greatly.
>
>
> I do not see any text requiring more than one module-set list entry to 
> be populated,
> except for rules on how <operational> can be different from a 
> conventional datastore.

Are you saying that a non-NMDA server implementing YANG Library 1.1 is 
only expected/required to populate one <module-set> entry and not 
instantiate <schema> and <datastore> at all, since those are not 
supported? That is exactly why I asked for an example.

>
> Our server does not use the 2019 version unless NMDA is actually enabled.

To me, that is the only decision that makes sense.

> There are already enough copies of the module info in the server 
> without the /yang-library copy.

What is the latter copy supposed to contain and what meaning does it 
convey to the client if the server does not support NMDA?

> I agree there is no value in providing the 2019 version in a non-NMDA 
> server.

That is my view as well.

> A non-NMDA client will be looking for the 2016 version anyway.

You seem to be implying that the client side cannot support both (NMDA 
and legacy) and decide which to use during <hello> exchange and some 
additional queries immediately after?

>
> Even if NMDA is enabled on our server, it only supports 1 module-set,
> because our clients do not support multiple schema trees per session.

All server implementations we have encountered are like that. So far. 
But like I said before, I'm more interested in non-NMDA servers that 
implement YANG Library 1.1.

Jernej

>
>
>
>
>     Jernej
>
>
>
> Andy
>
>
>>
>>     It has never been trivial for a client to support NMDA, and that
>>     is why NMDA
>>     is not being adopted (but the server-centric WG still thinks the
>>     jury is out on NMDA).
>>
>>
>>         IMO client software using <get> and <get-config> should not
>>         need changes
>>         to support device servers upgraded to support
>>         :yang-library:1.1 with or
>>         without implementation of ietf-netconf-nmda (<get-data> etc.).
>>
>>
>>     This is not just an opinion.
>>     No words in RFC 6241 are altered because NMDA is implemented.
>>     The <get> and <get-config> operations work exactly the same as
>>     before NMDA existed.
>>
>>         /Vladimir
>>
>>
>>
>>
>>     Andy
>>
>>         >
>>         > Jernej
>>         >
>>         > _______________________________________________
>>         > netconf mailing list
>>         > [e-mail] <mailto:[e-mail]>
>>         > https://www.ietf.org/mailman/listinfo/netconf
>>         <https://www.ietf.org/mailman/listinfo/netconf>
>>
>>         _______________________________________________
>>         netconf mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/netconf
>>         <https://www.ietf.org/mailman/listinfo/netconf>
>>
>>
>>     _______________________________________________
>>     netconf mailing list
>>     [e-mail]  <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/netconf  <https://www.ietf.org/mailman/listinfo/netconf>
>