Re: [netmod] FW: RE: Re: draft-srivastav-netmod-formulae-00

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 29 September 2017 13:10 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 B5E1013451E for <netmod@ietfa.amsl.com>; Fri, 29 Sep 2017 06:10:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 M-aQS87ogHat for <netmod@ietfa.amsl.com>; Fri, 29 Sep 2017 06:10:38 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3838E134528 for <netmod@ietf.org>; Fri, 29 Sep 2017 06:10:38 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0ED026AE; Fri, 29 Sep 2017 15:10:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Bic_R14artg6; Fri, 29 Sep 2017 15:10:33 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Sep 2017 15:10:36 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC9B3200F6; Fri, 29 Sep 2017 15:10:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id phCUgAgvWpWw; Fri, 29 Sep 2017 15:10:35 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0A53200F4; Fri, 29 Sep 2017 15:10:34 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C065D411B4C9; Fri, 29 Sep 2017 15:10:34 +0200 (CEST)
Date: Fri, 29 Sep 2017 15:10:34 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Sudhanshu Kumar Srivastav <sk.srivastav@samsung.com>
Cc: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>, KARTHIKEYAN SUBRAMANIAM <karthikeyan.s@samsung.com>, Surendra Pal Sharma <s.p.sharma@samsung.com>, "cpgs ." <cpgs@samsung.com>
Message-ID: <20170929131034.cpgjck7e2umt4zoe@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Sudhanshu Kumar Srivastav <sk.srivastav@samsung.com>, Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>, KARTHIKEYAN SUBRAMANIAM <karthikeyan.s@samsung.com>, Surendra Pal Sharma <s.p.sharma@samsung.com>, "cpgs ." <cpgs@samsung.com>
References: <20170915142859epcms5p526b9d21b55ddd8f0eb13edfec62efcff@epcms5p5> <c3199b8d-b90a-e1e7-2930-6ed47d823286@cisco.com> <20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106@epcms5p3> <CGME20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106@epcms5p1> <20170929125754epcms5p130f941babd487e94f81407ee2139d6c1@epcms5p1>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170929125754epcms5p130f941babd487e94f81407ee2139d6c1@epcms5p1>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/luTHK1WSSamZtzL0NMmDFXYk_g8>
Subject: Re: [netmod] FW: RE: Re: draft-srivastav-netmod-formulae-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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, 29 Sep 2017 13:10:41 -0000

Dear Sudhanshu,

I share Robert's concerns. Hard coding expressions in a syntax tree
format in a schema is hardly readable and highly inflexible. Note that
there has been prior work like this in different contexts and one
thing you entirely ignore is that management data is not static;
counter leaf values have no meaning unless you compute a delta over a
time period etc.

You also seem to confuse basic concepts, i.e., protocols like NETCONF
do not parse schema definitions. So why would NETCONF need
enhancements? It should be a design goal to not require protocol
enhancements.

/js

