On Fri, Jul 1, 2016 at 6:21 AM, Vinod Kumar <[email protected]> wrote:
> 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. > > I read your drafts as well. I strongly disagree that we need standard annotations for something as implementation-specific as code generation. This is way out of scope for the IETF. > Looking forward for your opinion/feedback. > > Thanks and Regards, > Vinod Kumar S. > Andy > > 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 > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
