Subject: [Netconf] 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 interFrom [email-masked]  Sat Aug 23 12:41:38 2008
Date: Sat, 23 Aug 2008 12:41:28 -0700
From: Andy Bierman <[email-masked]>
To: NETMOD Working Group <[email-masked]>, NETCONF <[email-masked]>
Subject: [Netconf] error-app-tag QName?
Sender: [email-masked]

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 bepreted 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

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

 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

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