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

Sudhanshu Kumar Srivastav <sk.srivastav@samsung.com> Fri, 29 September 2017 12:58 UTC

Return-Path: <sk.srivastav@samsung.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 4A71713452F for <netmod@ietfa.amsl.com>; Fri, 29 Sep 2017 05:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.695
X-Spam-Level:
X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[BASE64_LENGTH_79_INF=1.502, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 OQYpn6uy4vXR for <netmod@ietfa.amsl.com>; Fri, 29 Sep 2017 05:57:58 -0700 (PDT)
Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F15A134525 for <netmod@ietf.org>; Fri, 29 Sep 2017 05:57:57 -0700 (PDT)
Received: from epcas5p4.samsung.com (unknown [182.195.41.42]) by mailout1.samsung.com (KnoxPortal) with ESMTP id 20170929125755epoutp01efa766b78b5caad65042cf42a70aa209~o1nV1NOgI0808508085epoutp01w for <netmod@ietf.org>; Fri, 29 Sep 2017 12:57:55 +0000 (GMT)
Received: from epsmges5p1new.samsung.com (unknown [182.195.42.73]) by epcas5p3.samsung.com (KnoxPortal) with ESMTP id 20170929125754epcas5p3f9c3e10ee1bcd42172b88c49e740e39a~o1nVWTu4t2286822868epcas5p31; Fri, 29 Sep 2017 12:57:54 +0000 (GMT)
X-AuditID: b6c32a49-99fff7000000104d-4e-59ce43529384
Received: from epcas5p2.samsung.com ( [182.195.41.40]) by epsmges5p1new.samsung.com (Symantec Messaging Gateway) with SMTP id 34.F0.04173.2534EC95; Fri, 29 Sep 2017 21:57:54 +0900 (KST)
Mime-Version: 1.0
Reply-To: sk.srivastav@samsung.com
Sender: Sudhanshu Kumar Srivastav <sk.srivastav@samsung.com>
From: Sudhanshu Kumar Srivastav <sk.srivastav@samsung.com>
To: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
CC: KARTHIKEYAN SUBRAMANIAM <karthikeyan.s@samsung.com>, "cpgs ." <cpgs@samsung.com>, Surendra Pal Sharma <s.p.sharma@samsung.com>
X-Priority: 3
X-Content-Kind-Code: NORMAL
In-Reply-To: <20170915142859epcms5p526b9d21b55ddd8f0eb13edfec62efcff@epcms5p5>
X-Drm-Type: N,general
X-EPLocale: en_US.EUC-KR
X-EPWebmail-Msg-Type: personal
X-Msg-Generator: Mail
X-Msg-Type: PERSONAL
X-Reply-Demand: N
X-Sender: =?utf-8?B?U2Ftc3VuZyBFbGVjdHJvbmljcxtTUkktQg==?= =?utf-8?B?YW5nYWxvcmUtQ1UbQ2hpZWYgRW5naW5lZXI=?=
X-Sender-IP: 107.110.12.116
X-Local-Sender: =?UTF-8?B?U3VkaGFuc2h1IEt1bWFyIFNyaXZhc3RhdhtTUkktQmFuZ2Fsb3JlLUNV?= =?UTF-8?B?G+yCvOyEseyghOyekBtDaGllZiBFbmdpbmVlcg==?=
X-Global-Sender: =?UTF-8?B?U3VkaGFuc2h1IEt1bWFyIFNyaXZhc3RhdhtTUkktQmFuZ2Fsb3JlLUNV?= =?UTF-8?B?G1NhbXN1bmcgRWxlY3Ryb25pY3MbQ2hpZWYgRW5naW5lZXI=?=
X-Sender-Code: =?UTF-8?B?QzEwGxtDMTBJRDAxSUQwMTA5MTU=?=
Message-ID: <20170929125754epcms5p130f941babd487e94f81407ee2139d6c1@epcms5p1>
Date: Fri, 29 Sep 2017 12:57:54 +0000
X-CMS-MailID: 20170929125754epcms5p130f941babd487e94f81407ee2139d6c1
Content-Type: multipart/related; boundary="=_NamoWEC-ud1bd2lido"
X-CPGSPASS: Y
X-MTR: 20170929125754epcms5p130f941babd487e94f81407ee2139d6c1
CMS-TYPE: 105P
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsWy7bCmhm6Q87lIg8k3NC1eHtK0WDDpB7PF /IuNrBYnzvUxW/z8v4PdgdVjyu+NrB5Llvxk8ujbsooxgDmKyyYlNSezLLVI3y6BK+PJlEus BecXMlW8vf6RpYFx2lymLkZODgkBE4nPD5ezdzFycQgJ7GaU+LaghaWLkYODV0BQ4u8OYZAa YQEHicVPjzKD2EICShKNK3pZIOI2Eoe+H2MFsdkErCSe9J8Hs0UEvCRWn7nDAjKTWaCFUWLb p6tsEMt4JWa0P2WBsKUlti/fyghicwr4SUyc2cgKEReVuLn6LTuELSGxeuFzqF45iWlf1zDD 1Lw/Np8RwhaRaL13FiouKPHg526oeK5Ex/52Zphdf/8dYQQ5SEKgm1Hi1ZVbUM4URon9J59A bTCXuNzfC9bNK+ArsfzAOnAQsQioSmz98gDqIheJze0bweqZgcGyrWcvC8xnDRt/Q9XYSsw9 fACqhk+i9/cTJpiaHfNgbDWJs3cesE1gVJ6FCOxZSKZC2IoSU7ofskPYGhKtc+ZC2eIS+6+0 MWOqUZc4tWcJ8wJG9lWMkqkFxbnpqcWmBYZ5qeV6xYm5xaV56XrJ+bmbGMGpSstzB+Oscz6H GAU4GJV4eA0Uz0YKsSaWFVfmHmKU4GBWEuEVdToXKcSbklhZlVqUH19UmpNafIhRmoNFSZz3 2M7SSCGB9MSS1OzU1ILUIpgsEwenVAOj/Cbm/tA6QWaLB3llTq8fqDeXtqbGbYgouSZREPi8 3ZrDr0E85vaCaYeMS3PCmPltJ79a+fpG6J/az5zXnR/02RxM90lhj+NbOVnTvPIqd7iaulXr JJ+7Ou+nPDl0hv0Hz2IG71dTH6VcrPEKmrGlbWH83G0Jt7NX5rm+W/4ktUBHcb6OwQYlluKM REMt5qLiRAAkcqR9UQMAAA==
X-CMS-RootMailID: 20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106
X-RootMTR: 20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106
References: <20170915142859epcms5p526b9d21b55ddd8f0eb13edfec62efcff@epcms5p5> <c3199b8d-b90a-e1e7-2930-6ed47d823286@cisco.com> <20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106@epcms5p3> <CGME20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106@epcms5p1>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ZxCbqWUetIvfk5xIGqRfTyW-KmI>
Subject: [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 12:58:01 -0000

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:           
https://www.ietf.org/internet-drafts/draft-srivastav-netmod-formulae-00.txt" rel="nofollow">https://www.ietf.org/internet-drafts/draft-srivastav-netmod-formulae-00.txt
Status:        
https://datatracker.ietf.org/doc/draft-srivastav-netmod-formulae/" rel="nofollow">https://datatracker.ietf.org/doc/draft-srivastav-netmod-formulae/
Htmlized:      
https://tools.ietf.org/html/draft-srivastav-netmod-formulae-00" rel="nofollow">https://tools.ietf.org/html/draft-srivastav-netmod-formulae-00
Htmlized:      
https://datatracker.ietf.org/doc/html/draft-srivastav-netmod-formulae-00" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-srivastav-netmod-formulae-00

 

Regards

Sudhanshu



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod" rel="nofollow">https://www.ietf.org/mailman/listinfo/netmod

 


http://ext.samsung.net/mail/ext/v1/external/status/update?userid=sk.srivastav&do=bWFpbElEPTIwMTcwOTI5MTI1NzU0ZXBjbXM1cDEzMGY5NDFiYWJkNDg3ZTk0ZjgxNDA3ZWUyMTM5ZDZjMSZyZWNpcGllbnRBZGRyZXNzPW5ldG1vZEBpZXRmLm9yZw__" border="0" width="0" height="0">