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

From: "tom p." <[email-masked]>
Date: Tue, 9 Jan 2018 16:38:27 -0000

This I-D re-arranges the tectonic plates which underly the IETF's
management technology and is likely to affect all such work for some
years to come.  As such, I want it to be clear and unambiguous but do
not find it so.  I find it unclear as to the meaning of the word
'configuration'.

Netconf (and latterly YANG) were instigated to facilitate configuration,
which was narrowly defined as the values that a user might want to
change to get a box from its initial state to its desired state.  What
might have been thought as configuration historically - values learnt
from hardware or the interactions of protocols - was not configuration
but state, latterly referred to as operational state.  This narrow
definition of configuration is reflected in this I-D.

However, working through the 24 definitions that appear under
'Terminology', while the early ones use this narrow definition, by the
time
we get to

"learned configuration: Configuration that has been learned via protocol
interactions "
or

"system configuration: Configuration that is supplied by the device
itself."
the meaning has clearly changed to encompass all the different ways in
which a device can learn a value i.e 'learned configuration' and 'system
configuration' are not configuration as has been understood up until now
in this work.

I think it hard to follow this I-D when this key term seems to have a
variable meaning. I am uncertain what meaning to attribute the word when
it appears in the later text.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
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
> [email-masked] mailing lists by 2018-01-10. Exceptionally, comments may
be
> sent to [email-masked] 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.
>
>
>
>

---

From: "tom p." <[email-masked]>
Date: Tue, 9 Jan 2018 17:14:48 -0000

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 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:-)

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
Sent: Thursday, December 21, 2017 7:23 PM

to
Architecture'
final
be
beginning of
written
architectural

---

From: Robert Wilton <[email-masked]>
Date: Tue, 9 Jan 2018 17:26:00 +0000

Hi Tom,

The draft uses this definition for configuration:

    o  configuration: Data that is required to get a device from its
       initial default state into a desired operational state.  This data
       is modeled in YANG using "config true" nodes.  Configuration can
       originate from different sources.

The last sentence means that it encompasses configuration that comes 
from other sources such as protocol interactions.  I.e. by different 
sources it means that configuration may come via DHCP, or be learned 
from a peer protocol (e.g. hello timer values, Ethernet auto-negotiation 
settings).

The other sentence that is key is 'This data is modeled in YANG using 
"config true" nodes.'.  This statement applies both ways.  If you want 
to model configuration in YANG then it must be labelled "config true".  
Hence all nodes in the schema marked as "config true" are by definition, 
configuration.  Conversely, all nodes in the schema not marked as 
"config true" are by definition, not configuration.

So, I don't think that the definition for "configuration" changes 
through the definitions at all, it has the same meaning through out, 
i.e. the broader definition that encompasses data learned from other 
sources such as DHCP, peer protocols, etc, as well as conventional 
configuration received via NETCONF/RESTCONF or similar "regular" 
configuration protocols.

I think that the intent of "conventional configuration" probably matches 
your narrower definition of "configuration" that you describe below:

Thanks,
Rob

On 09/01/2018 16:38, tom p. wrote:
> .

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 09 Jan 2018 21:08:24 +0100 (CET)

Hi Tom,

"tom p." <[email-masked]> wrote:
> 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>,

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jan 2018 17:36:53 +0100

> is not new to this document.

Right. Lets see there "two" is used:

- 1st paragraph in 2. Objectives: I think the text is clear since it
  talks about a concrete example of a configured value and an
  operationally used value.

- 2nd paragraph in 2. Objectives: This text talks about two separate
  branches in the old models, this should be fine.

- 4th paragraph in 2. Objectives: I think this is potentially
  causing the confusion. It says:

    With the revised architectural model of datastores defined in this
    document, the data objects are defined only once in the YANG schema
    but independent instantiations can appear in two different
    datastores, one for configured values and one for operational state
    values.

  Perhaps a better wording would be this:

    With the revised architectural model of datastores defined in this
    document, the data objects are defined only once in the YANG
    schema but independent instantiations can appear in different
    datastores, e.g., for a configured value and one for an
    operationally used value.

  This e.g. then kind of continues the example the section started
  with. Would this change have avoided the question?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "tom p." <[email-masked]>
Date: Thu, 11 Jan 2018 12:32:29 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Wednesday, January 10, 2018 4:36 PM

>     document, the data objects are defined only once in the YANG
schema
>   with. Would this change have avoided the question?

Juergen

Yes, I would find that clearer.  Perhaps even better

OLD
     e.g., for a configured value and one for an
    operationally used value.
NEW
     e.g., one for a configured value and one (another?)  for an
     operationally used value.

I would say 'one' and 'another'  but 'one' and 'one' would be clear
enough.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Jan 2018 13:58:37 +0100

> I would say 'one' and 'another'  but 'one' and 'one' would be clear

I now have this:

  With the revised architectural model of datastores defined in this
  document, the data objects are defined only once in the YANG schema
  but independent instantiations can appear in different datastores,
  e.g., one for a configured value and another for an operationally used
  value.

OK?

/js

---

From: "tom p." <[email-masked]>
Date: Thu, 11 Jan 2018 16:16:15 -0000

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Thursday, January 11, 2018 12:58 PM

>   e.g., one for a configured value and another for an operationally
used

OK

Tom Petch