Re: [netmod] structured metadata for schema nodes using YANG extensions

["Jason Sterne (Nokia)" <[e-mail]>]

Thanks Martin.

I can see how that approach can be used to create a structure of containers and leafs (where each leaf could have a type). So that's helpful for some scenarios.

I'm not sure how to deal with leaf-lists or lists though.

If we wanted a leaf-list like this:
	myext:colors "red green"
it isn't obvious to me how to extend the approaches in yang-next issue 54 to specify it. I'm also not sure how to specify the format of the "instance data" in the leaf-list or if there is any sort of "right" format for that. In my example I show space separated names (any separator may need escape mechanisms).

Similarly I'm not sure how a list could work. In theory extension "saturation" could be a substatement of extension "color" and then "color" could have an argument. That could act as a sort of list:

extension color {
    argument "color-name";
}
extension saturation {
    argument "saturation-level";
    tailf:use-in "myext:color";
}

Leaf foo {
    myext:color "red" {
        saturation "45";
    }
    myext:color "blue" {
        saturation "12";
    }

Maybe another approach is to somehow allow full RFC 9195 instance data to be the argument of an extension, and then also have some way to define the data model of that instance data as part of the extension definition.

Jason

> -----Original Message-----
> From: Martin Björklund <[e-mail]>
> Sent: Wednesday, March 13, 2024 5:08 AM
> To: Jason Sterne (Nokia) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [netmod] structured metadata for schema nodes using YANG
> extensions
> 
> 
> CAUTION: This is an external email. Please be very careful when clicking links or
> opening attachments. See the URL nok.it/ext for additional information.
> 
> 
> 
> "Jason Sterne \(Nokia\)" <jason.sterne=[e-mail]> 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)
> >