On 18/09/2017 15:21, Andy Bierman wrote:
On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton <[email protected]
<mailto:[email protected]>> 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 <[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
