"Jason Sterne \(Nokia\)" <[email protected]> wrote:
> Hi all,
> 
> I'm looking for information about doing more complex YANG extensions
> that the basic <name,value> type, e.g.:
> oc-ext:openconfig-version "2.5.0";

See https://github.com/netmod-wg/yang-next/issues/54 for a discussion
about one approach.



/martin






> 
> The node-tags approach doesn't fit what I'm trying to do (tags can't
> have values).
> 
> RFC7950 says the following:
>    The substatements of an
>    extension are defined by the "extension" statement, using some
>    mechanism outside the scope of this specification.  Syntactically,
>    the substatements MUST be YANG statements, including extensions
>    defined using "extension" statements.
> 
> Let me start with a simple example and build on it. Say I want to
> associate a color with any schema node. That's easy:
> 
>     extension color {
>         argument "color";
>         description "Takes a value of red, green or blue";
>     }
> 
>     leaf foo {
>         myext:color "red";
>     }
> 
> But what if I want a more complex structure for my color metadata like
> this?  (a leaf-list and leaf inside a container)
> 
>     leaf foo {
>         myext:chroma-metadata {
>             myext:colors "red green";
>             myext:saturation "45";
>         }
> 
> >From what I can tell, I'd have to define it like this:
> 
>     extension chroma-metadata {
>     }
>     extension colors {
>         argument "color-list";
>         description "sub-statement of chroma-metadata. Space separated list of
>         colors red, green and blue.";
>     }
>     extension saturation {
>         argument "saturation-level";
>         description "sub-statement of chroma-metadata";
>     }
> 
> Or if I wanted a list like this?
> 
>     myext:chroma-metadata {
>         myext:color "red" {
>             myext:saturation "45";
>         }
>         myext:color "green" {
>             myext:saturation "23";
>         }
>     }
> 
> I don't think there is any formal way to do it, but could I say that
> the structure of the chroma-metadata follows a grouping I define?
> 
>     grouping cm-struct {
>         list color {
>             leaf saturation { ... }
>         }
>     }
> 
> Could another option be to just define the top level extension
> chroma-metadata with a single argument, and then describe that the
> argument itself is a json-ietf blob of instance data that conforms to
> YANG grouping xyz?
> 
> Jason (he/him)
> 

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

Reply via email to