Subject: [netmod] Yang questions

From: Graham Phillips <[email-masked]>
Date: Thu, 7 Apr 2011 13:34:53 -0700

We are evaluation Yang for an existing appliance.  The questions below are in the context of a retrofit as opposed to starting from scratch.  If these questions have been posted to the wrong email alias, please let me know.

1.       I note that one can use "typedef" and "pattern" to construct a Yang type.  I'm not clear whether we can define all our types using just "pattern".  Currently our validation is done in C code.  Are there any recommendations for defining types where the "pattern" may not be sufficient?  One idea is to perhaps annotate the type with an ID, and this ID could then be associated (at build type) with a C validation function.

2.       Is there an example of how an Yang extension might be used to support hierarchical data.  For example, I'm doing something like this:

Ns-ext:build_release  "6.0"

Ns-ext:build_version  "12.0"
                Whereas our existing meta files (in Perl) have something like:
                                build_info => {
                                                release => "6.0";
                                                version = "12.0";
                                }

3.       Consider the following "enumeration":
typedef yesno {
   type enumeration {
     enum on {
       value 1;
    }
  enum off {
      value 2;
  }
Where is it defined that the CLI token "on" corresponds to value 1.  Is that defined in this typedef or does that need to be defined somewhere else?  What if we wanted the CLI to also accept the token "yes" as value 1, but perhaps hide this from CLI help and tab completion?  Should this information be in the yang file or not?

Thanks.
--Graham Phillips

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 09 Apr 2011 14:04:13 +0200 (CEST)

Hi,

Graham Phillips <[email-masked]> wrote:
> 
> 
> We are evaluation Yang for an existing appliance.  The questions below are in
> the context of a retrofit as opposed to starting from scratch.  If these
> questions have been posted to the wrong email alias, please let me know.
> 
> 
> 1.  I note that one can use "typedef" and "pattern" to construct a Yang type.
> I'm not clear whether we can define all our types using just "pattern".
> Currently our validation is done in C code.  Are there any recommendations for
> defining types where the "pattern" may not be sufficient?  One idea is to
> perhaps annotate the type with an ID, and this ID could then be associated (at
> build type) with a C validation function.

This would be perfectly fine.  In fact, this is a technique that we
also are using.  I suggest you document the constraint clearly in the
typedef's description, and use your extension statement to instruct
your compiler / code generator that special code is needed.

> 2.  Is there an example of how an Yang extension might be used to support
> hierarchical data.  For example, I'm doing something like this:
> 

Sorry, I don't understand the question.

> Where is it defined that the CLI token "on" corresponds to value 1.

YANG doesn't talk about mapping to CLIs at all.  Such a mapping is
always proprietary.  But YANG does define that the XML value "on"
corresponds to the value 1, so it seems natural to use the same
mapping for a CLI built from YANG.

> Is that
> defined in this typedef or does that need to be defined somewhere else?  What
> if we wanted the CLI to also accept the token "yes" as value 1, but perhaps
> hide this from CLI help and tab completion?  Should this information be in the
> yang file or not?

This is outside the scope of YANG, but I would suggest that you use a
proprietary YANG extension to cover this:

 typedef yesno {
    type enumeration {
      enum on {
        value 1;
        foo:alias-name "yes";
     }
   enum off {
        value 2;
        foo:alias-name "no";
   }

/martin