Subject: [yang-doctors] defining new RPCs.

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 17 Aug 2016 11:59:26 +0200

Do we have an opinion on the suitability of
defining (many) new RPCs?

My personal thinking was that one can define new RPCs indeed,
but that we wouldprefer that not too many be defined?

Opinions?

Bert

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Aug 2016 12:17:08 +0200 (CEST)

> but that we wouldprefer that not too many be defined?

I think it depends what the RPC does.  Sometimes we see RPCs on the
form 'create-foo' or 'modify-foo' which modify the config.  Such RPCs
should not be allowed b/c we already have generic RPCs for this
(edit-config etc).  Also, often people tend to forget that there are
multiple datastores when they define such RPCs...

Another example is RPCs on the type 'get-foo'.  These should also in
most cases be avoided, since we already have the generic 'get'
operation for NETCONF anf GET for RESTCONF.

I suspect that if you see a module with many RPCs, quite a few of them
fall into the categories above, and might not be needed.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Aug 2016 12:19:23 +0200

> but that we wouldprefer that not too many be defined?

In my view, the main guideline is that newly defined RPCs should not
overlap with what can already be achieved with the basic protocol
primitives we have.

/js

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