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";
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