[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NETCONF Notifications: Consensus Points
On Fri, Nov 25, 2005 at 01:26:20PM -0800, Andy Bierman wrote:
> >>Application-Level ACKs
> >>
> >> It is not clear what a sender would do differently even
> >> if it knew the receiver did not understand the message.
> >> 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.
> >>
> >>
> >
> >I think that we require Netconf Notification ACKs, and they can be
> >optional as was done in SNMPv3 (i.e.: unACKed traps, ACKed informs).
> >They are required for cases where the sender needs to know if the
> >information was successful transmitted and may decide to retransmit at a
> >later time.
> >
> >
>
> I'm not sure we are all clear on the semantics here.
> What I think we mean by application-layer ACK
> is the receiver understood the message. TCP lets
> us know the receiver got the message.
>
>
> I don't see how retransmitting at a later time will
> help the receiver understand the message (delivered as sent)
> any better, unless the reason the message was garbled is
> an intermittent bug in the sender. I don't think we need to
> worry about this case in the protocol. Because if this isn't the case, then
> the exact same error condition will occur no matter how
> many times the sender retries.
My understanding is that a netconf protocol does not exist in
isolation and that most events that trigger netconf notifications will
originate in other pieces of software. For some pieces of software,
"shout and forget" is all what is needed. Other applications may want
to know whether they were heard so they can for example flush entries
in notification logs (as Randy mentioned).
If we don't provide application layer acks for those apps who need it,
then these apps will end up using TCP acks as the only approximation
for the indication that everything went fine. Such a best guess may
work, but it surely is not what I would call a robust solution (but
who cares about this these days).
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
--
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/>