[netmod] <running> vs <intended> [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Robert Wilton <[e-mail]>]

Hi Andy,

At the moment, NMDA does not change the definition of <running> for a 
standards compliant implementation of YANG/NETCONF/RESTCONF.  It is 
still the same as in 7950, and <running> must still be a "valid 
configuration data tree" for a standards complaint implementation.

However, the draft acknowledges that proprietary extensions exist that 
can modify the behaviour of <running> in ways that means that <running> 
is not always a valid configuration data tree.  The draft gives two 
examples of how <running> could be manipulated (inactive config, and 
templates).

If those extensions are standardized then I think it is likely that 
those RFCs would need to update 7950 to indicate that <running> isn't 
necessarily a "valid configuration data tree" when those extensions are 
used.  But I don't think that needs to be stated in the NMDA 
architecture at this time.

So, what is <intended>?
  - this is meant to represent the configuration that the system will 
actually attempt to apply after any and all manipulation (e.g. by 
templates, inactive removal, perhaps system scripts, etc) of the 
configuration has been performed.
  - it must always be a valid configuration data tree.
  - If <running> is updated then <intended> is always updated at the 
same time.  Hence, any successful change to <running> requires that 
<intended> has also been updated and validated.  E.g. in RESTCONF terms, 
I think that both <running> and  <intended> should get the same 
last-change timestamp whenever <running> is updated.
  - It provides a known fixed point so that any client can see the full 
validated config, i.e. even for devices that implement proprietary 
manipulations of the configuring in <running>.
  - If the device doesn't support any extra proprietary config 
manipulations, then <intended> is identical to <running>.

I think that we can possibly do a bit more to better define what 
<intended is>.  My previous suggestion as an improvement was below 
(perhaps you think it needs more clarification)?:

*OLD:*

4.4.  The Intended Configuration Datastore (<intended>)

    The intended configuration datastore (<intended>) is a read-only
    configuration datastore.  It is tightly coupled to <running>.  When
    data is written to <running>, the data that is to be validated is
    also conceptually written to <intended>. Validation is performed on
    the contents of <intended>.

    For simple implementations, <running> and <intended> are identical.

    <intended> does not persist across reboots; its relationship with
    <running> makes that unnecessary.

    ...

*NEW:*

4.4.  The Intended Configuration Datastore (<intended>)

    The intended configuration datastore (<intended>) is a read-only
    configuration datastore.  It represents the configuration after all
    configuration transformations to <running> are performed (e.g.
    template expansion, inactive configuration removal), and is the
    configuration that the system attempts to apply.

    It is tightly coupled to <running>.  When data is written to
    <running>, the data that is to be validated is also conceptually
    written to <intended>.  Validation is performed on the contents of
    <intended>.

    For simple implementations, <running> and <intended> are identical.

    The contents of <intended> is also related to the 'config true'
    subset of <operational>, and hence a client can determine to what
    extent the intended configuration is currently applied by checking
    whether the contents of <intended> also appears in <operational>.

    <intended> does not persist across reboots; its relationship with
    <running> makes that unnecessary.

    ...

Thanks,
Rob


On 17/09/2017 16:31, Andy Bierman wrote:
> Hi,
>
> My concern is that the definition of <running> is being changed to
> include undefined and undeclared proprietary extensions.
> This is counter-productive to the IETF's stated goal of interoperability.
>
>
> Andy
>
>
> On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Andy Bierman <[e-mail] <mailto:[e-mail]>> wrote:
>     > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
>     > [e-mail]
>     <mailto:[e-mail]>> wrote:
>     >
>     > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
>     > > > Hi,
>     > > >
>     > > > I strongly agree with Tom that the current draft is an
>     update to RFC
>     > > 7950.
>     > > > I also strongly disagree with the decision to omit RFC 2119 in a
>     > > standards
>     > > > track document. IMO RFC 2119 terms need to be used in
>     normative text,
>     > > > especially when dealing with XPath and YANG compiler behavior.
>     > > >
>     > >
>     > > RFC 8174:
>     > >
>     > >    o  These words can be used as defined here, but using them
>     is not
>     > >       required.  Specifically, normative text does not require
>     the use
>     > >       of these key words.  They are used for clarity and
>     consistency
>     > >       when that is what's wanted, but a lot of normative text
>     does not
>     > >       use them and is still normative.
>     > >
>     > >
>     > So what?
>     > Existing YANG specifications use RFC 2119 terms.
>     > This draft uses those terms, just with lower-case.
>
>     Actually, section 5.1 XPath Context in the revised datastore draft
>     uses the same language as section 6.4.1 XPath Context in RFC 7950.  In
>     fact, the text in the draft is copied (and adjusted) from RFC 7950.
>
>
>     /martin
>
>