Subject: [Netconf] making more 4741bis waves

From: Andy Bierman <[email-masked]>
Date: Fri, 09 Apr 2010 13:50:38 -0700

Hi,

I have some new issues for 4741bis:

1) test-only enum

   I really dislike using a protocol capability for 1 enum value of
   1 parameter of 1 RPC operation.  Is there a way to avoid this?

   We never actually solved the problem of what <validate> means,
   or what 'test-then-set', 'test-only' means, so it's not like the :validate
   capability is something special. (See 2 below).

   We should make it more clear what a server does for validation:
        #1)  test-then-set == test-only == validate, except for a conceptual
             config made from the config source and the target config.
             A validate is done on a conceptually complete database.
             Only the test part of test-then-set is considered here.
        #2) The server MUST detect all schema errors
        #3) The server SHOULD detect all platform-specific constraints
            that are specified in description statements instead of
            machine-readable statements.
        #4) The server MAY detect resource allocation errors.
        #5) The server MAY detect network-wide constraint violations

2) <test-option> present is an error

   Balazs complained before that a client MUST NOT set the <test-option>
   leaf if :validate is not advertised, even though there are
   defaults defined for the server for both modes.  This is a CLR.
   We should just make the <test-option> optional in base:1.1
   and the server MUST use the appropriate default.

3) <test-option> default

   It is very resource-intensive to default the test-option to test-then-set
   on the candidate config.  This also breaks incremental changes to candidate,
   since the test-then-set option means "make sure the entire database is valid".

   IMO, this should be fixed.  It would be simpler if there was just
   an plain optional default with a default:

   OLD:

        leaf test-option {
           if-feature validate;
           type enumeration {
             enum test-then-set;
             enum set;
             enum test-only {
               description
                 "This value can only be used if the 'validate-1.1'
                  feature is supported.";
             }
           }
         }

   NEW:

        leaf test-option {
           type enumeration {
             enum test-then-set {
               description
                 "This value can only be used if the 'validate'
                  feature is supported.";
             enum set;
             enum test-only {
               description
                 "This value can only be used if the 'base-1.1'
                  capability is supported.

                  If the 'validate' feature is also supported,
                  then the server will perform a complete
                  validation procedure.

                  If the 'validate' feature is not supported,
                  then the server will make a best-effort attempt
                  to detect any errors in the <edit-config> request.";
             }
           }
           default set;
        }

4) new 'destroy' operation

   The nc:delete operation is too picky.
   The server MUST return a 'data-missing' error-tag if the data
   instances do not exist as predicted by the client.

   A new operation called 'destroy' would be like an 'rm -f' command.
   The data is deleted if it exists.
   The requested data MUST identify data nodes that the server supports
   but if the requested instances do not exist, then <ok/>  is still returned.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Apr 2010 08:25:14 +0200 (CEST)

>    1 parameter of 1 RPC operation.  Is there a way to avoid this?

Yes, if 4741bis defines base:1.1 we don't need this capability.

>              A validate is done on a conceptually complete database.

I'm not sure I understand the "except..." part above, but I agree that
"test-" should be the same as validate.  So if you do:

  edit-config candidate, test-option=set
  validate candidate

you would detect the same errors as

  edit-config candidate test-option=test-then-set

(the db contents will be different, but that's not the point)

>             machine-readable statements.

s/platform-specific//

But this depends on the text in the description statement.  If the
textual constraint says that a server MUST detect a certain constraint
in a valid config, then this is a MUST, not SHOULD.

>         #5) The server MAY detect network-wide constraint violations

I do not undertand what #5 means.  Typically, network-wide constraints
cannot be checked on a single device - that's what makes then network
wide!

>    and the server MUST use the appropriate default.

I disagree.  The behavior you describe is what you get from this leaf:

      leaf test-option {
        if-feature validate;
        type enumeration {
          enum test-then-set;
          enum set;
          enum test-only;
        }
        default "test-then-set";
      }

The leaf itself is conditional based on the feature.  If the feature
is enabled, there is a default value.

Is this leaf construct in some way bad design?

> 4) new 'destroy' operation

Yes please!!

>    but if the requested instances do not exist, then <ok/>  is still returned.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Apr 2010 08:52:26 -0700

> "test-" should be the same as validate.  So if you do:

validate applies to an entire config provided by the client

test-* applies to the conceptual config made from
combining the client config fragment with the real config
to construct a complete config to validate

>>             machine-readable statements.

OK

> cannot be checked on a single device - that's what makes then network

A constraint doe not have to be local.
What if the device can use the network
to check an identifier that is
supposed to be unique within the entire administrative domain?

> I disagree.  The behavior you describe is what you get from this leaf:

This is what we have now.

The 'set' option is a NO-OP for this parameter.

It is a lot simpler to implement test-only than validate.

It seems better if test-only were available on all
servers, even if it does not check all the errors
that :validate is supposed to check.

But this is not that important.  Server developers just
need to do more work and support :validate.

> Is this leaf construct in some way bad design?

Yes.

The 'set' enum is a NO-OP.
A server that does not support :validate
supports the NO-OP mode already.

I would rather get back an invalid-value for setting the leaf
to 'test-only', than get an error that the leaf does not exist
at all.

But this is not important either I guess.
The client will get an error either way.

This switch is also counter-intuitive because the test-then-set
enum is pointless (since it is the default).  The only thing for
a client to do is disable this test-option by being forced to
provide the 'set' value.

IMO, the client should opt-in for this testing because:
  - the candidate is supposed to allow incremental edits
  - this parameter has no affect on the running config (test-then-set
    is always done on running -- 'set' means nothing here)

Andy