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

[Vinod Kumar <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> On Fri, Jul 1, 2016 at 4:10 PM, Randy Presuhn <
> [e-mail]> wrote:
>
>> 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.
>>
>>
>
> 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.
>
>
>    (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).
>>
>>
> 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
>
>
>>
>> -----Original Message-----
>>
>> From: Vinod Kumar
>>
>> Sent: Jul 1, 2016 6:21 AM
>>
>> To: Martin Bjorklund
>>
>> Cc: "[e-mail]" , "Anil Kumar S N (VRP Network BL)" ,
>> Gaurav Agarwal , [e-mail]
>>
>> 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 <[e-mail]> wrote:
>> "vinods.kumar" <[e-mail]> 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
>>
>> [e-mail]
>>
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>
>