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

[Jernej Tuljak <[e-mail]>]

On 03/07/2021 17:57, Andy Bierman wrote:
>
>
> On Fri, Jul 2, 2021 at 2:22 AM Jernej Tuljak <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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.
>
>
>
> 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.

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 allow YANG Push to be used without NMDA in this way,
> because YANG Push is popular/useful and NMDA is not.
>
>
>
>>
>>
>>         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.
>
>
> No -- see above.
>
>
>>
>>     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?
>
>
>
> 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.
>
>
>
>>     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?
>
>
>
> 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.
>
>
>>
>>     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
>
>
>
> Andy
>
>>
>>
>>
>>
>>         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>
>>
>