Re: [netmod] Last Call: <draft-ietf-netmod-revised-datastores-09.txt> (Network Management Datastore Architecture) to Proposed Standard two

Martin Bjorklund <mbj@tail-f.com> Tue, 09 January 2018 20:08 UTC

Return-Path: <mbj@tail-f.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 A90BC120725; Tue, 9 Jan 2018 12:08:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 VvIUGjv_brh3; Tue, 9 Jan 2018 12:08:27 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EF5C3120721; Tue, 9 Jan 2018 12:08:26 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 890401AE0144; Tue, 9 Jan 2018 21:08:24 +0100 (CET)
Date: Tue, 09 Jan 2018 21:08:24 +0100 (CET)
Message-Id: <20180109.210824.760424986407969599.mbj@tail-f.com>
To: daedulus@btconnect.com
Cc: ietf@ietf.org, netmod-chairs@ietf.org, bclaise@cisco.com, draft-ietf-netmod-revised-datastores@ietf.org, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <012c01d3896d$68c41d80$4001a8c0@gateway.2wire.net>
References: <151388421473.12936.719186167168412861.idtracker@ietfa.amsl.com> <012c01d3896d$68c41d80$4001a8c0@gateway.2wire.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hgVVvWIz1LYbAE30_bDAK-axg0o>
Subject: Re: [netmod] Last Call: <draft-ietf-netmod-revised-datastores-09.txt> (Network Management Datastore Architecture) to Proposed Standard two
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: Tue, 09 Jan 2018 20:08:38 -0000

Hi Tom,

"tom p." <daedulus@btconnect.com> wrote:
> Much of this I-D is about the idea that network management data objects
> can often take two different values.  The I-D always refers to this as
> being two values but is that a limit that this architecture imposes; or
> can it be more?

The I-D talks about two instantiations in the Objectives section, when
the original "config vs oper values" problem is explained, and how
NMDA solves the problem.

But the archtecture allows for any number of instantiations; it all
depends on which datastores a particular server implements.  For
example, a config node might have one value in <candidate>, a
different in <running> and yet a different value in <startup>.  This
is not new to this document.


> The later diagrams show  three datastores, <running>,
> <intended> and <operational>.  Since "<intended> MAY also be updated
> independently of <running> ", can there be three values?  And since the
> architecture says that other conventional configuration datastores may
> be defined in future, can there be any number more values?  I think this
> is a significant issue when set against the objectives, of exposing to
> the user
> what values there are in a server; the I-D is clear that there is one
> schema, but I
> am less certain about its insistence on two values.
> 
> In a sense, there is a datastore, perhaps more than one, missing.  The
> focus has been on configuration-related datastores and is now widening
> to put other object values into datastores.  Yet the values learnt
> from hardware, protocols and such like will only be in a datastore if
> that value is used and so is in <operational>.  If a user-configured
> value is the one put into <operational>, then values learnt by other
> means will not
> appear AFAICT.  For completeness, there should be a datastore for values
> learnt from the hardware, from protocols and so on.  (In fact, doing the
> sort of
> thing that routing protocols, which learn different routes to the same
> destination via different means, have been doing for years:-)

The architecture defined in this I-D defines a set of datastores, but
it also allows for new datastores defined in the future.  If a
datastore with "unused" values is needed, such a datastore can be
defined later.


/martin



> 
> Tom Petch
> 
> ----- Original Message -----
> From: "The IESG" <iesg-secretary@ietf.org>
> Sent: Thursday, December 21, 2017 7:23 PM
> 
> > The IESG has received a request from the Network Modeling WG (netmod)
> to
> > consider the following document: - 'Network Management Datastore
> Architecture'
> >   <draft-ietf-netmod-revised-datastores-09.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> final
> > comments on this action. Please send substantive comments to the
> > ietf@ietf.org mailing lists by 2018-01-10. Exceptionally, comments may
> be
> > sent to iesg@ietf.org instead. In either case, please retain the
> beginning of
> > the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >    Datastores are a fundamental concept binding the data models
> written
> >    in the YANG data modeling language to network management protocols
> >    such as NETCONF and RESTCONF.  This document defines an
> architectural
> >    framework for datastores based on the experience gained with the
> >    initial simpler model, addressing requirements that were not well
> >    supported in the initial model.  This document updates RFC 7950.
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/
> >
> > IESG discussion can be tracked via
> >
> https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ba
> llot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
>