On Fri, Sep 29, 2017 at 12:57:54PM +0000, Sudhanshu Kumar Srivastav wrote:
>    Hi Robert,
> 
> 
> 
>    Please find response inline.
> 
> 
> 
>    1) In particular, rather than modeling the expression directly in YANG
>    using YANG extensions, which effectively makes the expression look like
>    quite a verbose abstract syntax tree, I think that you may be better off
>    defining a separate expression language, similar to how Xpath is used
>    today.  Probably it could be related to Xpath, perhaps it could be a
>    superset.
> 
>    [srivastav]    There is slight difference in suggested idea and
>    that is "Model the formula as schema, not as Data".
> 
> 
> 
>    2) I think that there are some questions about how these expressions would
>    get programmed into the device.  Are they statically included as part of
>    the schema loaded by the NETCONF/RESTCONF server?  Or are they programmed
>    dynamically via the NETCONF/RESTCONF client.  For the latter case it would
>    be necessary to either define new RPC operations, or perhaps better a
>    configuration and operational YANG data model to manage the expressions.
> 
>    [srivastav]  formulas are getting statically included at server and not
>    programmed dynamically.  The benefit of this is when formula changes, Just
>    schema need to be changed and updated at server and no change in server is
>    required.
> 
> 
> 
>    3) I think that it would also need to be considered whether the
>    constructed expression values are represented as new nodes in the YANG
>    schema (which would probably prevent them from be constructed
>    dynamically), or perhaps they should make use of YANG metadata (RFC 7952)
>    instead so that the base underlying schema isn't changed.
> 
>    [srivastav]  YANG metadata (RFC 7952) shall be used.
> 
>    4) Any solution should probably also consider how it would inter-operate
>    with the work currently being doing in NETCONF on YANG push and related
>    technologies.
>    [srivastav]  I don't foresee any inter-operability problem with YANG push
>    technology. Kindly let me know if you foresee any problem.
> 
>    5) They may be security implications of allowing a client to execute
>    arbitrarily complex expressions would may degrade the performance of the
>    system, although perhaps the memory and cpu available to execute the
>    expressions could be limited.
> 
>    [srivastav] Modeling formula as schema don't put this security
>    implications, as formula is not getting programmed dynamically.
> 
> 
> 
> 
> 
>    Kindly let me know how can I proceed further to this idea from
>    conceptualization to  realization in IETF forum.
> 
> 
> 
>    Regards
> 
>    Sudhanshu
> 
> 
> 
>    --------- Original Message ---------
> 
>    Sender : Sudhanshu Kumar Srivastav <sk.srivastav@samsung.com> Chief
>    Engineer/SRI-Bangalore-CU/Samsung Electronics
> 
>    Date : 2017-09-15 19:58 (GMT+5:30)
> 
>    Title : RE: Re: [netmod] draft-srivastav-netmod-formulae-00
> 
>    To : null<rwilton@cisco.com>om>, null<netmod@ietf.org>
> 
>    CC : KARTHIKEYAN SUBRAMANIAM<karthikeyan.s@samsung.com>om>, cpgs
>    .<cpgs@samsung.com>om>, Surendra Pal Sharma<s.p.sharma@samsung.com>
> 
> 
> 
>    Dear  Robert,
> 
> 
> 
>       Thanks a lot for your feedback. It gave me other key areas to be
>    considered which can be impacted due to the suggested idea.
> 
> 
> 
>       With respect to first feedback, I think there is slight difference
>    in suggested idea and that is "Model the formula as schema, not as
>    Data".  So it's getting statically included at server and not programmed
>    dynamically.
> 
>       As I think "Modeling formula" as Data may have security implications.
> 
> 
> 
>       I am going through the feedbacks provided in details, I will check and
>    come back to this.
> 
> 
> 
>    Regards
> 
>    Sudhanshu
> 
> 
> 
>    --------- Original Message ---------
> 
>    Sender : Robert Wilton <rwilton@cisco.com>
> 
>    Date : 2017-09-13 15:11 (GMT+5:30)
> 
>    Title : Re: [netmod] draft-srivastav-netmod-formulae-00
> 
>    To : Sudhanshu Kumar Srivastav<sk.srivastav@samsung.com>om>,
>    null<netmod@ietf.org>
> 
>    CC : KARTHIKEYAN SUBRAMANIAM<karthikeyan.s@samsung.com>om>, cpgs
>    .<cpgs@samsung.com>
> 
> 
> 
>    Hi Sudhanshu,
> 
>    Thanks for posting this.
> 
>    The premise of what you are trying to achieve here is interesting.  My
>    interpretation is that your idea is to allow a NETCONF/RESTCONF
>    server/device to take existing data in the operational state data tree and
>    to construct new derived data (or perhaps just metadata) by executing a
>    client defined algorithm that is described via extensions statements to
>    YANG.
> 
>    This broadly seems a reasonable idea to me, but I'm not sure that I would
>    implement it in quite the same way, and I've put forward some other points
>    or issues that you may want to consider.
> 
>    1) In particular, rather than modeling the expression directly in YANG
>    using YANG extensions, which effectively makes the expression look like
>    quite a verbose abstract syntax tree, I think that you may be better off
>    defining a separate expression language, similar to how Xpath is used
>    today.  Probably it could be related to Xpath, perhaps it could be a
>    superset.
> 
>    E.g .to take your example in 3.10, I think that it would be better if the
>    expression was written more like a normal mathematical expression.  E.g. I
>    think that the following would be easier to read/understand.  Obviously an
>    implementation needs to parse the expression, but that shouldn't be too
>    difficult, and they would need to write code to interpret the expression
>    anyway.
> 
>     container formula {
>        leaf a {
>           type int32;
>        }
>        ... leaves b to d defined similarly ...
>        leaf e {
>           type int32;
>        }
>        mt:math x {
>          leaf x {
>            type int32;
>            mt:expression"((a+b) - (c-d)/(e*100))";
>          }
>        }
> 
>    2) I think that there are some questions about how these expressions would
>    get programmed into the device.  Are they statically included as part of
>    the schema loaded by the NETCONF/RESTCONF server?  Or are they programmed
>    dynamically via the NETCONF/RESTCONF client.  For the latter case it would
>    be necessary to either define new RPC operations, or perhaps better a
>    configuration and operational YANG data model to manage the expressions.
> 
>    3) I think that it would also need to be considered whether the
>    constructed expression values are represented as new nodes in the YANG
>    schema (which would probably prevent them from be constructed
>    dynamically), or perhaps they should make use of YANG metadata (RFC 7952)
>    instead so that the base underlying schema isn't changed.
> 
>    4) Any solution should probably also consider how it would inter-operate
>    with the work currently being doing in NETCONF on YANG push and related
>    technologies.
> 
>    5) They may be security implications of allowing a client to execute
>    arbitrarily complex expressions would may degrade the performance of the
>    system, although perhaps the memory and cpu available to execute the
>    expressions could be limited.
> 
>    I hope the brief feedback is useful.  I'm not sure how familiar you are
>    with the IETF process, but please note that these comments just represent
>    my personal opinion and do not necessarily reflect those of the wider
>    participants in the NETMOD WG. Other opinions may, and in my experience
>    probably will, differ :-)
> 
>    Thanks,
>    Rob
> 
>    On 13/09/2017 08:30, Sudhanshu Kumar Srivastav wrote:
> 
>      Dear NETMOD Team,
> 
> 
> 
>        I have submitted a draft for new YANG module that defines new YANG
>      extension statements and method to model the formulae/KPI's.
> 
>        Request you to please check and provide your comments.
> 
> 
> 
>      Draft Details:
> 
>      Name: draft-srivastav-netmod-formulae
>      Revision: 00
>      Title: YANG extension Statements for formulae modeling
>      Document date: 2017-09-12
>      Group: Individual Submission
>      Pages: 28
>      URL:
>      [1]https://www.ietf.org/internet-drafts/draft-srivastav-netmod-formulae-00.txt
>      Status:
>      [2]https://datatracker.ietf.org/doc/draft-srivastav-netmod-formulae/
>      Htmlized:
>      [3]https://tools.ietf.org/html/draft-srivastav-netmod-formulae-00
>      Htmlized:
>      [4]https://datatracker.ietf.org/doc/html/draft-srivastav-netmod-formulae-00
> 
> 
> 
>      Regards
> 
>      Sudhanshu
> 
>  _______________________________________________
>  netmod mailing list
>  [5]netmod@ietf.org
>  [6]https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> 
> References
> 
>    Visible links
>    1. https://www.ietf.org/internet-drafts/draft-srivastav-netmod-formulae-00.txt
>    2. https://datatracker.ietf.org/doc/draft-srivastav-netmod-formulae/
>    3. https://tools.ietf.org/html/draft-srivastav-netmod-formulae-00
>    4. https://datatracker.ietf.org/doc/html/draft-srivastav-netmod-formulae-00
>    5. mailto:netmod@ietf.org
>    6. https://www.ietf.org/mailman/listinfo/netmod



> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


-- 
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/>