Subject: RE: NETCONF Notifications: Consensus Points

From: "Andrea Westerinen \(andreaw\)" <[email-masked]>
Date: Sat, 26 Nov 2005 21:42:24 -0800

One usage of application-level ACKs (by the sender) is to disable
sending notifications/event messages until specifically re-enabled.  

Andrea

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Saturday, November 26, 2005 6:51 PM
> To: [email-masked]
> Subject: Re: NETCONF Notifications: Consensus Points
> 
> 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/>
> 

--
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: "Randy Presuhn" <[email-masked]>
Date: Sat, 26 Nov 2005 22:20:58 -0800

Hi -

> From: "Andrea Westerinen (andreaw)" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Saturday, November 26, 2005 9:42 PM
> Subject: RE: NETCONF Notifications: Consensus Points
>

...

That depends on how one structures the protocol.  My initial reaction to
such a proposed usage is, in admittedly non-technical terms, "Eww, gross!"
More to the point, if the protocol only permits a single notification
"in the pipe" at a time, it would be unsuitable for use in high-delay (think NASA)
environments.   Perhaps we can live with that; I don't know whether anyone
would use netconf in high-delay environments.

This is not a necessary property of application-level acknowledgements;
an example of a protocol that does not have this property is CMIP.

Randy