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

Andy Bierman <andy@yumaworks.com> Sat, 03 July 2021 15:57 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CED3A1A28 for <netconf@ietfa.amsl.com>; Sat, 3 Jul 2021 08:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22XugseVJRvh for <netconf@ietfa.amsl.com>; Sat, 3 Jul 2021 08:57:40 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0EFD3A1A27 for <netconf@ietf.org>; Sat, 3 Jul 2021 08:57:39 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id n14so24002297lfu.8 for <netconf@ietf.org>; Sat, 03 Jul 2021 08:57:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XteH8dPhYrTR7XKipNE5ivnfagraaivgYT1QQ7/y0Ow=; b=nnPQvT+OLkpYblLu0pAMCjoauMrMjkLBR1W2XydtM7k4XKpmXOk/XvbCLptSpHkeRH 1UJU5/lPsL6wJfAZR1Txn50a58qmF0zlgxWVesmajpF7ICNlogzy1JbYeoIZPZIC8oo5 EVoN7G0aLWIdgfKhhgo1rEHwuGQgQNMnJXY9YYgFg+7c6/rKO0h0NCTKw8ZBtBTv3Mg4 N9VfBbfGYdRLB76UTSn07TkjFakVgO92jN+pOkRsef4swxiEvl03BdmU+j0ImKS7W/SG 2QKhZF3gStDQgxAQ7bBEeeig/tbuRYV3b/k1BS0CHpXfDyZTo/AFu60qizzo6ey+49gU XqgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XteH8dPhYrTR7XKipNE5ivnfagraaivgYT1QQ7/y0Ow=; b=HRVcpmgPKh7edKNkZnNpbdPwIoI08Ebsi1vdRFiAODRfRPPtJfEQcmwkhSnJJ76DnQ 1akmxhBYGHBKa+oh6DD8PTBNEMxuX6JAc/MVBFa0xdeAoP5sDdX6COAv3voF4VXQyfzB zIEsfmnlT9hG2fRU/0BUyuLJvfNznH06/Hps2Vae5TvdmOjimaMnZOlIsyw+UpmScWAt 1dAaX93fVuHDXkn/ILEUbHBBjbUfz9uBiXaDOEbbjRx+ilV8+mv8YT/eQ7fuBWBuFcdd 6aXCOSPTAUGl63ICpqGoLbxCGtYyhuGkRSSE4r3clgR+466WCR0XQC43YXL5198rNssV qpJw==
X-Gm-Message-State: AOAM533Ivy+stphmr5nkbUlD2DCDe8Sct0VA3lDaNXsvxS6LzS0Fjy1o DXtDG4nvKkpczoreZ4FkPrSsHcJzMMMOfHQBPVhilA==
X-Google-Smtp-Source: ABdhPJzc0jWdyZqzuEebE+OdgIQ+7+d5HTKcsP/qn7LKzq/GLlblrw4HUVeXmNsPM3eSeoWp8SM0OoXHrtLhhJhIhzs=
X-Received: by 2002:a19:c1d4:: with SMTP id r203mr3797042lff.512.1625327856056; Sat, 03 Jul 2021 08:57:36 -0700 (PDT)
MIME-Version: 1.0
References: <d8bd1bec-834c-3247-8269-0f9d915dd36a@mg-soft.si> <ee2ced1d-2d74-093a-d377-73907e03c7fa@lightside-instruments.com> <CABCOCHQomyGQxbg-svjZTcKPjc+BWodPaugSE8LFC_fXj-Uw6Q@mail.gmail.com> <a5c08314-3687-59bc-a44c-1044b6c06b33@mg-soft.si> <CABCOCHQ8L4M8ZwNdUgcPX=Ba0uYs6mkX_cAthkZc74vpdqnunw@mail.gmail.com> <12702921-2d78-84b2-8601-2ab225da0b52@mg-soft.si>
In-Reply-To: <12702921-2d78-84b2-8601-2ab225da0b52@mg-soft.si>
From: Andy Bierman <andy@yumaworks.com>
Date: Sat, 03 Jul 2021 08:57:25 -0700
Message-ID: <CABCOCHT1MTKiGsHN1NsLf7jvHjr0b16gJ4=Oy2PPdBkOSsT=6g@mail.gmail.com>
To: Jernej Tuljak <jernej.tuljak@mg-soft.si>
Cc: Vladimir Vassilev <vladimir@lightside-instruments.com>, Netconf <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000810ed705c63a2140"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/SXSvQGS3j22yLcbQ6nMJP6kzcFw>
Subject: Re: [netconf] Should a NETCONF server implement YANG Library 1.1 if it does not support NETCONF NMDA?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Jul 2021 15:57:45 -0000

On Fri, Jul 2, 2021 at 2:22 AM Jernej Tuljak <jernej.tuljak@mg-soft.si>
wrote:

> On 01/07/2021 16:58, Andy Bierman wrote:
>
>
>
> On Thu, Jul 1, 2021 at 7:32 AM Jernej Tuljak <jernej.tuljak@mg-soft.si>
> wrote:
>
>> On 01/07/2021 14:25, Andy Bierman wrote:
>>
>>
>>
>> On Thu, Jul 1, 2021 at 1:36 AM Vladimir Vassilev <
>> vladimir@lightside-instruments.com> 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.

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
>>> > netconf@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/netconf
>>>
>>> _______________________________________________
>>> netconf mailing list
>>> netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>>
>>
>> _______________________________________________
>> netconf mailing listnetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>>
>>
>>
>