Subject: [netmod] identity and identityref

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 11 Oct 2008 21:26:37 +0200

Hi!

In the SMIv2 world, we sometimes use OBJECT IDENTIFIERs (OIDs) as
distributed registries. An example are OIDs identifying crypto
algorithms. By using OIDs instead of enumerations, everybody can
create his own algorithm without having to go through a central
registry (IANA). This clearly has proven useful.

YANG currently lacks a mechanism to do this (enumerations are
centralized, choices with augmentations can't be reused since this
would require augmentable groupings). To provide distributed
registries in YANG, we (Martin and myself) propose the following
additions to YANG:

1) A new 'identity' statement that can be used to define identities
   (the equivalent of the SMIv2 OBJECT-IDENTITY macro). The base
   substatement associates an identity with a base identity. By way of
   example:

   // module a - introduces a crypto-alg registry
   module A {
     namespace uri:module:a;
     prefix a;
     identitiy crypto-alg {
       description ...; 
     }
   }

   // module b - registers a new algorithm
   module B {
     namespace uri:module:b;
     prefix b;
     import A { prefix a; }
     identity des {
       base a:crypto-alg;
       description ...;
     }
   }

2) A new 'identityref' type is introduced with a 'base' (or scope?)
   restriction. The value set of an identityref is the set of identities
   with the same base. By way of example:

   // module C - uses a leaf with crypto algorithms
   module C {
     namespace uri:module:c;
     prefix c;
     import A { prefix a; }
     leaf x {
       type identityref {
         base a:crypto-alg;
	 description ...;
       }
   }

   A possible XML encoding would look like this:

   <x xmlns:b="uri:module:b">b:des<x>

   Note that the value uses an XML namespace prefix and hence another
   possible XML encoding would be:

   <x xmlns:foo="uri:module:b">foo:des</x>

Using the XML namespace prefix in the XML encoding is consistent from
an XML perspective. However, this requires that applications dealing
with the value can deal with potentially different prefixes for the
same identity. An alternative would be to prefix the identity value
with the module name (B:des in the example) - this guarantees that the
value is always the same but this is somewhat strange from an XML
perspective.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Sat, 11 Oct 2008 16:28:02 -0700

> Hi!

I like this idea a lot.
I prefer to keep all XML instance documents XML namespace based,
using local prefixes via xmlns attributes.  Let's keep module
names out of XML documents because it will confuse people
who know XML and know about QNames.

A YANG content QName is simple to think about as
the namespace of the module + the name of an identifier
within that module.  A missing namespace should not be
allowed for a YANG QName, since we cannot agree on
what that means, or even if the NULL namespace is allowed.
IMO, every YANG definition should be defined in a unique
namespace, and the NULL namespace should be disallowed.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 13 Oct 2008 09:47:01 +0200

> value is always the same but this is somewhat strange from an XML
The idea is nice.
Question: do you have to import the module B, if you want to use the value defined in module B? 
If I do not import module B how does my system know that a value defined in Module B exists?
Balazs
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 13 Oct 2008 09:57:08 +0200 (CEST)

> Question: do you have to import the module B, if you want to use the value

What do you mean when you say "use the value defined in module B"?

If your module refer to a defintion in module B, then you have to
import it, otherwise not.

> value defined in Module B exists?

Compare with instance-identifer.  You don't import all the modules
that may end up in an instance-identifer.  Your system will implement
a set of modules.  If these modules define identities with the
identity in module A as a base, then a client can use them in
edit-config requests.

/martin