Re: Netconf Event: Issue #1: To RCP or Not to RPC

[Andy Bierman <ietf@andybierman.com>]

Sharon Chisholm wrote:

> hi
>
> As Juergen suggested, I'm going to start off pros/cons list of having
> something at the RCP-layer in the Netconf Notification Solution. My list
> on each side is shorter than I was hoping, but it hopefully can start
> things off for us.
>
> In short though, once you have the Netconf Layers diagrammed engrained
> in your head, honouring these layers by having an rpc-layer wrapper
> seems to be the simplest solution. Removing it seems more like an
> optimization that says well, this new wrapper only can contain one type
> of operation, so why have it? I see the efficiency in removing it, but
> think we need to be careful about future proofing the architecture.
>
> Note that I've always viewed the term <rpc> as a bit of a misnomer since
> the Netconf RPC isn't really a traditional RPC. I suspect that perhaps
> some of the disconnect on this issue might lie in how much one treats
> <rpc> like an XML tag and how much one treats it like a traditional RPC.
>
> Pros
> ----
> 1) Other netconf operations are wrapped in something in the RPC-layer.
> It seems cleanest to also wrap the <notifications> in this layer. (Ease
> of understanding, ease of processing, etc)
>
>  

This is where we really disagree.
IMO, a notification is not an operation.
You are not executing an operation on the remote peer.
You are simply notifying the remote peer of something.

In my code anyway, the <rpc> node is processed in the
same manner for all RPC methods.  If I had to look ahead
to see if this <rpc> was really some kind of special notification
instead, this will complicate processing, not simplify it.

> Cons
> ----
> 1) If there is only one type of asynchronous message, then we can save
> some bits on the wire, but only having one wrapper instead of two.
>
>  

I think this pros and cons list is really missing the point, and masks
some important decisions the WG has to make:

1) Are we standardizing notifications based on syslog, or creating
   something entirely different?

2) How should our design deal with unspecified, unknown,
   future extensions to the initial document?

> Sharon Chisholm
> Nortel 
> Ottawa, Ontario
> Canada
>  

Andy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>