Subject: [Netconf] validate-1.1 capability

From: Andy Bierman <[email-masked]>
Date: Sun, 09 Aug 2009 08:18:30 -0700

Hi,

The validate-1.1 capability is somewhat broken.
I would prefer to see all the validate capability
be mandatory (including rollback-on-error), but this
would mean a new protocol version.

It is trivial to implement test-only, but it is
only available if the agent implements test-then-set
and the <validate> operation.

As Balazs pointed out many times already, the fact that
the manager MUST NOT provide this parameter unless
:validate is supported is really fragile.

Also, I have pointed out many times that the default of 'test-then-set'
is totally wrong.  It makes no difference on running, but
on the candidate, it will disrupt incremental editing.
The default should always be 'set'. (test-then-set forces the
manager to provide all the related edits at once, but
that is totally contrary to the purpose of the candidate config).

I want to change 4741bis to reflect this behavior,
except I think micro-partitioning the parameters
for various operations in arbitrary ways needs to stop.
So I don't want to fix it with a band-aid like this validate-1.1
capability.  This design approach will be a disaster for
NMS developers within a few years.

By insisting that the protocol version stay the
same, the WG is actually making NETCONF harder to
use for NMS developers, not easier.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 10 Aug 2009 14:43:42 +0200 (CEST)

Hi,

> The validate-1.1 capability is somewhat broken.

[...]

> capability.

validate-1.1 adds one optional enumeration value.  It does not try to
fix the problem you raise at all, so I don't see how it is a band-aid
for this problem.

> would mean a new protocol version.

+1, but I'm not sure that this is important enough (on its own) to
warrant a new protocol version.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 10 Aug 2009 10:11:41 -0400

>would mean a new protocol version.

"Doesn't work the way I prefer" != "broken", right?

>and the <validate> operation.

In some implementations, test-only requires a complete copy of the
configuration, which for some devices was seen as an impediment to
their adoption of netconf.  So it's optional.

>:validate is supported is really fragile.

If your kernel doesn't support TIOCGWINSZ, calling ioctl with that
parameter will get you an error.  Does that make your kernel
"really fragile"?

NETCONF isn't supposed to force the device to live by a single set
of rules (not that the nm community could ever agree on that set
of rules), but to allow the device to let you know what you can and
cannot do to it.  Once it has told you, it's the client responsibility
to act accordingly.

>I want to change 4741bis to reflect this behavior,

-1: This would be a break in backwards compatibility.

>use for NMS developers, not easier.

NMS developers that want "set" can say "set".  This may be slightly
less convenient for them, but I don't see this as a serious hardship.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Aug 2009 08:07:57 -0700

> "Doesn't work the way I prefer" != "broken", right?

It is trivial to have a leaf parameter called <test-only/>.

There are 2 design choices the NETCONF WG keeps making
that are going to be a big problem later, when all
the YANG modules in the world cannot be counted on one hand.

  1) over-loading existing capabilities with new requirements
     and meanings, so the NMS has to look at a hard-wired set
     of variables (not all boolean) to see how the agent really
     works for some operation.
  2) using capabilities to micro-partition the data model.
     The if-feature-stmt is great because you cannot set the
     granularity any finer than a single leaf.

There needs to be a balance between implementation
requirements on the manager and the agent.

> parameter will get you an error.  Does that make your kernel

This is an API that we have control over.
It is not some HW error in the kernel.
That has nothing to do with how easy it
is for a manager to use the API.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Aug 2009 08:27:46 -0700

> fix the problem you raise at all, so I don't see how it is a band-aid

I would rather the standard used a new leaf for this
purpose, and put it in a new 'test-only' YANG feature,
instead of using the :validate capability at all.

Capabilities are evil.  They cannot be automated.
They are buried in multiple sections or
multiple RFCs, and the interactions are hard to figure out.

The overloading of multiple capabilities on a single XML element
is really awful.  Use another leaf.  We can make more.  It's ok.
We should use if-feature instead.

> warrant a new protocol version.

Depends if a better confirmed-commit procedure is
on the table.  Better to wait for that.  At some point,
we are going to need to 'roll up' many of the tiny little
options into a new protocol version.  I would like to
see :validate and :xpath be mandatory to implement
in version 2.

Andy