RE: netconf notification transport issues

["Sharon Chisholm" <schishol@nortel.com>]

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