Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 duplicaiton

From: Robert Wilton <[email-masked]>
Date: Wed, 18 Oct 2017 17:38:23 +0100

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" <[email-masked]>
> To: "t.petch" <[email-masked]>; "netmod WG" <[email-masked]>
> Cc: <[email-masked]>;
> <[email-masked]>
> 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" <[email-masked]>
>>> To: "netmod WG" <[email-masked]>
>>> Cc: <[email-masked]>;
>>> <[email-masked]>
>>> 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
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> .
>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 18 Oct 2017 17:48:38 +0100

Hi Tom,

Regarding the issue on the definition of inactive configuration, in the 
end we think that we don't need to define it for the following reasons:

1) Juergen's new objectives contains a brief description of inactive 
configuration (without defining it).
2) Inactive has been removed from the normative text, instead the 
normative text more generically refers to "configuration 
transformations" and just uses inactive as an example of such a 
transformation.
3) Configuration transformation is defined as:

    o  configuration transformation: The addition, modification or
       removal of configuration between the <running> and <intended>
       datastores.  Examples of configuration transformations include the
       removal of inactive configuration and the configuration produced
       through the expansion of templates.

OK?

Validating that this is sufficient to address your concern maybe easier 
when we post an updated revision with all WG LC markups applied.

Thanks,
Rob

On 17/09/2017 21:21, t.petch wrote:
> From: "Juergen Schoenwaelder" <[email-masked]>
> Sent: Friday, September 15, 2017 6:09 PM
>
>
>> Two comments:
>>
>> - Obviously, inactive can be in <candidate> and I would not rule out
>>    that inactive configuration can be in any other or future
>>    configuration datastores.
>>
>> - Whether protocols support inactive or not does not belong into a
>>    definition of what inactive configuration is. The same for backwards
>>    compatibility considerations etc.
>>
>> So if we define inactive configuration, the definition should be
>> something like this:
>>
>> * inactive configuration: Configuration held in a configuration
>>    datastore that is marked to be inactive. Inactive configuration is
>>    ignored during validation and never applied and actively used by
>>    a device.
>>
>> Yes, we should use 'inactive configuration' everywhere to be
> consistent.
>
> Juergen
>
> Yes, your definition is better than mine; let's add it.
>
> Tom Petch
>
>> /js
>>
>> On Fri, Sep 15, 2017 at 05:20:15PM +0100, t.petch wrote:
>>> Inactive appears a dozen times but is not defined, except in the
> course
>>> of those appearances it effectively is, but is sometimes 'inactive',
>>> sometimes 'inactive configuration', sometimes 'inactive data'.
>>>
>>> I would find it clearer if the term was used consistently and if
> there
>>> was an explicit definition amongst the other definitions in section
> 2
>>> such as
>>>
>>> inactve configuration: Configuration that is present in <running>
> which
>>> is not in use by the device and which plays no part in validation.
> It
>>> cannot appear in any other datastore.  The protocols that are
> currently
>>> standardised do not support inactive configuration but a number of
>>> proprietary protocols do. Inactive configuration is only exposed to
>>> clients that indicate support for inactive configuration; clients
> not
>>> indicating support for  inactive configuration receive the contents
> of
>>> <running> with the inactive configuration removed.
>>>
>>> This would put a stake in the ground for as and when the concept is
>>> standardised and may reduce the proliferation of the term with
> multiple
>>> meanings.
>>>
>>> Tom Petch
>>>
>>>
>> --
>> 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/>
> .
>