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

Re: NETCONF Notifications: Consensus Points

Randy Presuhn wrote:


Hi -


From: Andy Bierman <ietf@andybierman.com>
Sent: Nov 25, 2005 10:32 AM
To: netconf@ops.ietf.org
Subject: NETCONF Notifications: Consensus Points

...

Terminology:

The term Notification is preferred over Event Message.


My understanding of current IETF usage of "Notification" is as a
way of talking about the realization of a NOTIFICATION-TYPE, without
pinning it down to the specific SNMP PDU=type used to carry the
information.  I think that using it in the context of netconf to refer
to a particular message type would only be asking for confusion.
I understand the term "SNMP Notification" to mean that, but not the generic term. Many protocols have notifications. Only SNMP experts associate the generic term 
exclusively with SNMP. ;-)


We have used the term 'NETCONF Notification' since the first XMLCONF draft.
I really don't see the WG consensus to change it now.



...

Application-Level ACKs

 It is not clear what a sender would do differently even
 if it knew the receiver did not understand the message.


This is only one of the possible reasons for application-level
acknowledgments.  A more important one is that for purposes
such as log maintenance, it is essential that the generation
of the acknowledgment be under the application's control, rather
than, for example, the TCP stack's.  Otherwise, race conditions
arise in which the notification sender will erroneously believe
the information has been processed (e.g., written to disk) by the
receiver.



I'm not sure what this has to do with NETCONF.
If the sender cares about the difference in timing between the
receiver timestamping in the TCP stack vs. the application,
then perhaps a more suitable protocol (IPPM OWAMP)
should be used.

Our chartered application is Network Configuration.


Without specific features in the protocol which would
need app-level ACKs (such as data model version negotiation),
the cost and complexity of this feature cannot be justified.

...

This is based on the premise that the sole reason for application
level acknowledgment is confirmation that it could "understand"
the data.  For logging applications, this is neither necessary nor sufficient.


NETCONF is not an accounting protocol.
For network management, notifications are used for directed polling purposes. They are not intended to replace the reliable transfer of data via the direct request. 
This has been good enough for SNMP for years, so even if our charter
was to replace SNMP (which it is not), this is not a feature that the NM
community is currently using.
If the agent has vital data that must not be lost, and must be understood by the NMS, then it should be designed to hold on to that data until the NMS retrieves it with an RPC call. Notifications should be used to tell the NMS to get the data. If this is not acceptable, the agent can open a session to the manager and use 
a reverse RPC to push the data.


Randy



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