Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

Andy Bierman <andy@yumaworks.com> Thu, 08 February 2018 17:12 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 9A420126E64 for <netmod@ietfa.amsl.com>; Thu, 8 Feb 2018 09:12:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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_LOW=-0.7, SPF_PASS=-0.001, 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 euBbzcFas8Kl for <netmod@ietfa.amsl.com>; Thu, 8 Feb 2018 09:12:02 -0800 (PST)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 92D0412D7FC for <netmod@ietf.org>; Thu, 8 Feb 2018 09:12:01 -0800 (PST)
Received: by mail-lf0-x22f.google.com with SMTP id g72so7441729lfg.5 for <netmod@ietf.org>; Thu, 08 Feb 2018 09:12:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3IE5hBhBDLTEQNcMTByWxMtFj470Q1PWKEyN5uf4jfA=; b=m9NZ1jZpN680Fr2iSEVSce5nR1nd826tWSOu1gytqu8K3cjvSLMzZQmrfTGOPQkiKb yiF6U2RuotKrtFBZhoi5OD7QZIDK1WDqR4miVjTwRjidaRQ5MzDHMCWoplSmqnlnt3Xa uCiPcd0HHlxOr6Ir2FArCwRoN1fsFVBpKc1aPFNvZp3D1OqzkfvHa2j2iFSWW3G1Z3MF rRhHxERHD0aUNrgR0/F0I12UtTpfSh9BBA7FDApfqENV6mZ1oMgk861Bbc9b7wcMd9lA AfhsT6SO7CA454c2KGqZHY6hhdRUG3kxNsRPyjyDEVWXTad6ueMUp9G8Ac1iU3tIZosN AyFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3IE5hBhBDLTEQNcMTByWxMtFj470Q1PWKEyN5uf4jfA=; b=eMA0z/TA8o2XPW0QTWyNdrTtcDCvTjdh+HgVaBjXejfg08yEzNu39G4BuAVBVWbfbF gp1FYDV70wj+DXbCqXDFV2/0LY72Q9c5sMfnHnTny7CLlDfnx6lL0JOFEaiP/0kM2qbz CBJNaKW1k0UyyjDdHKi1xc7aSZ+y9WKt3ZxWZXLHRnj0OWsS0+4Vyfuy+e93XiBipHLi moag1yNMVUTyMjxlOdPc/Rkv0bxkrNSE+4PaUB5Htw0WPGVfJ7rqx/vyQaeBmA1cNKzT oAMPCC9lA8PLVfeOrHmqsr9urKO8yQEzfhPjTyqi53cukVFrdjKSg6pZp+tQSD50ULy4 TVeA==
X-Gm-Message-State: APf1xPCpkIWqJFlR7KCyZxAlorWYlAuG7CgsckgC1z5pFq51De7YcJ5x vS+ozQYIQK76sExWO8Vv+FG6yrSne/wceFRR/xRcUg==
X-Google-Smtp-Source: AH8x225WRDWPohHpIfDdl4mmWtf4zYmmdF4+pA/ebgJBq8/krYAj2mdanvnMjStMwl3gSckro5/rPlEaj/cUL9hVI8Q=
X-Received: by 10.46.23.84 with SMTP id l81mr937790lje.146.1518109919748; Thu, 08 Feb 2018 09:11:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.225.18 with HTTP; Thu, 8 Feb 2018 09:11:58 -0800 (PST)
In-Reply-To: <20180208073617.yico4gvfrl6xdusw@elstar.local>
References: <CABCOCHSUWGKOH2JJA3TrRRJrvgwmmFRPs8cmOtPg0YKcY9=tsg@mail.gmail.com> <a0b9c4ba-a54d-f26e-3c09-1c2a92df58dd@cisco.com> <CABCOCHR34ovCHumyTKXOYzJcU3WM1kt-EnpxxtGLS2kLUPtECA@mail.gmail.com> <20180207.192803.834988416883038576.mbj@tail-f.com> <CABCOCHR95zL=AZ-LLq_1FsCff9dgUKP5_33uY7W7OMd8tdfb3w@mail.gmail.com> <20180208073617.yico4gvfrl6xdusw@elstar.local>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 8 Feb 2018 09:11:58 -0800
Message-ID: <CABCOCHT6RNQqOn+gkk9CepwFTu5DSTAF768++-g3YmrXfKRxCg@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>, Netconf <netconf@ietf.org>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1a635e7f38da0564b68240"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/YDH1qf2yUl88m6-7m-YZZrp_7yc>
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 08 Feb 2018 17:12:04 -0000

On Wed, Feb 7, 2018 at 11:36 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, Feb 07, 2018 at 03:03:49PM -0800, Andy Bierman wrote:
> > >
> > > > 2) The <get-data> operation returns all values in use.
> > > >     The only way to suppress defaults is to use <origin-filter>
> > > >     (e.g., request all origins except 'default')
> > >
> > > Or use with-defaults = trim.
> >
> > Yes -- because the definition in RFC 6243 is worded to exclude nodes.
> >
> > It should be clear in some draft how basic-mode applies to origin=default
> > within <operational>.
>
> Frankly, carrying the different basic modes over to <operational>
> sounds like a mistake. Complexity for no real value.
>
>

API consistency is never a mistake.
Special case treatment of 1 datastore sounds like a mistake.


> > Applying sec 2 of 6243...
> >
> > config=true:
> >
> > If basic-mode=report-all then origin=default will never be present
> >
> > If basic-mode=trim then origin=default is only possible if the
> value-in-use
> > is the YANG default
> >
> > If basic-mode=explicit then origin=default is only possible if the
> > configured value was not
> > explicitly set by a client.  Sec 2.3.1 is not clear if the YANG default
> > value is relevant or not.
> > It could be that if the configured value not explicitly set, then any
> > value-in-use (not just the
> > YANG default) could be tagged origin=default.
> >
> >
> > config=false:
> >
> > report-all: default ignored, no nodes treated as default
> > trim: node removed if value=YANG default
> > explicit: all config=false nodes are set by the server, so no nodes
> treated
> > as default
>
> Who needs all this to manage a network?



>
>
> This draft makes with-defaults mandatory-to-implement.
> > It is a SHOULD implement now.  (I approve!).
> >
> > The with-defaults capability MUST be advertised by the NMDA server,
> > including
> > the basic-mode parameter. The also-supported parameter MAY be included.
> >
> > Is it possible for report-all-tagged to apply to nodes that are learned
> > (i.e., not origin=default)?
>
> So here is an alternate proposal: The NMDA documents are silent about
> with-defaults and if someone wants to use with-defaults with
> datastores then an update of RFC 6243 needs to be written. This way,
> implementations can choose to not do any of the with-defaults magic.
>
> What we may consider, though, is to have a way to negate origin-filter
> so that we can exclude specific origins - right now to emulate this
> one has to (a) know all possible origins and then (b) list all origins
> except the one not wanted.
>
>
Then remove the text that says an error is sent if with-defaults attempted
on <operational>.
None of this new text needs to go into NMDA. It can be a vendor-specific
mystery what gets set as origin=default.  Implementors can read RFC 6243
and figure it out on their own.

Sometimes default leafs might take up 50% or more of the retrieval response.
Insisting that all clients always want this extra data seems overly
simplistic.
Assuming all networks are fast enough to ignore a 2X increase in data size
for no benefit
is not a good idea either.





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