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

[Andy Bierman <[e-mail]>]

On Thu, Jul 1, 2021 at 7:32 AM Jernej Tuljak <[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]> 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.


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.

Our server does not use the 2019 version unless NMDA is actually enabled.
There are already enough copies of the module info in the server without
the /yang-library copy.
I agree there is no value in providing the 2019 version in a non-NMDA
server.
A non-NMDA client will be looking for the 2016 version anyway.

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.




> 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]
>> > https://www.ietf.org/mailman/listinfo/netconf
>>
>> _______________________________________________
>> netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>
> _______________________________________________
> netconf mailing [e-mail]://www.ietf.org/mailman/listinfo/netconf
>
>
>