Subject: [Netconf] error-app-tag in standards

From: Andy Bierman <[email-masked]>
Date: Fri, 21 May 2010 12:42:22 -0700

Hi,

I started a new thread because I want to understand
how implementors use <rpc-error>.

There are several instances in standard NETCONF content
where error-app-tag values are mandated.  Besides creating
busy work for server developers, I'm not sure this has
any other impact.

Strings like 'no-matches' or the worst one (in with-defaults!)
called 'with-defaults-mode-not-supported', look like
error messages with dashes instead of spaces.  Why not
mandate error messages instead?  At least those can
be translated into other languages.

 error-app-tag:  Contains a string identifying the data-model-specific
      or implementation-specific error condition, if one exists.  This
      element will not be present if no appropriate application error
      tag can be associated with a particular error condition.

IMO, this field is over-loaded.
The problem is when there may be more than 1 tag, not zero tags.
Implementations cannot reply on this field if standards values
override the vendor tag with an arbitrary string.

We use this field for classifying errors into 1 of about 10
different enumerations, to help tune error dialogs based
on a known set of enumerations.   The IETF is overloading
the error-app-tag field with random error messages.  This ruins
any vendor-specific use of this field.

Andy