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

From: Randy Presuhn <[email-masked]>
Date: Fri, 1 Jul 2016 16:10:26 -0700 (GMT-07:00)

Hi -

Some lessons learned from annotating SMI files for code generation
are probably applicable here.
   (1) doing annotations "in-line", regardless of the grammatical
       tricks used to support those annotations, is problematic
       from a software configuration management perspective.
         (a) as new versions of the module definition appear,
             it becomes necessary to "re-apply" annotations.
             This is particularly a nuisance when different
             organizations are involved.
         (b) when the same module needs to be annotated in
             different ways for different purposes, as when used
             in multiple products built using different development
             environments.

   (2) As others have already mentioned, working within the
       language framework for annotation syntax is a big win
       *if* you're doing annotations in-line, but see (1).

Randy

-----Original Message-----

From: Vinod Kumar 

Sent: Jul 1, 2016 6:21 AM

To: Martin Bjorklund 

Cc: "[email-masked]" , "Anil Kumar S N (VRP Network BL)" , Gaurav Agarwal , [email-masked]

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

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:
"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

_______________________________________________

netmod mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Fri, 1 Jul 2016 16:53:29 -0700

>              in multiple products built using different development

This is why commercial SDKs support separate annotations,
deviations, and module/submodule files.  Ideally the module sources are
common across all platforms, but annotations and deviations can be platform
and revision specific.

I understand the need for standard extensions like nacm:default-deny-all
that are tied to a standard module, but not tool-specific annotations.

>        *if* you're doing annotations in-line, but see (1).
YANG allows either inline or separate module (sort of)

Side issue...

We use the deviation statement to patch in extensions same as other
deviations.
That's why I do not like all the text in 7.20.3 about deviating from the
standard and
'server does not implement faithfully'.

https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-14#section-7.20.3

The ABNF allows the following, so the RFC text is wrong:

   deviation /if:interfaces/if:interface {
       deviate add {
            ncx:sil-delete-children-first;
        }
    }

This does not alter the conformance requirements at all.

> Randy

Andy

>     Initially we also wanted to define them as individual extensions and
> use them in the YANG file as indicated by you.
>     - 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.
>    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.

---

From: Vinod Kumar <[email-masked]>
Date: Mon, 4 Jul 2016 14:49:26 +0530

Dear All,

Thanks to all of you for your review and valuable suggestions/comments.

We would like to bring some more points to give you more information about
the background of requirement and purpose.

*Background*
We are handling YANG Utilities (YANG compiler) in ONOS which automates
application development using YANG. Here we see a gap wherein YANG doesn't
support data organization as required by application. Hence we see a
requirement for YANG to support different flavors of data organization.

*Need for Standard*
We wanted to address this gap, in a standardized way, so that it is NOT
compiler / tools specific. This enables applications to be portable across
platforms, for example, applications can be portable across controllers
(like ONOS / ODL) without any additional effort with respect to data
organization.

*Views on received suggestions/comments*
We accept the mechanism of decorating YANG modules/submodules with
annotations is NOT a correct approach, as pointed out, there are
maintenance issues.
As suggested, we can choose one of the alternative which defines the
annotations in separate module/sub-module. For Example: similar to augment,
we can use the compiler-annotation extension to have an argument, which
identifies the target node which is being annotated.

ca:compiler-annotation /candidate-servers/server{
  ca:app-data-structure{
    ca:data-structure="map";
    ca:key="name";
  }
  ca:app-derived{
    ca:extended-name="special-server";
  }
}

Kindly let us know your opinion/feedback on the same.

Thanks and Regards,

Vinod Kumar S.

On Sat, Jul 2, 2016 at 5:23 AM, Andy Bierman <[email-masked]> wrote:

>
>
> On Fri, Jul 1, 2016 at 4:10 PM, Randy Presuhn <
> [email-masked]> wrote:
>
>> Hi -
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 4 Jul 2016 11:27:38 +0200

> (like ONOS / ODL) without any additional effort with respect to data

Data organization is highly implementation specific and even more so
if you accept that not all implementations are written in Java. And as
Andy said, the IETF has a tradition to not standardize APIs.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Jan Lindblad <[email-masked]>
Date: Mon, 4 Jul 2016 11:41:04 +0200

Vinod,

I would think that different implementations would want to choose their own values for the implementation details below, so this sort of information should definitely not be part of the standard YANG modules. Being able to provide this sort of information as annotations in YANG, however, is often very useful. Many projects do.

The standard YANG extension keyword already allows this practice, so if you just replace the equals sign below "=" with space " ", this would already be valid YANG and presumably useful for your implementation, assuming you declare your extensions properly.

I don't see any need to change or extend YANG for your use case.

/jan

> Views on received suggestions/comments
> We accept the mechanism of decorating YANG modules/submodules with annotations is NOT a correct approach, as pointed out, there are maintenance issues.
> As suggested, we can choose one of the alternative which defines the annotations in separate module/sub-module. For Example: similar to augment, we can use the compiler-annotation extension to have an argument, which identifies the target node which is being annotated.

--
Jan Lindblad, [email-masked], +46 702855728
Solutions Architect/Business Development, Tail-f
Tail-f is now a part of Cisco