Dear Martin,
Thanks for your valuable comments.
Initially we also wanted to define them as individual extensions and
use them in the YANG file as indicated by you.
Below are some reasons, which compelled us to add them as a separate
annotations(metadata) in YANG file.
- These extensions are not required while defining the schema, it is
only required while implementing a schema in a server or client. It is used
by applications to instruct the YANG utilities or compilers to automate the
application development related to data organization / processing.
- These extension are of internal scope, and should be masked while
server advertises its schema resources.
- These extension values for a given YANG file may not match in server
and client.
We felt that annotating is a good option, similar to other languages
where-in by looking at annotation itself utilities/compilers can perform
additional functionality as instructed.
As you have pointed out, it is not a valid YANG 1.0, so we can modify
it as extensions to be compatible.
We feel that annotation (compiler) support in YANG is an important
requirement which needs to be standardized for all compiler implementation,
hence we believe there is a need to incorporate annotations in YANG 2.0.
Looking forward for your opinion/feedback.
Thanks and Regards,
Vinod Kumar S.
On Fri, Jul 1, 2016 at 2:10 PM, Martin Bjorklund <[email protected]> wrote:
> "vinods.kumar" <[email protected]> wrote:
> > Dear All,
> >
> > We have written a draft, to add annotation in YANG definition which
> can
> > be used by the YANG compilers.
> >
> > We are implementing these drafts as a reference implementation in the
> IETF
> > 96 hackathon on ONOS YANG utilities.
> >
> > Request you to review the below drafts and provide your
> comments/feedback.
> >
> > Draft(s):
> >
> https://datatracker.ietf.org/doc/draft-agv-netmod-yang-compiler-metadata/
> >
> >
> >
> https://datatracker.ietf.org/doc/draft-agv-netmod-yang-annotation-ds-and-der
> > ived/
>
> I have looked at these drafts. I have two high-level comments.
>
> 1) What you propose is not valid YANG. This new syntax would
> require a new version of the YANG language.
>
> 2) What you propose is not necessary; it can be done (and is being
> done in several existing implementations) with current YANG
> syntax and semantics, with normal YANG extension statements.
>
> For example, the draft proposes this:
>
> list server {
> ca:compiler-annotation{
> @MappedCollection(collection-type='map', map-key='name')
> @OverrideImpl('DefaultServer');
> }
> ...
>
> It can be done today as:
>
> list server {
> xx:mapped-collection {
> xx:collection-type map;
> xx:map-key name;
> }
> xx:override-impl DefaultServer;
> ...
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
