Re: [netmod] structured metadata for schema nodes using YANG extensions
Ok thx. Appreciate the pointer and the ideas.
Jason
> -Original Message-
> From: Martin Björklund
> Sent: Thursday, March 14, 2024 4:26 AM
> To: Jason Sterne (Nokia)
> Cc: netmod@ietf.org
> 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)" 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
> > > Sent: Wednesday, March 13, 2024 5:08 AM
> > > To: Jason Sterne (Nokia)
> > > Cc: netmod@ietf.org
> > > 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\)" wrote:
> > > > Hi all,
> > > >
> > > > I'm looking for information about doing more complex YANG extensions
> > > > that the basic 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 a
Re: [netmod] structured metadata for schema nodes using YANG extensions
"Jason Sterne (Nokia)" 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
> > Sent: Wednesday, March 13, 2024 5:08 AM
> > To: Jason Sterne (Nokia)
> > Cc: netmod@ietf.org
> > 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\)" wrote:
> > > Hi all,
> > >
> > > I'm looking for information about doing more complex YANG extensions
> > > that the basic 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 "
Re: [netmod] structured metadata for schema nodes using YANG extensions
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
> Sent: Wednesday, March 13, 2024 5:08 AM
> To: Jason Sterne (Nokia)
> Cc: netmod@ietf.org
> 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\)" wrote:
> > Hi all,
> >
> > I'm looking for information about doing more complex YANG extensions
> > that the basic 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] structured metadata for schema nodes using YANG extensions
"Jason Sterne \(Nokia\)" wrote:
> Hi all,
>
> I'm looking for information about doing more complex YANG extensions
> that the basic 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
[netmod] structured metadata for schema nodes using YANG extensions
Hi all,
I'm looking for information about doing more complex YANG extensions that the
basic 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
