On 18/09/2017 17:03, Andy Bierman wrote:
On Mon, Sep 18, 2017 at 8:34 AM, Robert Wilton <rwil...@cisco.com
<mailto:rwil...@cisco.com>> wrote:
On 18/09/2017 15:21, Andy Bierman wrote:
On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton <rwil...@cisco.com
<mailto:rwil...@cisco.com>> 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:
No. I do not agree that the MUST in RFC 7950 can be removed.
I do not agree the architecture should update YANG at all.
OK.
So, can the NMDA draft just be silent about whether <running> is valid
or not? I.e. allowing the current statement in 7950 to stand. That way
if inactive or templating are standardized, and if the standard solution
means that running is no longer always valid, then those drafts can
update 7950 as appropriate.
The NMDA architecture can still specify <intended> and also still
specify that it is always valid, and explain its relationship to
<running> and <operational>.
Thanks,
Rob
Andy
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
<m...@tail-f.com <mailto:m...@tail-f.com>> wrote:
Andy Bierman <a...@yumaworks.com
<mailto:a...@yumaworks.com>> wrote:
> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@jacobs-university.de>> 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
