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
Status: https://datatracker.ietf.org/doc/draft-srivastav-netmod-formulae/
Htmlized: https://tools.ietf.org/html/draft-srivastav-netmod-formulae-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-srivastav-netmod-formulae-00
Regards
Sudhanshu
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
