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 <[email protected]
<mailto:[email protected]>> wrote:
Andy Bierman <[email protected] <mailto:[email protected]>> wrote:
> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
> [email protected]
<mailto:[email protected]>> 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
