Subject: [netmod] YANG 1.1 Issue: error-app-tag collisions (real example)

From: Andy Bierman <[email-masked]>
Date: Tue, 1 Jul 2014 13:11:27 -0700

Hi,

We have known for years that the error-app-tag leaf is not
that useful because standard values override vendor values
(and clients can't tell them apart anyway).

Now modules like ietf-routing are defining error-app-tag values
in description statements (contributing to the completely ad-hoc
registry of arbitrary strings).

Not sure if this is already reported, but RFC 6020 and 6022 both
define a 'data-not-unique' error-app-tag.  The one in 6020 is for
a unique-stmt failure and requires an error-info node pointing at
the non-unique leaf.  The 6022 version is for a <get-schema> request
without a <revision> element (and there are multiple revisions
on the server.  No <error-info> is returned in this version.

RFC 6020, sec. 13.1:

   If a NETCONF operation would result in configuration data where a
   unique constraint is invalidated, the following error is returned:

     error-tag:      operation-failed
     error-app-tag:  data-not-unique
     error-info:     <non-unique>: Contains an instance identifier that
                     points to a leaf that invalidates the unique
                     constraint. This element is present once for each
                     non-unique leaf.

                     The <non-unique> element is in the YANG
                     namespace ("urn:ietf:params:xml:ns:yang:1").

RFC 6022, sec. 5:

  rpc get-schema {
    description
      "This operation is used to retrieve a schema from the
       NETCONF server.

       Positive Response:
         The NETCONF server returns the requested schema.

       Negative Response:
         If requested schema does not exist, the <error-tag> is
         'invalid-value'.

         If more than one schema matches the requested parameters, the
         <error-tag> is 'operation-failed', and <error-app-tag> is
         'data-not-unique'.";

The flat list of strings is so fragile, we can't even keep track of our
own standard values.  Not to mention the fact that every time we add
a new ad-hoc standard error-app-tag, it could be colliding with a vendor
value that is already deployed.

IMO this part of NETCONF/YANG is significantly broken and needs
to be fixed or completely removed.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Jul 2014 22:25:37 +0200 (CEST)

> on the server.  No <error-info> is returned in this version.

I don't think this is a problem in this case.  These error-app-tags
are returned for different operations, so there is no conflict.

> to be fixed or completely removed.

I don't think this is a pure YANG issue, but a NETCONF/XML issue.  I
suggested a long time ago that this should be encoded as a QName in
NETCONF.  This would require a new version of the protocol though :(

RESTCONF can use QName in XML and <modulename>:<error-app-tag> in
JSON.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 1 Jul 2014 13:44:20 -0700

> are returned for different operations, so there is no conflict.
It is bad precedent and IMO sloppy design.
These values should not be per-operation.
For example, a tool validating the <rpc-reply> would need to know the <rpc>
in order to generate or suppress a missing <non-unique> error.

> NETCONF.  This would require a new version of the protocol though :(

This field in the protocol is broken.  2 years from now, it will still be
broken.
Perhaps the error-message and error-app-tag statements could be allowed
as child statements of data-def-stmts, but that is not part of YANG 1.1.
E.g.: error-tag-stmt below.

 rpc route-count {
    description
      "Return the current number of routes in a RIB.";
    input {
      leaf rib-name {
        type rib-state-ref;
        mandatory "true";
        description
          "Name of the RIB.

           If the RIB with name equal to the value of this parameter
           doesn't exist, then this operation SHALL fail with
           error-tag 'data-missing' and error-app-tag
           'rib-not-found'.";

         error-tag data-missing {
           error-app-tag rib-not-found;
         }

      }
    }

> RESTCONF can use QName in XML and <modulename>:<error-app-tag> in

Yes -- this is how it should work. IMO leaf-list instead of leaf as well.

Andy