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

[Andy Bierman <[e-mail]>]

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 <[e-mail]>
wrote:

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