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 protected]> wrote:
>
>
> On Fri, Jul 1, 2016 at 4:10 PM, Randy Presuhn <
> [email protected]> 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: "[email protected]" , "Anil Kumar S N (VRP Network BL)" ,
>> Gaurav Agarwal , [email protected]
>>
>> 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 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
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
