New Issue 1.5: Validation conformance

[Andy Bierman <abierman@cisco.com>]

Hi,

The protocol document is fairly vague on what an agent does
for <edit-config>, test-option==test-then-set or for the
<validate> operation.

The document says validate means at least check for syntax errors.
This just means check for well-formed XML throughout and proper
NETCONF message wrappers.  All implementations have to do this anyway.
Syntax check != XSD validation.

I am strongly opposed to standard features without standard semantics
to go with them.  IMO, unless we can do a better job defining the various
validation details, we should remove this feature from the draft.

Some document comments ...

-----------------------------

sec. 5.2, page 19:

      test-option: (test-then-set | set) [default: set]

            test-then-set: Perform a validation test before attempting
            to set; skip set if any errors.

            set: Perform a set without a validation test first.

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

Actually, just the value test-then-set is controlled by the #validate
capability.  It should not be an error if an application puts 
test-option="set" in an edit-config operation.

------------------

6.6.1 Description

   Validation consists of checking a candidate configuration for
   syntactical and semantic errors before applying the configuration to
   the device.

   If this capability is advertised, the device supports the <validate>
   protocol operation and checks at least for syntax errors.  In
   addition, this capability supports the validate parameter to the
   <edit-config> operation and, when it is provided, checks at least for
   syntax errors.

This paragraph should say that #validate also means the agent
will support test-option==test-then-set for <edit-config>.

------------------

6.6.4.1 <validate>
...

   Negative Response:

         An <rpc-error> element is included in the <rpc-reply> if the
         request cannot be completed for any reason.

         A validate operation can fail for any of the following reasons:

         +  Syntax errors

         +  Missing parameters

         +  References to undefined configuration data

What should an application expect to find in the 1 or more
<rpc-error> elements in the response?  Is there any structure
to validation error report at all?





--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>