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

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

Ok thx. Appreciate the pointer and the ideas.
Jason

> -----Original Message-----
> From: Martin Björklund <[e-mail]>
> Sent: Thursday, March 14, 2024 4:26 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)" <[e-mail]> wrote:
> > 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).
> 
> A "leaf-list" would be:
> 
>   myext:color "red";
>   myext:color "green";
> 
> It could be specified as:
> 
>   extension color {
>     argument color-name {
>       tailf:arg-type {
>         type enumeration {
>           enum red;
>           enum green;
>         }
>       }
>     }
>     tailf:occurence "*";
>   }
> 
> 
> 
> >
> > 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:
> 
> Yes.
> 
> But the approach we took was to be able to specify a grammar for
> extension statements so that they could express what ordinary YANG can
> do, rather than having a way to add "instance data" to a module.
> 
> 
> /martin
> 
> 
> 
> >
> > 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)
> > > >