Subject: [Netconf] test-option in edit-config operation

From: Tomasz Mikolajczyk <[email-masked]>
Date: Thu, 27 Nov 2008 18:13:44 +0100

Hi,

The RFC 4741 in section 7.2 says:

"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.
"

Does it mean that the "test-option=set" value is the same as "normal"
edit-config behavior, i.e. as without :validate capability advertised?
If it does, I think the "set" value should be the default one and could
be specified in the request no matter if the :validate capability is
advertised or not. The "test-then-set" value would be allowed to use
only if a server supports the :validate capability.

Tomasz

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: [email-masked].
Thank You.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Nov 2008 09:40:34 -0800

> edit-config behavior, i.e. as without :validate capability advertised?

yes

> only if a server supports the :validate capability.

I disagree.
The default should be to do the most validation available,
not the least.  I agree that this knob should
always be accepted if the value is 'set', regardless of
the :validate capability.

Note that YANG must, unique, and keyref validation will
probably require an agent to run its validation code
anytime the <running> config is changed.  But since the
<running> config is never allowed to be invalid,
then there isn't much reason to have this knob at all.
The best change would be to get rid of test-option completely.

> Tomasz

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Nov 2008 09:40:34 -0800

yes

I disagree.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Nov 2008 20:36:23 +0100 (CET)

> The best change would be to get rid of test-option completely.

Some implementations (including yours I believe) also allow the value
"test-only" for test-option.  By using this value, you can validate an
edit-config PDU.  If I understand things correctly, this was supposed
to be covered by the <validate> operation, but as we have discussed
serveral times earlier, this didn't work.  So I would rather like to
see "test-only" standardized.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Nov 2008 20:36:23 +0100 (CET)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Nov 2008 12:50:58 -0800

> see "test-only" standardized.

I agree test-option=test-only is more useful, perhaps a different
use-case.  The only use for the current enums would be
if you wanted to force or avoid a validate on the candidate config
each time you did an incremental edit-config.  I don't
know why that is useful, which is why Tomasz wants to change
the default to 'set'.

Most implementations (including mine) do not run all
the 'commit-tests' on edit-config operations to candidate,
since the whole point of this target is
to allow incremental edits which may not be valid
until all the edits are done.

I'm currently implementing this default wrong for candidate,
so thanks for pointing that out.  You have to run <validate>
explicitly to run the 'commit-tests' on candidate.  I ignore
test-then-set I guess.

I changed my mind about removing this knob.
I forgot about test-only.  The default should
be set, since that is the right thing for candidate,
and the same as test-then-set for running.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Nov 2008 12:50:58 -0800

Andy

---

From: [email-masked]
Date: Thu, 27 Nov 2008 23:38:16 -0000 (GMT)

> not the least.

So maybe the :validate capability should be mandatory.
You can't use the "test-then-set" value if your server doesn't support
this capability and you can't use also the "set" value in this case (even
if it is not connected with the validation at all).
The default value "test-then-set" means that such value is used by a
server no matter if the "<test-option>test-then-set</test-option>" is
passed or isn't passed at all. The :validate capability is optional so
even if you don't use the <test-option> tag, the server assumes
"test-then-set" value. It makes no sense for me.

> I agree that this knob should

Tomasz

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: [email-masked].
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: [email-masked]
Date: Thu, 27 Nov 2008 23:38:16 -0000 (GMT)

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 28 Nov 2008 10:16:24 +0100

> then there isn't much reason to have this knob at all.

Huh! Is it not too strong assumption? At some point running
configuration may be valid, however :writable-running allows to
configure it directly, so bad data always might be passed. In addition
running configuration may be configurable via other protocols, like CLI,
snmp, etc. Moreover, many often device may have correlated parameters
and setting one parameter in the device may have influence on the
others, so you cannot be sure that it's always valid.

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 28 Nov 2008 10:16:24 +0100

Tomasz

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 01 Dec 2008 08:26:47 +0100 (CET)

> and the same as test-then-set for running.

Maybe the default should have been 'set', for consistency reasons.

But I don't think that this is a bug, so we should not change it in
4741bis.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 01 Dec 2008 08:26:47 +0100 (CET)

/martin