Subject: Re: [Netconf] RESTCONF #21: operation input output encoding

From: Kent Watsen <[email-masked]>
Date: Mon, 4 May 2015 21:19:10 +0000

>A new RESTCONF issue has been added:
>
>https://github.com/netconf-wg/restconf/issues/21
>
>This issue proposes to change the encoding of operation
>input and output parameters:
>
>  - change "input" tp rpc name
>  - change "output" to rpc-name
>
>If there are no objections by May 7, then this
>change will be added to the next draft (-05).

Hi Andy, 

I don't agree to this, at least not without discussion.

We (Martin, you, and myself) discussed this (and action statements)
privately on Mar 31 and again on Apr 9/10 - a total of 26 messages, where
we landed on sticking with the input/output top-level elements - what's
changed?   Given that the current encoding has been with us since the
beginning, changing it now needs to be done with care.

Personally, I find the input/output elements more useful, as already the
URL encodes the name of the RPC - having the RPC's name again in the body
of the message seems redundant, whereas input/output provides context.
Additionally, keep in mind that, with action statements, there can be many
actions with the same name.  For this reason, it's never possible to
process an input or output message body without context (e.g., pyang would
have to have a parameter indicated *which* action statement to assume).
Is your motivation for this change to enable contextless processing?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 4 May 2015 14:34:56 -0700

> Is your motivation for this change to enable contextless processing?

The problem is that all RPCs from the same module look the same
and there is no way to associate the data with the operation other
than knowing the request URI that goes with the data

   <reset> .... </reset>

   <get-reset-info>  ...  </get-reset-info>

OR

   <input>  ... </input>

   <input>  ... </input>

The <rpc-name> is what we do in NETCONF.
RESTCONF is supposed to be consistent with NETCONF unless there
is a good reason to do otherwise.

> Kent

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 May 2015 11:46:41 -0700

Hi,

There has not been any discussion on this issue
so I guess we should leave the operation encoding
unchanged.

Andy