Subject: [netmod] How to use type that does not have standard yang typedef yet

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Mon, 16 Jul 2012 21:33:27 +0000

Hi,

I would like to find out what is the best practice to use a type that should be defined in another module but that module is not available yet. Here is the scenario:

My yang module B has a leaf L which type  T is a reference  (for example, vlan id, IP Protocol) to the id of a container/list in module A (for example VLAN, IP). However, module A is not defined yet. Should I define type T in B and then deprecate it when module A is available? Should I use description to indicate type T and leaf L may be deprecate after module A or type T is available in some standard?

Thanks,

Lisa

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Jul 2012 00:43:22 +0200

> My yang module B has a leaf L which type  T is a reference  (for example, vlan id, IP Protocol) to the id of a container/list in module A (for example VLAN, IP). However, module A is not defined ye…

Are you saying T is a leafref? Or what does "T is a reference to the
id of a container/list" mean?

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

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Tue, 17 Jul 2012 00:36:09 +0000

Good comments. Obviously I could not use leafref since the leaf and its
container module is not present.

On 7/16/12 3:43 PM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>> I would like to find out what is the best practice to use a type that
>>should be defined in another module but that module is not available
>>yet. Here is the scenario:
>> 
>> My yang module B has a leaf L which type  T is a reference  (for
>>example, vlan id, IP Protocol) to the id of a container/list in module A
>>(for example VLAN, IP). However, module A is not defined yet. Should I
>>define type T in B and then deprecate it when module A is available?
>>Should I use description to indicate type T and leaf L may be deprecate
>>after module A or type T is available in some standard?
>> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Jul 2012 08:42:06 +0200

Hi,

I still do not understand what precisely your question is hence it is
difficult to say something useful. Are you trying to import and use a
type that does not exist yet? Are you trying to use a leafref for
something that does not exist yet? And what does "use" mean - specify,
implement or deploy?

/js

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Tue, 17 Jul 2012 17:46:29 +0000

Here is one example. I have the following in B module:

Module B {
    ...
    typedef vlan-id {
	type uint16 {
	    range "1 .. 4095";
        }
	Description "vlan id  ";
    }

    Container B {
        Leaf vlanId {
            type vlan-id;
        }
    }

}

Module B has a leaf which type is vlan-id. Ideally, vlan-id typedef should
be defined in vlan module or some other ietf types module, which is not
existing yet. What is the right process to define vlan-id? Should I
propose the vlan-id typedef to ietf types module or define my own. If I
define my own, whenever the vlan ietf standard module defined, the only
way for module B to align with the standard is to deprecate both vlan-id
and leaf vlanId. 

Thanks, 

Lisa

However

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Jul 2012 21:49:01 +0200

> way for module B to align with the standard is to deprecate both vlan-id

In the SMI world, we usually allowed to replace an inline type
(syntax) definition with a textual convention (type) definition if
both were 100% semantically identical. As a matter for fact, it often
happened that inline definitions were later turned into TCs in order
to reuse them (or to move maintenance over to IANA).

The hard part is semantic equivalence.  If for whatever reason the
finally published type differes from your best guess, you indeed have
to deprecate the object(s) and create new one(s) or you stick with
your own definition.

Concerning the process, the simple answer is we do not really have
one. Right now, the recommendation is to write up concrete proposals
and to send them to the mailing list. I am trying to collect them and
at some point we need to decide what to do with them, e.g., revising
RFC 6021 and adding definitions or even more modules. (Ideally, a
vlan-id typedef would be defined by the IEEE but this is unlikely to
happen anytime soon.)

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Jul 2012 12:54:10 -0700

See RFC 6020, page 136:

   o  A "type" statement may be replaced with another "type" statement
      that does not change the syntax or semantics of the type.  For
      example, an inline type definition may be replaced with a typedef,
      but an int8 type cannot be replaced by an int16, since the syntax
      would change.

Andy

On Tue, Jul 17, 2012 at 12:49 PM, Juergen Schoenwaelder
<[email-masked]> wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Tue, 17 Jul 2012 21:28:44 +0000

Andy, 

Thanks for the comments.

Does it mean the following change is allowed?

Before:

Module B {
    revision 2012-01-08
    ...
    typedef vlan-id {
        type uint16 {
        range "1 .. 4095";
    }
    Description "vlan id  ";
    }

    Container B {
	Leaf vlanId {
	    type vlan-id;
	}
    }

}

After:

Module B {
    Import A { prefix a ;}
    revision 2012-08-08		<--- change the revision
    ...

    Container B {
	Leaf vlanId {
	    type a:vlan-identifier	<---change to the type from import
	}
    }
}
Module A {

    typedef vlan-identifier {	<---typedef name changes
	type uint16 {
	    range "1 .. 4095";
        }
	Description "This type denotes a VLAN tag.  ";   <--- description is not
exactly the same.
    }
}

Thanks,

Lisa

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Jul 2012 15:08:36 -0700

> Does it mean the following change is allowed?

yes.
The syntax and semantics cannot change.
The packaging can change, including wrapper types;

typedef new-vlan-id {
   type vlan-identifier;
}

Andy