We could eliminate the replay attributes from the notification
operation, and a data model for logging unsent notifications could be
defined that can be accessed using a <get>. This way replay becomes a
data-model-specific thing, not an operation extension, and the
notification operation is vastly simplified.
All the extra text associated with replay that we are debating would
go away, and the netconf-equivalent of "end of table" would identify
when replay was complete.
The SNMP community didn't define a new operation feature to provide
replay; they defined the NOTIFICATION LOG MIB. The MIB has the
following sections:
o Configuration -- control over how much the log can hold and
what Notifications are to be logged.
o Statistics -- indications of logging activity.
o Log -- the Notifications themselves.
In this MIB, each log is named, and has an associated filter, and an
associated entry limit. In netconf terms, each "named" log of
notifications for replay could be considered a separate stream. So a
manager could subscribe for a replay-stream. But I like the <get>
approach.
With the MIB, a manager must explicitly ask that notifications be
logged (saved), and which notifications are of interest. The agent
does not need to save all notifications in case some manager decides
to ask for a filtered subset of the whole sometime in the future, but
is only required to save the notifications explicitly requested by a
manager when it requested the named log be maintained. And the maximum
number of entries in each log can be specified by the manager as well.
If a netconf manager was required to configure the replay log in
advance, then they could request only the notifications of interest;
this is similar to a subscribe. The MIB uses a "filter name" to
identify a filter predefined in a different table; this is similar to
the namedProfile feature of netconf-notifications. If the manager was
required to provide something akin to OwnerString, then once the
manager had accessed the notifications it had requested, then the
agent could discard the saved notifications "stream" (and a manager
could choose to delete their saved log). If no manager requests
replay, then the agent does not need to consume resources saving
notifications nobody wants.
This seems consistent with the syslog.conf approach of allowing
operators to name logs, and specifying what they want saved into those
logs. Since notification replay is really all about replaying logs of
notifications, it would probably be a good thing to design an approach
consistent with existing widely-deployed logging mechanisms, such as
syslog, so that existing admin tools and scripts would work with the
netconf replay logs as well.
David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
-----Original Message-----
From: owner-netconf@ops.ietf.org
[mailto:owner-netconf@ops.ietf.org] On Behalf Of Phil Shafer
Sent: Friday, July 13, 2007 3:50 PM
To: Andy Bierman
Cc: Balazs Lengyel; Netconf (E-mail)
Subject: Re: notification-08 comments
Andy Bierman writes:
This mode
(get replays from time A to time B) could be viewed as just
another RPC operation like <get>.]
Heck, all of get-notifications could be viewed as just another RPC
operation ;^)
Thanks,
Phil
P.s.:
http://professional.juniper.net/phil/ietf/draft-shafer-netconf
-syslog-00.txt
--
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/>