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 >> >> >> >
- [netconf] Should a NETCONF server implement YANG … Jernej Tuljak
- Re: [netconf] Should a NETCONF server implement Y… Vladimir Vassilev
- Re: [netconf] Should a NETCONF server implement Y… Andy Bierman
- Re: [netconf] Should a NETCONF server implement Y… Jernej Tuljak
- Re: [netconf] Should a NETCONF server implement Y… Andy Bierman
- Re: [netconf] Should a NETCONF server implement Y… Jernej Tuljak
- Re: [netconf] Should a NETCONF server implement Y… Andy Bierman
- Re: [netconf] Should a NETCONF server implement Y… Jernej Tuljak
- Re: [netconf] Should a NETCONF server implement Y… Andy Bierman
- Re: [netconf] Should a NETCONF server implement Y… Robert Varga