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

On Fri, Jul 1, 2016 at 4:10 PM, Randy Presuhn <randy_presuhn@mindspring.com>
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: "vinods.kumar@huawei.com" , "Anil Kumar S N (VRP Network BL)" ,
> Gaurav Agarwal , netmod@ietf.org
>
> 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 <mbj@tail-f.com> wrote:
> "vinods.kumar" <vinods.kumar@huawei.com> 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
>
> netmod@ietf.org
>
> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>