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

[Robert Varga <[e-mail]>]

On 03/07/2021 21:12, Jernej Tuljak wrote:
> 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:
>>
>> 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.

(sorry for the late response, this got stuck in drafts for way too long)

With my implementer (but not NMDA just yet) hat on:

I agree, RFC8525/6 model is perhaps a bit too flexible. I agree there is
room for some best practices, which we can probably recommend as what to
do in these situations. This may even help simplify clients, as
sometimes you can make assumptions on what servers you are talking to.

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

I think the correct answer is: one module set, one datastore schema and
one entry for each datastore you support.

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

Not quite. running/candidate/startup datastores were defined by RFC4741.
RFC8342 clarifies their lifecycle and relationship to YANG (i.e. RFC8342
Figure 1 should have appeared in RFC6241), proposes (IMHO) a much better
lifecycle model and gives the each datastore a manifestation in YANG.

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

Right, and a server not implementing RFC8526 should not be advertizing
it. That does not mean the server cannot implement RFC8525 yang-library.

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

Understood and agreed. I think it is worth arriving at some sort of
recommendation how a non-RFC8432-compliant server should preferably
implement RFC8525. I would assume it would be a completely mechanic way
of deriving the contents of RFC8525 /yang-library from RFC7895 
/modules-state -- that would clean up exactly these sorts of 
shenanigans, I think.

Regards,
Robert