Subject: Re: NETCONF Notifications: Consensus Points

From: Randy Presuhn <[email-masked]>
Date: Sat, 26 Nov 2005 18:50:45 -0800 (GMT-08:00)

Hi -

> From: Andy Bierman <[email-masked]>
> Sent: Nov 25, 2005 10:32 AM
> To: [email-masked]
> 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.

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

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

Randy

--
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: Sun, 27 Nov 2005 07:33:05 -0800

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

>the information has been processed (e.g., written to disk) by the

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.

>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