Subject: [Netconf] Difference between test-then-set and set within <edit-config>operation

From: Qin Wu <[email-masked]>
Date: Thu, 20 Dec 2018 01:31:50 +0000

Hi, All:
RFC6241 said:
"

      test-option:  The <test-option> element MAY be specified only if

         the device advertises the :validate:1.1 capability

         (Section 8.6<https://tools.ietf.org/html/rfc6241#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.

         test-only:  Perform only the validation test, without

            attempting to set.

"
It is not clear to me the real difference between test-then-set and set witin <edit-config> operation? Why test-then-set is set as default option?
Do we use explicitly validate operation defined section 8.6.4 of RFC6241 to perform validation test in the test-then-set?
RFC 7950 section 8.3.3 said:
"
If the datastore is
"running" or "startup", these constraints MUST be enforced at the end
   of the <edit-config> or <copy-config> operation.  If the datastore is
   "candidate", the constraint enforcement is delayed until a <commit>
   or <validate> operation takes place.
"
It gives me impression that for <running>, the configuration MUST be validated before it can be set.
Therefore there seems no difference between test-then-set and set option.
But for <candiate> datastore, selecting between test-then-set and set option seems to have value.
So when we will choose to use 'test-then-set', when we will choose to use 'set'?
Do we need to clarify this in RFC6241 for this?

-Qin