Subject: [Netconf] :test-only-1.0 instead of :validate-1.1

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Sep 2009 09:45:43 -0700

Hi,

I think the <test-option> still needs work, and Balazs
also raised issues about it.  All but 2 issues are
either resolved or don't-care:

  1) the client should be able to use 'test-only'
     in edit-config, even if :validate-1.0 is not supported

  2) the client is not allowed to provide any leaf at all
     if :validate-1.0 is not supported.

I think we should consider a :test-option-1.0 capability,
instead of a :validate-1.1 capability:

If the :test-only capability is advertised, it means the server
will accept the new <test-only> parameter to edit-config.
(See below.)  It preserved validate-1.0 for the clients
that rely on it, and decouples the new functionality.

The validate-1.0 capability would remain unchanged.

A new 'test-only' feature would be added to match the new :test-only
capability.

The edit-config/input section would be modified as follows:

   choice edit-config-test-option {
      if-feature validate;
      if-feature test-only;

      leaf test-option {
         if-feature validate;
         // rest same as RFC 4741
      }

      leaf test-only {
         if-feature test-only;
         type empty;
         description
           "The server will perform all the validation procedures
            for the requested operation, except no changes will
            be made to the specified target database.";
      }
   }

I think this is cleaner than :validate-1.1.
The concept of 'validation' in NETCONF is server-specific,
and probably of little standards value, but there is still
operational value in a 'test-only' mode on each server.

There is no other way to validate a partial configuration
against an existing database.  The 'test-only' mode will
validate a specific edit-config operation, which must
account for arbitrarily nested nc:operation attributes.
It allows clients to ask "will this edit work?",
which is currently not possible in NETCONF.

Andy