Hi Tom,
Juergen has tweaked your proposed text into an additional objectives
section before terminology with the following text:
2. Objectives
Network management data objects can often take two different values,
the value configured by the user or an application (configuration)
and the value that the device is actually using (operational state).
These two values may be different for a number of reasons, e.g.,
system internal interactions with hardware, interaction with
protocols or other devices, or simply the time it takes to propagate
a configuration change to the software and hardware components of a
system. Furthermore, configuration and operational state data
objects may have different lifetimes.
The original model of datastores required these data objects to be
modeled twice in the YANG schema, as "config true" objects and as
"config false" objects. The convention adopted by the interfaces
data model ([RFC7223]) and the IP data model ([RFC7277]) was using
two separate branches rooted at the root of the data tree, one branch
for configuration data objects and one branch for operational state
data objects.
The duplication of definitions and the ad-hoc separation of
operational state data from configuration data leads to a number of
problems. Having configuration and operational state data in
separate branches in the data model is operationally complicated and
impacts the readability of module definitions. Furthermore, the
relationship between the branches is not machine readable and filter
expressions operating on configuration and on related operational
state are different.
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. This provides a more elegant and simpler solution to the
problem.
The revised architectural model of datastores supports additional
datastores for systems that support more advanced processing chains
converting configuration to operational state. For example, some
systems support configuration that is not currently used (so called
inactive configuration) or they support configuration templates that
are used to expand configuration data via a common template.
This also removes the following, now repetitive, paragraph from the
Background Section:
Furthermore, separating operational state from configuration
in a separate branch in the data model has been found operationally
complicated, and typically impacts the readability of module
definitions due to overuse of groupings. The relationship between the
branches is not machine readable and filter expressions operating on
configuration and on related operational state are
OK?
We should provide an updated draft with all the last call review markups
applied soon, which may make it easier to review this text in context.
Thanks,
Rob
On 14/09/2017 17:37, t.petch wrote:
Lou
I am proposing that the text I included would go more or less as is into
the beginning of section 3. I think that it makes sense even before we
get into the historic definitions of configuration etc. I want to spell
out the problem - two different values of the one conceptual object,
originally handled with two schema nodes in one store of data, now
handled with one schema node in two datastores. Thus start section 3
with
NEW
Some data objects can take two different values, the one configured by
the user (configuration), the other the one that the device is using
(operational state),
perhaps as a result of interactions with hardware, with protocols, with
other devices and so on.
The original model of datastores
required these data objects to be modelled twice, as configuration false
and as configuration true, and, since there could be many of them, and
the rules of YANG require them to be in separate trees, this led to a
twin-trees approach, such as can be seen in RFC7277 or RFC7223.
This duplication of definitions and separation of operationsl state from
configuration leads to a number of problems. Having them in
separate branches in the data model is operationally
complicated and impacts the readability of module
definitions. The relationship between
the branches is not machine readable and filter expressions operating
on configuration and on related operational state are different.
With revised datastores, the data object appears once in the model
but can appear in two datastores, one for the
configured value, one for the operational state value.
Instead of two YANG data nodes there is one data node in two
datastores, a more elegant and simpler solution to the problem.
/NEW
I would make minor changes to the last three paragraphs of Section 3
mostly excising where I have already included that material
Tom Petch
The problem that is hinted at but never explicitly stated is that
data
objects can appear both as configuration and as state, e.g. when
learned
by other means or at other times. The original model of datastores
required these data objects to be modelled twice, as configuration
false
and as configuration true, and since there could be many of them,
and
the rules of YANG require them to be in separate trees, this led to
a
twin-trees approach such as can be seen in RFC7277 or RFC7223.
Amongst other problems, this separation of operational state from
configuration in a
separate branch in the data model has been found to be
operationally
complicated and impacts the readability of module
definitions. The relationship between
the branches is not machine readable and filter expressions
operating
on configuration and on related operational state are different.
With revised datastores, there is a single data object to model both
values but this now appears in two datastores, one for the
configuration value, one for the operational state value.
Instead of two YANG data nodes there is one data node in two
datastores,
a more elegant and simpler solution to the problem.
ta
objects can appear both as configuration and as state, e.g. when
learned
by other means or at other times. The original model of datastores
required these data objects to be modelled twice, as configuration
false
and as configuration true, and since there could be many of them,
and
the rules of YANG require them to be in separate trees, this led to
a
twin-trees approach such as can be seen in RFC7277 or RFC7223.
Amongst other problems, this separation of operational state from
configuration in a
separate branch in the data model has been found to be
operationally
complicated and impacts the readability of module
definitions. The relationship between
the branches is not machine readable and filter expressions
operating
on configuration and on related operational state are different.
With revised datastores, there is a single data object to model both
values but this now appears in two datastores, one for the
configuration value, one for the operational state value.
Instead of two YANG data nodes there is one data node in two
datastores,
a more elegant and simpler solution to the problem.
Tom Petch
----- Original Message -----
From: "Lou Berger" <lber...@labn.net>
To: "t.petch" <ie...@btconnect.com>; "netmod WG" <netmod@ietf.org>
Cc: <netmod-cha...@ietf.org>;
<draft-ietf-netmod-revised-datasto...@ietf.org>
Sent: Wednesday, September 13, 2017 5:56 PM
Subject: Re: [netmod] WG Last Call:
draft-ietf-netmod-revised-datastores-04 duplicaiton
I believe that text such as this would make the I-D much easier to
follow. As it stands, you have to read between the lines and
speculate.
Tom,
Thank you for the comments. Do you have a specific change in mind,
or could your propose text, that would address this?
Thanks,
Lou
On 9/13/2017 12:42 PM, t.petch wrote:
I think that in one respect, perhaps the key respect, this I-D fails
to
state the obvious (or at least what is likely obvious to those who
have
been at this for a while:-).
The problem that is hinted at but never explicitly stated is that
data
objects can appear both as configuration and as state, e.g. when
learned
by other means or at other times. The original model of datastores
required these data objects to be modelled twice, as configuration
false
and as configuration true, and since there could be many of them,
and
the rules of YANG require them to be in separate trees, this led to
a
twin-trees approach such as can be seen in RFC7277 or RFC7223.
Amongst other problems, this separation of operational state from
configuration in a
separate branch in the data model has been found to be
operationally
complicated and impacts the readability of module
definitions. The relationship between
the branches is not machine readable and filter expressions
operating
on configuration and on related operational state are different.
With revised datastores, there is a single data object to model both
values but this now appears in two datastores, one for the
configuration value, one for the operational state value.
Instead of two YANG data nodes there is one data node in two
datastores,
a more elegant and simpler solution to the problem.
I believe that text such as this would make the I-D much easier to
follow. As it stands, you have to read between the lines and
speculate.
Tom Petch
----- Original Message -----
From: "Lou Berger" <lber...@labn.net>
To: "netmod WG" <netmod@ietf.org>
Cc: <netmod-cha...@ietf.org>;
<draft-ietf-netmod-revised-datasto...@ietf.org>
Sent: Friday, September 01, 2017 10:02 PM
All,
This starts a two week working group last call on
draft-ietf-netmod-revised-datastores-04.
The working group last call ends on September 17.
Please send your comments to the netmod mailing list.
Positive comments, e.g., "I've reviewed this document and
believe it is ready for publication", are welcome!
This is useful and important, even from authors.
Thank you,
Netmod Chairs
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
