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

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 1 Jul 2021 10:36:05 +0200

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>.

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.).

/Vladimir

>
> Jernej
>
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Thu, 1 Jul 2021 05:25:57 -0700

> requirement for such implementation to also implement ietf-netconf-nmda

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.

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).

> 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

---

From: Jernej Tuljak <[email-masked]>
Date: Thu, 1 Jul 2021 16:32:37 +0200

On 01/07/2021 14:25, Andy Bierman wrote:
>
>
> On Thu, Jul 1, 2021 at 1:36 AM Vladimir Vassilev 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
> It is trivial for the server to support the new YANG library, and at 
> least 2 implementations

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.

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.

Jernej

> is not being adopted (but the server-centric WG still thinks the jury 
> is out on NMDA).
>
>
> The <get> and <get-config> operations work exactly the same as before 
> NMDA existed.
>
>     /Vladimir
>
>
>
>
> Andy
>
>     >
>     > Jernej
>     >
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netconf>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netconf>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 1 Jul 2021 07:58:39 -0700

On Thu, Jul 1, 2021 at 7:32 AM Jernej Tuljak <[email-masked]>
wrote:

> 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.

> 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.

Andy

> netconf mailing [email-masked]://www.ietf.org/mailman/listinfo/netconf
>
>
>

---

From: Jernej Tuljak <[email-masked]>
Date: Fri, 2 Jul 2021 11:22:48 +0200

On 01/07/2021 16:58, Andy Bierman wrote:
>
>
> On Thu, Jul 1, 2021 at 7:32 AM Jernej Tuljak <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     It is trivial for the server to support the new YANG library, and
>>     at least 2 implementations
>     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.
>
>
>
> 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 

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?

> 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

>>     is not being adopted (but the server-centric WG still thinks the
>>     jury is out on NMDA).
>>
>>
>>     The <get> and <get-config> operations work exactly the same as
>>     before NMDA existed.
>>
>>         /Vladimir
>>
>>
>>
>>
>>     Andy
>>
>>         >
>>         > Jernej
>>         >
>>     https://www.ietf.org/mailman/listinfo/netconf  <https://www.ietf.org/mailman/listinfo/netconf>
>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 3 Jul 2021 08:57:25 -0700

On Fri, Jul 2, 2021 at 2:22 AM Jernej Tuljak <[email-masked]>
wrote:

>> but implements YANG Library 1.1. I'd like to see a concrete example of the
> 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.
>

This is academic since we do not use the 2019 version unless NMDA is
enabled,
because the redundant data is not helpful to the operator.
I do not think RFC 8525 imposes NMDA requirements, so it should be possible
to comply with this RFC but not RFC 8342.

Example:
  - 1 module set
  - 1 schema containing the 1 module-set
  - 1 datastore entry for running

I guess your issue is that <operational> should not be included, so any
module
that has config=false nodes cannot be properly represented.  Or the server
can
implement <operational> for just config=false nodes, since it has no support
for operational values of config=true data nodes.

We allow YANG Push to be used without NMDA in this way,
because YANG Push is popular/useful and NMDA is not.

> instantiate <schema> and <datastore> at all, since those are not supported?
> That is exactly why I asked for an example.
>

No -- see above.

> convey to the client if the server does not support NMDA?

Not sure why this is a problem.
The server has no special datastore for operational values for
configuration data nodes.
Other than that, it is the same as NMDA.

> 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?
>

The client can <get> /modules-state or /yang-library.
We cannot take away /modules-state from our server.
Too much code out there depends on it.

> 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.
>

Andy

---

From: Jernej Tuljak <[email-masked]>
Date: Sat, 3 Jul 2021 21:12:30 +0200

