[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: example notification seems redundant

Sharon Chisholm wrote:

hi

Your the one who brought up the content discussion :-) As previously
indicated, there are significant benefits to being able to send
notifications with Netconf content. In addition, there are some gaps
between existing solutions and what is required. If you make too many
changes to existing solutions, they risk not interoperating with
deployed versions of itself. You risk ending up with the worst of both
worlds - a new protocol and one that still requires expensive mediation
to exchange information with Netconf-based ones.

The content discussion I was referring to is in Appendix B1, starting on
page 38.


I am only concerned with content as part of understanding
the access control model that is needed to limit
access to particular content.

I don't think the non-normative appendices are going to
stay in this document.  The WG is going to agree on
specific notification content (if any) and it will
be normative text.  Anything else will be removed from
the document.

XML already provides a way for us to implement a
content-independent protocol.  Just like for the
<config> element in RPC operations, a namespace is
used to link the content to a schema.

So our document does not even need to define content types.
Event classes can just be strings in the protocol.

Let's say one wanted to use RFC 3195 COOKED mode syslog
(even though it uses attributes instead of elements).
Here how the example from page 24 might look in netconf:


<notification xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <type>syslog</type>
  <sequence>1034</sequence>
  <timestamp>2006-05-07T11:30:00.000-08:00</timestamp>
  <data>
    <entry xmlns="http://iana.org/beep/SYSLOG/COOKED";
       facility="24" severity="5"
       timestamp="Oct 27 13:24:12"
       deviceFQDN="screen.lowry.records.example.com"
       deviceIP="10.0.0.47"
       pathID="173" tag="dvd"/>
    </entry>
  </data>
</notification>


So standard data models for notification content can continue
in parallel with standard data models for configuration,
after the protocol extension is done.  It's just a different
content layer namespace in the protocol.




Sharon


Andy




-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com] Sent: Friday, April 07, 2006 1:10 PM 
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: example notification seems redundant


Sharon Chisholm wrote:

hi

There are really then three different use cases at work here
1) I am the originator of the request and I would like some concise indication that things worked out OK in the end for some reason or other 



We have <rpc-reply> for this already.
2) I am creating an audit log and need to know exactly what was done and by whom and how 

This is a use case for a traditional dedicated notification generator ->
receiver application.
3) I am a user of the configuration information and need to know what information has been changed. This covers the cases of configuration mirroring, configuration applications and people just interested in the device inventory for whatever reason. 

There are several ways to do this already, such as
retrieving the configuration before the change and
again after the configuration.  The application
making the changes should also know, otherwise
it might carelessly clobber existing config data.

However, this still seems like a use case for the
traditional centralized notification service, not a
per-session model.

I am in favor of a netconf capability for notifications,
which means delivery of content-independent notifications
on a session (mandatory: dedicated; optional: mixed).

The syslog WG is going to have to be responsible for standardizing
syslog content, not the netconf WG. Beyond a standard content type
wrapper for <syslog-text>, and maybe <syslog-xml>, I don't believe the
netconf WG is the right place to work on syslog.
The example content in the appendixes cover the second and the third cases. I believe the message content is different for the three use cases. 

What page #s?


Sharon



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