Subject: RE: requirement: agent initiated session support

From: "Hector Trevino \(htrevino\)" <[email-masked]>
Date: Thu, 30 Mar 2006 11:01:30 -0800

The main body of the netconf-notif doc does not describe this but
Appendix B.4 discusses potential protocol enhancements to support
NETCONF server session initiation. One of the use cases mentioned there
is "call home". 

The same appendix also mentions the subscription info persistency issue
that you talk about below. It is suggested as a potential enhnacement
but if you want "simple" then this is not a needed feature. The document
does not discuss a notification logging feature because it is not a
protocol feature (it is a system/model capability)- although it could be
added. So, I agree w/your comment about this being a problem but if
we're limited to protocol discussion then can't be addressed in the doc.

Hector

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Thursday, March 30, 2006 8:19 AM
> To: Netconf (E-mail)
> Subject: requirement: agent initiated session support
> 
> Hi,
> 
> The current subscribe model does not support agent initiated 
> sessions at all.  There are 2 use cases I think are important:
> 
> 1) notification generator application
>    Traditional model as in SNMP.
>    Agent SW dedicated to notification generation
>    (maybe an aggregator for multiple sub-agents)
>    Agent connects to the notification receiver application
>    and sends notifications as they are generated.
> 
> 2) bootstrap (thin agent)
>    Agent is initially configured with a
>   (username, password, cofig-server-IP-addr) tuple.
>   Agent boots and immediately connects to the config-server
>   (manager role in netconf), and issues a <configure-me>
>   notification (perhaps with some parameters). The config
>   server then issues <rpc> edit-config or copy-config
>   commands to finish bootstrapping the agent.
> 
> 
> Boot-up Problem with Subscribe model:
> 
> Using the client-subscribe model, all of the initial 
> notifications generated upon system reboot will be lost 
> because the agent isn't connected to a manager yet, and we 
> have no NOTIFICATION-LOG-MIB.  Requiring the agent to save 
> all notifications because a manager might connect someday and 
> request them is a huge memory burden and not likely to be supported.
> 
> In general, I don't really see the subscription model as an 
> improvement over the traditional configuration data model 
> approach.  Even when used in the client-initiated mode, it 
> isn't as efficient because the manager has to re-enter the 
> config-data every time (in the form of a start-notifications 
> RPC).  If the profile wasn't opaque that could be used instead.
> 
> Andy
> 
> 
> 
> 
> 
> 
> 
> --
> 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/>
> 

--
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: Andy Bierman <[email-masked]>
Date: Fri, 31 Mar 2006 06:42:13 -0800

> we're limited to protocol discussion then can't be addressed in the doc.

There's a lot of unspecified details in that appendix.
How does the manager know that some agent that initiates
the session wants it to invoke a <create-subscription> RPC?

The whole approach seems extra complicated for no apparent reason,
if I just want the agent to connect to a notification receiver
application using a pre-configured profile.

Andy