Re: Update to Netconf Notifications Draft

[Phil Shafer <phil@juniper.net>]

[back from vacation and kickstarting my brain (putt, putt)]

Andy Bierman writes:
>The eventual solution will need to provide for
>proper standard read-create data models, specify
>a reasonable architecture and security model,
>and be as simple as possible, with a small number
>of options.

With the exception of the create (.vs. write?) data model, I think
I cover most of this.  What are you looking for wrt the security
model?  Security of the content of the data (permission to see bgp
peer information) or just security of the data as a whole (as covered
by the transport protocol)?

>We also need to explain why it is so important that
>the NMS get copies of notifications in NETCONF sessions,
>as opposed to using a mgr-2-mgr API to get the same information
>from a notification receiver application (e.g., syslog +
>SNMP trap server).

Syslog and snmp are traditionally preconfigured, with the device
knowing (from config) who to aim notifications at.  This works
well in traditional environments but breaks in the "pop open my
laptop and run my application locally" world.  When configuring
a device, access to the notifications it is sending gives valuable
information about the state of the box, what's going on, and what
you just broke.  Being able to see this in your application (and
being able to react to it automatically) is a win.

I have some words about this in the draft; do I need more?

Thanks,
 Phil

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