Subject: Re: [netmod] Request to review the YANG compiler annotations draft.

From: Martin Bjorklund <[email-masked]>
Date: Fri, 01 Jul 2016 10:40:34 +0200 (CEST)

"vinods.kumar" <[email-masked]> 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

---

From: Vinod Kumar <[email-masked]>
Date: Fri, 1 Jul 2016 18:51:22 +0530

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-masked]> wrote:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 1 Jul 2016 07:26:23 -0700

> 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.

Andy

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 05 Jul 2016 21:38:41 -0400

>       require a new version of the YANG language.

I must vigorously agree with the other commentators that if the
annotations are permitted to be in-line in a Yang module, then you must
develop a syntax that is valid Yang.  Otherwise, an annotated Yang file
isn't processable by an arbitrary Yang processor, it is bound to a
special processor, and isn't really a Yang file at all.

If the concept of more-or-less implementation independent annotations is
adopted, it seems to be best to put it conceptually in the framework by
which one Yang module extends another module.

Dale