Subject: RE: netconf notification transport issues

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 26 Jan 2006 12:14:43 -0500

hi

<Andy>

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).

</Andy>

This is a design alternative that we (internal to my organization)
brought up and rejected early on in the design process. One disadvantage
is, as you have noted, you can't do synchronous and asynchronous
communication on the same connection and there are times you want to do
that. Also, you can't run more than one notification stream on the same
connection, and again there are times you want to do that (event replay
being a big one). Also,  questions were raised on the ability to process
as you go if the receiver is looking for a complete XML document. There
may have been other reasons this was rejected as well. I'll try and see
if we captured more reasoning.

<Andy>
2) Multiple channels and Multiple Connections

   Should we try to bring back this concept?
   Wasn't this the main reason we picked BEEP in the first place?
   Is the BEEP mapping that relevant without it?
   This issue is only relevant if multi-use sessions are required.
</Andy>

I think we eventually need to go there, but it can be decoupled from
this discussion. We can wait and tackle it later when it is clear that
we absolutely need it - ie, people are maxing out their connections and
need to multi-plex.

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

</Andy>
Yes, I said the same thing in my argument for why having the extra
wrapper around the notification was good future proofing. I'm not sure
it helps in the case of unacknowledged events.

<Andy>
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?
   If kept, how should it be done?
</Andy>

I don't see how it supports notifications, but I think Eliot wanted it
for call-home.

</Andy>
4) Any More Transport Issues??
</Andy>

From my perspective, the weakest part of the current draft is its
mappings to the application protocols. I would love to see some of the
people who wrote the application protocol mapping documents review those
sections.

Sharon

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

---

From: "Hector Trevino \(htrevino\)" <[email-masked]>
Date: Thu, 26 Jan 2006 10:25:27 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 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
> 

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. 

>    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
>    from the agent to the manager.  It might be simpler to define
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.   

> Andy
> to unsubscribe send a message to [email-masked] 
> with the word 'unsubscribe' in a single line as the message text body.