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

[Robert Wilton <[e-mail]>]

On 18/09/2017 15:21, Andy Bierman wrote:
>
>
> On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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).
>
>
> I don't see how NMDA can both acknowledge and violate the MUST be 
> valid in RFC 7950.
> That statement is quite clear in RFC 7950.
I think that NMDA acknowledges non standard extensions could exist that 
would violate RFC 7950 if/when those features are used, and provides a 
standard architecture (i.e. the definition of <intended>) to allow 
devices to expose the effects of those bespoke features in a standard way.

Phil had proposed adding the following text on validation:

+The implication of the existence of templating mechanisms is that
+<running> is now explicitly allowed to be invalid, since the
+templating mechanism may be supplying additional data that satisfies
+constraints that may not be satisfied by <running> itself.

Do you think that text like this would help?  Or perhaps more 
generically, something like this:

The implication of the existence of mechanisms that can allow
<intended> to differ from <running> means that <running> is no
longer guaranteed to always be valid.  However, when any
change is made to <running>, <intended> must also be updated at
the same time and be successfully validated before the operation
on <running> can be completed.

Obviously this would then need to update 7950.

>
>     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.
>
>
>  Right -- because 7950 still holds any any server that does not have a 
> valid <running>
> is non-compliant to 7950.
I agree.

Thanks,
Rob

>
>
> Andy
>
>     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
>>
>>
>
>