Re: [netmod] Clarifications re RFC 8342 NMDA

Andy Bierman <andy@yumaworks.com> Fri, 03 January 2020 16:06 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68985120863 for <netmod@ietfa.amsl.com>; Fri, 3 Jan 2020 08:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 qx64H72PlO4I for <netmod@ietfa.amsl.com>; Fri, 3 Jan 2020 08:06:08 -0800 (PST)
Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (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 5E3A4120846 for <netmod@ietf.org>; Fri, 3 Jan 2020 08:06:08 -0800 (PST)
Received: by mail-lf1-x142.google.com with SMTP id l18so23988770lfc.1 for <netmod@ietf.org>; Fri, 03 Jan 2020 08:06:08 -0800 (PST)
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=C+f+3ykhd4gt1adAJPd4tViQ4+ux1prt4XHJ31r+f9U=; b=LofeaXaJkaqEWRUCb77WZXwikrGOZhjpq7wOWWFkWFmSERMzjukEdT4Yss7/dlcDRh qbESnjE9HzN2VjNoUIis1lN0OUuDJZrjxV1CP+a9sKTOEohjQ5yRG4atadG0rFOZFlfR V7q+Rjm+mHtrITmDyfHJG3UmdD853SBxMhKtI023J3M3HqwCuTW3NE/m+smoTLFpof4I v3SYv5Xguu/GvxJzLyyBG+4DujeR+kYdV7w2xm1s1uW8zpg2AM5XRRc6ljIsuAN2fyZ1 rwJkGTD9PGS0E8FZofLUoiRFOzMzdwhyzkmA8Gnz0D+tqcH3GbIxLnYfM38r7TNDXHsR D6vw==
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=C+f+3ykhd4gt1adAJPd4tViQ4+ux1prt4XHJ31r+f9U=; b=J4qNkV8xXjW7AGuqRuSlMy53cBHtJ9Hq3hBwevzW6kpBQxlD9OGtyOB3WtPvJnR2dM yB+ZLv+GJrNV8dzymdZ4SOizvJHldnI8KKS8DADdKuow6wOiIhn2rN4qVDT9qnl5D3P2 kQ+tSumcwM0zjnzz8mfr/ywrfnwyS55o738EZ6n6CboWlisn9tfEj32/9G4q8GaO09fN pgZLka3jUF065XT23fikTnkFIauUnEM2a0mg2aVPoUtojVgi4NS3rWqO0fAh4fEmTz4s lSx0i7b3L07XJP4T14u7akEfsRw+x9XG/i17bK8Y4y+njDVQznxMHIx43Y8VmbbkbvbR F3dw==
X-Gm-Message-State: APjAAAXudnk7TsIUrQwag4q7ZKs8dBiSNqNz3R/J8HFEGT1UcVAGzKCJ f0a3F05enGCm4kHNlxpPH900WN0aE7UXmvuC3Eo9HA==
X-Google-Smtp-Source: APXvYqy5kQIbSyrGUHp0TrPL9z1IBAusLEmbgrBuEW7pCYaK/fF/eLhUrjYzxocVp5YtpKVqxFoWPpmhcp196MzfPtQ=
X-Received: by 2002:a19:4b87:: with SMTP id y129mr53408964lfa.32.1578067566622; Fri, 03 Jan 2020 08:06:06 -0800 (PST)
MIME-Version: 1.0
References: <em2975b9f7-f2aa-4f8a-9052-e0f141dc029e@vanguard> <20200102183705.gyymbaylpmx7lkxk@anna.jacobs.jacobs-university.de> <eme5cd3fe4-f085-44ef-8fd9-233423d9c0a5@vanguard> <20200103154330.4iswclcwvfg4bqm5@anna.jacobs.jacobs-university.de>
In-Reply-To: <20200103154330.4iswclcwvfg4bqm5@anna.jacobs.jacobs-university.de>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 3 Jan 2020 08:05:55 -0800
Message-ID: <CABCOCHSx0ChMBwCMqK7XRsg0qkqpQL4H1K5OU6mjB4YfTDEi+g@mail.gmail.com>
To: =?UTF-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= <J.Schoenwaelder@jacobs-university.de>
Cc: Jonathan <jonathan@hansfords.net>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bd8ecb059b3e7cb2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/9uqz9yLRR3k4FLvjsGxvQMW1So0>
Subject: Re: [netmod] Clarifications re RFC 8342 NMDA
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jan 2020 16:06:15 -0000

On Fri, Jan 3, 2020 at 7:43 AM Schönwälder, Jürgen <
J.Schoenwaelder@jacobs-university.de> wrote:

> On Fri, Jan 03, 2020 at 11:39:31AM +0000, Jonathan wrote:
> > > Since <operational> is the only way to expose config false nodes for
> > > an NMDA server, it is kind of mandatory as soon as you have config
> > > false nodes to expose.
>
> > RFC 6241 describes <get> as retrieving "running configuration and device
> > state information" and <get-config> as retrieving "all or part of a
> > specified configuration datastore". RFC 8526 introduces <get-data> which
> it
> > describes as "similar to NETCONF's <get-config> operation". As far as I
> can
> > tell, neither RFC 8342 not RFC 8526 actually identify which operation to
> use
> > to retrieve operational state data. Am I right in assuming it would be
> > <get-config>? In that case, it is similar to <get> when performed on
> > <operational> as it will also return state data.
>
> There is quite some discussion of 'operational state datastore' in
> subsections of section 3.1.1 'The <get-data> Operation' in RFC 8526.
> There is also an example in section 3.1.1.4.
>
> The <get-config> operation returns config data, hence it won't return
> config false data, i.e., its not a good choice for <operational>. The
> reason why we have NMDA is that <get> semantics have been found to be
> problematic. Hence, NMDA systems should use RFC 8526 operations
> (<get-data> and <edit-data>) when talking to each other.
>
> > And what should be the result of performing <get> on an NMDA-supporting
> > server? Should it still return config true nodes from <running> plus
> config
> > false nodes from <operational>? Or should the operation be rejected?
>
> A proper NMDA client should never send a <get>. Supporting <get> only
> makes sense for legacy clients and they might expect RFC 6241
> behaviour as far as that is implementable (the reason we have NMDA is
> that <get> semantics assume that <running> is identical to <applied>
> config, which is just not always true).
>
>

This issue has been discussed quite a bit.
RFC 8526 does not change RFC 6241 in any way. Period.
The implementation of <get>, <get-config>, and <edit-config> are
not changed at all if NMDA is also supported by the server.


/js
>
>
Andy


> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>