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

Randy Presuhn <randy_presuhn@mindspring.com> Fri, 01 July 2016 23:10 UTC

Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5897512B046 for <netmod@ietfa.amsl.com>; Fri, 1 Jul 2016 16:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=randy_presuhn@mindspring.com header.d=mindspring.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpT_93zlqUJK for <netmod@ietfa.amsl.com>; Fri, 1 Jul 2016 16:10:37 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 46F0612D5AB for <netmod@ietf.org>; Fri, 1 Jul 2016 16:10:37 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=EAUZphLTkkfIJdSvYYEVAov8bn8F7ru1SbdRIVGmgOk5rk5CzZNNOg1lVeLt5UAN; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.39] (helo=elwamui-little.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1bJ7Zq-0007M4-LX for netmod@ietf.org; Fri, 01 Jul 2016 19:10:26 -0400
Received: from 76.254.53.186 by webmail.earthlink.net with HTTP; Fri, 1 Jul 2016 19:10:26 -0400
Message-ID: <25452548.1467414626550.JavaMail.wam@elwamui-little.atl.sa.earthlink.net>
Date: Fri, 01 Jul 2016 16:10:26 -0700
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b484d7840976cb7e37c151a92644a67446ff2814cc0b53a9350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.39
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/vkOg8EUN15ZnSBzQfJ6_Gb3DrUU>
Subject: Re: [netmod] Request to review the YANG compiler annotations draft.
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Randy Presuhn <randy_presuhn@mindspring.com>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2016 23:10:39 -0000

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