RE: netconf notification transport issues

["Hector Trevino \(htrevino\)" <htrevino@cisco.com>]

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Thursday, January 26, 2006 9:27 AM
> To: Netconf (E-mail)
> Subject: netconf notification transport issues
> 
> Hi,
> 
> Phil brought up some transport issues again, that I think we 
> should find out some opinions, one way or the other.
> 
> 1) Multi-use session
> 
>    Is it important that a manager be able to issue <rpc> calls and
>    receive <notification> messages within the same session?
> 
>    The other option (Single-use session) implies that the manager
>    will establish multiple single purpose sessions instead.
> 
>    As Phil pointed out, if single-use is okay, then the manager can
>    simply make a 'start-receiving-notifications' RPC call that
>    never finishes (usually until the manager shuts down the session).

HT: I think that both of the options above should be supported. The
client
should be allowed to decide whether to setup multiple dedicated sessions
or
a multi-purpose one. By doing this you are providing the same (similar)
capabilities over communication protocols with different properties
(e.g. BEEP, SSH). 

BTW, since Andy likes implementations... this is what we chose to do. 

> 
> 
> 2) Multiple channels and Multiple Connections
> 
>    Should we try to bring back this concept?
HT: Yes - unless people think that BEEP is not going anywhere. Maybe we
should find out
who is implementing/using BEEP. 
>    Wasn't this the main reason we picked BEEP in the first place?
HT: AFAIK yes. 
>    Is the BEEP mapping that relevant without it?
HT: I don't think so
>    This issue is only relevant if multi-use sessions are required.
> 
> 
> 3) Application Acks and Reverse RPCs
> 
>    As Phil and I pointed out in emails, a notification with an
>    application-ack is really just another <rpc> method, but
>    from the agent to the manager.  It might be simpler to define
>    how to reverse the flow for notification purposes, rather
>    than redefining the <rpc> and <rpc-reply> elements.
> 
>    Should this feature be dropped, capability-based, or mandatory?
HT: I think it should be kept but made capability-based. This will allow
vendors to
support the capability based on demands. 

>    If kept, how should it be done?
HT: This goes back to the previous discussion on one-way-msg. 1)
Choosing to add a new message
<one-way-whatever> (unack'd) and re-using the <rpc> <rpc-reply> (ack'd)
preserves the message structure 
(i.e. the info in the <rpc>), also preserves the protocol stack, but
semantics (reply or no reply) are in
the rpc layer only.  

2) If the rpc layer is removed then the semantics (reply/no reply) are
put into the message itself as well as any other information previously
under the rpc portion of the message. 

The third option and I think this is what you suggested before is to
maintain the <rpc> <rpc-reply> put the 
notification semantics in the message itself and have the extra message
exchange. 

If <rpc> with no reply is allowed then I'd go w/ #3. The extra message
is ok for people wanting confirmed notifications
Otherwise it is a toss up between #1 and #2.   


> 
> 
> 4) Any More Transport Issues??
> 
> 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/>
> 

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