On 03/07/2021 17:57, Andy Bierman wrote:
>
>
> On Fri, Jul 2, 2021 at 2:22 AM Jernej Tuljak <[email-masked] 
>>     On Thu, Jul 1, 2021 at 7:32 AM Jernej Tuljak
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>         It is trivial for the server to support the new YANG
>>>         library, and at least 2 implementations
>>         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'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.
>
>
>
> I guess your issue is that <operational> should not be included, so 
> any module
> that has config=false nodes cannot be properly represented.  Or the 
> server can

No, my issue here is, that there are too many ways one can choose to 
populate this part of YANG Library 1.1, if the server does not support 
NMDA, because nothing exists to guide implementations on how to do 
properly. Therefore the client side is forced to rely on what is 
practically guesswork to try to understand something as basic as model 
compliance announcements from the server side.

Even the (purely academic) solution you suggest, 1 datastore, 1 schema 
and 1 module-set, is a gray area from my perspective. Why did you choose 
only ds:running, for example? Why not list ds:running, ds:candidate, 
ds:startup and ds:operational? Why not only ds:operational? Why list any 
at all - they are optional as per model?

The real issue for me regarding these is that they are defined in 
ietf-datastores, published only as part of RFC8342, titled "NMDA", which 
the server does not implement. My interpretation of the available 
documents is that those names may only represent one thing - NMDA 
datastores. To try to stretch their definitions to also cover legacy 
datastores + operational state of a device leads to something that is 
ambiguous at best.

Even just advertising 
urn:ietf:params:netconf:capability:yang-library:1.1?revision=2019-01-04&content-id=123 
in <hello> seems problematic. That capability is a NETCONF extension to 
support NMDA, defined only in RFC8526, which the server does not 
implement. You used the A and B module analogy in a previous message. 
Does such an analogy not apply also to the RFCs where the modules were 
published?

We have seen implementations in the wild do random things in order try 
to support YANG Library 1.1 in a non-NMDA context. And it has caused 
interoperability problems for us. That is why I'm asking the question in 
this thread.

Jernej

>>         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,
>     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.
>
>
> No -- see above.
>
>
>>
>     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.
>
>     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?
>
>
>
>     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
>
>
>
> Andy
>
>>
>>
>>
>>
>>         Jernej
>>
>>
>>
>>     Andy
>>
>>
>>>
>>>         is not being adopted (but the server-centric WG still thinks
>>>         the jury is out on NMDA).
>>>
>>>
>>>         The <get> and <get-config> operations work exactly the same
>>>         as before NMDA existed.
>>>
>>>             /Vladimir
>>>
>>>
>>>
>>>
>>>         Andy
>>>
>>>             >
>>>             > Jernej
>>>             >

---

From: Andy Bierman <[email-masked]>
Date: Sat, 3 Jul 2021 12:33:32 -0700

Hi,

We already agreed that implementation of the NMDA version
by a non-NMDA server is not useful, so no reason to discuss it further.

The general topic on the impact of complexity on deployment of
standards is probably out of scope here. Let's just say that
the pre-defined partitioning of functionality (e.g. YANG features)
is just a suggestion to vendors.

Andy

On Sat, Jul 3, 2021 at 12:12 PM Jernej Tuljak <[email-masked]>
wrote:

>> 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.
>>
>
>
> Even the (purely academic) solution you suggest, 1 datastore, 1 schema and
> 1 module-set, is a gray area from my perspective. Why did you choose only
> ds:running, for example? Why not list ds:running, ds:candidate, ds:startup
> and ds:operational? Why not only ds:operational? Why list any at all - they
> are optional as per model?
>
> the server does not implement. My interpretation of the available documents
> is that those names may only represent one thing - NMDA datastores. To try
> to stretch their definitions to also cover legacy datastores + operational
> state of a device leads to something that is ambiguous at best.
>
> Even just advertising
> support NMDA, defined only in RFC8526, which the server does not implement.
> You used the A and B module analogy in a previous message. Does such an
> analogy not apply also to the RFCs where the modules were published?
>
> We have seen implementations in the wild do random things in order try to
> support YANG Library 1.1 in a non-NMDA context. And it has caused