Subject: [netmod] error-app-tag QName?

From: Andy Bierman <[email-masked]>
Date: Sat, 23 Aug 2008 12:41:28 -0700

Hi,

Martin brought this up a long time ago, but
maybe now is time to fix error-app-tag before
it gets too hard to change it later.

Right now, an application cannot use the string
in a multi-module-publisher environment (gee, all of them)
because there is no way to tell error-app-tag
values apart from different vendors.  There are also no
definitions within YANG, so no way to associate them
with a given module.

Instead of the xsd:string data type we have now:

    <error-app-tag>my-error</error-app-tag>

We should be using a xsd:QName instead:

    <error-app-tag>acme:my-error</error-app-tag>

In this way, vendors and IETF WGs can define their
own error-app-tags without any need for a centralized
registry.  An empty XML element works the same in
YANG as a plain OBJECT-IDENTIFIER in SMIv2.

But what prefix/namespace to use for the YANG error codes?

YANG needs an XSD anyway to define the insert and key
XML attributes, so that XSD can contain some empty
elements for registration points

    <element name="data-not-unique">
      <annotation>
        <documentation>
            YANG error-app-tag identifier for an unique
            statement violation during the validation of
            a NETCONF configuration database.
        </documentation>
      </annotation>
    </element>

     ...

    <error-app-tag>yang:data-not-unique</error-app-tag>

Note that YANG cannot support the definition of a registration
QName (element name) because it would be interpreted as a
database leaf, not a registration leaf.

What if we had a generic object identifier statement
for YANG, that was top-level only (body-stmt), and
was used to define the YANG equivalent of registration OIDs?

module yang {

    ...

    identifier data-not-unique {
       status current;
       description
           "YANG error-app-tag identifier for an unique
            statement violation during the validation of
            a NETCONF configuration database.";
       reference
           "draft-ietf-netmod-yang-00.txt, sec. E.1";
    }

    ...
}

Andy

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Aug 2008 11:27:10 +0200 (CEST)

Hi,

[removed cc: netconf, since I just comment on the YANG bits]

>            "draft-ietf-netmod-yang-00.txt, sec. E.1";

So when an "error-app-tag" statement is used, it MUST refer to an
existing identifier?  In the current module or some other module:

   import foo { prefix foo; }
    ...
      error-app-tag foo:fatal-error;

Can the identifiers defined with this statement be used for something
else than just error-app-tag?  Is the idea that they can be used like
OBJECT-IDENTITY - if so, do we also need a corresponding builtin type
"identifier" (or better name) which is encoded as a QName:

     leaf encryption-method {
        type identifier;
     }

     identifier des3 { ... }
     identifier aes128 { ... }

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Aug 2008 05:38:08 -0700

>       error-app-tag foo:fatal-error;

yes

>      identifier aes128 { ... }

yes -- that is the main purpose.
SNMP has a registration OID mechanism.
The YANG approach (keep augmenting a choice
with empty leafs) is pretty lame.  YANG needs
some sort of ID-only node to solve this correctly.

Either assuming a bunch of IANA registries will be
created, or simply ignoring naming collisions, seems
like a bad idea.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Aug 2008 18:42:06 +0200 (CEST)

> SNMP has a registration OID mechanism.

I support this idea.

> with empty leafs) is pretty lame.

I agree it's sort of not obvious.  It's actually more powerful than
OBJECT IDENTITY/OBJECT ODENTIFIER, b/c you cannot restrict the OID in
the model; there is no formal way to know which values the
'encryotion-method' object above might get.  E.g. there is no way to
known that you cannot set 'encryotion-method' to 'data-not-unique'.

If the 'encryption-method' is a choice, each value is an augment and
thus very specific.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Aug 2008 09:59:34 -0700

> If the 'encryption-method' is a choice, each value is an augment and

This is true, and these are used more often for read-only data.
In reality, the manager needs to know which module contains
the 'identify' or the 'augment', and know what it means.

A bunch of leaf x (identifies platform x) leaf y, etc.
is no better than identifier x,y for this purpose.
An invalid-value comes back either way if you send
the ID for a chassis fan when the agent expects the ID of the
encryption method.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 27 Aug 2008 10:32:16 +0200 (CEST)

> the ID for a chassis fan when the agent expects the ID of the

Yes, but I tend to prefer solutions where you know as much as possible
before trying.  On the tools-side, a client can provide the user with
e.g. a drop-down list of all available encryption methods, and this
list will not include the chassis fan.   With an unrestricted
'identifier', the list will either include the chassis-fan, or it will
not be a list at all; just a plain string.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Aug 2008 12:09:23 -0700

> not be a list at all; just a plain string.

fine. 'foo:error-name' is valid syntax for error-app-tag,
as well as just 'error-name'.  Implementations can put whatever
they want in there for their own error-app-tags, so
no change in the spec is even needed for the use case
I originally brought up.

The identifier issue might come up again,
like why doesn't YANG support the XSD QName data type?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 27 Aug 2008 21:16:11 +0200 (CEST)

> like why doesn't YANG support the XSD QName data type?

As I said, I support this idea.  We can start with the identifier
statement and require an error-app-tag statement to refer to an
existing identifier, and require YANG-compatible servers to declare
the prefix in the rpc-error and use prefix:identifier.  You're right
that no change is needed in rfc4741 for this.

The other question is if we need a corresponding 'identifier' (or
maybe QName) type.  I would like this, b/c I agree that the current
solution of augmenting choices is non-intuitive.  But I also think
that the current solution gives better control than a simplistic
identifier solution.

/martin