Subject: [Netconf] test-option default

From: Andy Bierman <[email-masked]>
Date: Sun, 05 Jul 2009 22:06:10 -0700

Hi,

The <test-option> parameter to the <edit-config> operation
has 2 different defaults:

  test: if :validate not supported
  test-then-set: if :validate is supported

Not only is this confusing, but it is actually wasteful and
may cause false errors, if the default used is 'test-then-set'.

There is no point in validating the <running> config.
This should always be valid.  The agent uses 'test-then-set'
all the time if :writable-running is supported.

If the <edit-config> target is <candidate>, then incremental edits are
to be expected, so validating the entire <candidate> database by default
may lead to false errors and scripts that normally work
will break if :validate is supported by the agent.
This is unacceptable.

I propose that the default for <test-option> always be 'test'
in the new :validate.1.1 capability (will be in next 4741bis draft).
I would like to alter the :validate.1.0 behavior to match, if that
is OK.  Hopefully, no managers rely on, or want, an automatic
validate of the <candidate> each time it is written.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 Jul 2009 19:14:47 +0200 (CEST)

>   test: if :validate not supported

This should be 'set'.

> validate of the <candidate> each time it is written.

I understand your reasoning but I think this falls in the
"nice to have enhancement" category - yes it would be better to always
have 'test' as default, but it is not backwards compatible.  It is not
unreasonable to assume that a client that *wants* test-then-set on the
candidate leaves it out, since it is the default.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 06 Jul 2009 11:38:30 -0700

> candidate leaves it out, since it is the default.

I think it's in the "currently broken" category.

      test-option:

         The test-option element may be specified only if the device
         advertises the :validate capability (Section 8.6).

         The test-option element has one of the following values:

         test-then-set: Perform a validation test before attempting to
            set.  If validation errors occur, do not perform the
            <edit-config> operation.  This is the default test-option.

         set: Perform a set without a validation test first.

If :validate is not supported, setting this parameter to
any value will yield a 'unknown-element' error.

So a manager has to make sure the capability is supported
before turning off this behavior.

So a manager has to write scripts for the <candidate> database
that check the :validate capability, so normal incremental
edits do not cause errors.

Way too fragile!

I think this has to be changed in :validate.1.1.
The normal use-case for <candidate> breaks by default.
IMO, that is a bad default.  The default should be
for <edit-config> to always work the same, unless
the manager takes explicit action to do something
differently.

BTW, it is OK to advertise validate.1.1 and not validate.1.0, right?
Let vendors deprecate broken features if they want.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 07 Jul 2009 08:20:28 -0700

WashamFan wrote:
> Hi,
> 
> ----- Original Message -----
> From: Andy Bierman <[email-masked]>
> Date: Tuesday, July 7, 2009 2:40 am
> Subject: Re: [Netconf] test-option default
> To: Martin Bjorklund <[email-masked]>
> Cc: [email-masked]
> 
> 
>> Martin Bjorklund wrote:
> So extra effort is needed to check the version of the :validate if 
> they are not compatible. But 1.1 as you described is more reasonable
> to me. Maybe from a long-term perspective, we should do 1.1 
> 

We already are doing a :validate.1.1 to add the 'test-only'
enumeration.

This is an example of implementors doing what works,
rather than what the standard says.

It turns out that the big complicated :validate capability
that was thought to be so clever when it was written,
is actually mostly useless.

It turns out that a simple 'test-only' enum that took 20 minutes to
implement is much more useful.

Backwards compatibility is extremely important when it
is real -- based on real operators solving real problems
with running code.  That's not what we have with :validate.1.0.

And if :confirmed-commit.1.0 is considered too lame to preserve,
that's a good thing.  If version 1.1 is way better, then 1.0
will go away anyway because nobody will want to use it.

> washam

Andy

---

From: WashamFan <[email-masked]>
Date: Tue, 07 Jul 2009 19:45:52 +0800

Hi,

----- Original Message -----
From: Andy Bierman <[email-masked]>
Date: Tuesday, July 7, 2009 2:40 am
Subject: Re: [Netconf] test-option default
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]

washam

>  
>  > 
>  > /martin
>  > 
>  > 
>  
>  
>  Andy
>  _______________________________________________
>  Netconf mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 13 Jul 2009 19:39:21 +0200

> any value will yield a 'unknown-element' error.

Also it is not stated what happens if you omit the option. The normal thing would be to use its 
default value, but that is not possible if :validate is not supported.

So this is clearly broken.

Balazs