[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: notification charter proposal
-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Monday, November 28, 2005 1:09 PM
To: Hector Trevino (htrevino)
Cc: Sharon Chisholm; netconf@ops.ietf.org
Subject: Re: notification charter proposal
Hector Trevino (htrevino) wrote:
>Agree and as I said in a previous e-mail... a transport layer (TCP) ACK
>is sufficient for most applications. An application layer ACK could be
>included in the spec for those users who think they need it. I suggest
>that this should be separate of app layer protocol (e.g. BEEP) built-in
>acks.
>
>
Do you mean an optional-to-implement ACK feature?
Or optional-to-use ACK feature?
HT: I meant an optional-to-use ACK feature. However, thus far
notifications are optional (another capability).
What is this mechanism exactly?
Don't care because you mean optional-to-implement and don't plan on
implementing it?
HT: No, we haven't discussed the mechanism because the current document
proposes NO appl layer ACKs. Some people want to have appl layer ACKs.
If there is enough support and justification for this additional
functionality then we could specify it.
Nobody has specified the messages, timeouts, state machine, etc.
It's more complicated than "throw in an ACK". IMO it is
bad engineering to build this complexity into the protocol if it's not
important enough to be mandatory to implement.
HT: Sure, agree.
Please see my previous email on the <notify-confirm> RPC idea.
I don't see why we would spend a lot of effort on a complicated
optional-to-implement solution when we already have a mandatory solution
available.
The <notify-confirm> RPC and setting the ack-required flag in the
<notify> message could be optional to implement or support.
But this is just another RPC, and there is no need to define a
complicated architecture because RPC is already defined.
BTW, this provides a 3-way confirm, not 2-way like an application ACK.
Since the agent replies <ok> to the <notify-confirm> RPC request, the
manager knows that the agent got the application ACK.
HT: I saw that and it is certainly a possibility. The current doc
introduces rpc-one-way (for unackd notifications). You could use the
existing rpc-request, rpc-reply for ackd notifications. I guess
depending on where the ack has to be originated what you're proposing
may be better but at an extra ACK expense.
>Hector
>
>
Andy
>
>
>-----Original Message-----
>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
>Behalf Of Sharon Chisholm
>Sent: Thursday, November 24, 2005 6:19 PM
>To: netconf@ops.ietf.org
>Subject: RE: notification charter proposal
>
>hi
>
>No, they are not the same, but the transport layer one seems to be
>sufficient from what I have seen. I suggest we don't do anything to
>preclude the later addition of an application level acknowledgements,
>but that we don't provide one now. The design in the current draft does
>this.
>
>Sharon
>
>-----Original Message-----
>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
>Behalf Of McDonald, Ira
>Sent: Thursday, November 24, 2005 3:58 PM
>To: netconf@ops.ietf.org
>Subject: RE: notification charter proposal
>
>
>Hi,
>
>As Juergen Schoenwaelder just pointed out - a transport layer ACK does
>NOT have the same semantics as an upper layer ACK that indicates
>receipt of a well-formed XML message.
>
>Confusing the two is not helpful - NetConf is supposed to behave the
>same over any transport.
>
>Cheers,
>- Ira
>
>
>Ira McDonald (Musician / Software Architect) Blue Roof Music / High
>North Inc PO Box 221 Grand Marais, MI 49839
>phone: +1-906-494-2434
>email: imcdonald@sharplabs.com
>
>
>
>>-----Original Message-----
>>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
>>Behalf Of Sharon Chisholm
>>Sent: Thursday, November 24, 2005 10:23 AM
>>To: netconf@ops.ietf.org
>>Subject: RE: notification charter proposal
>>
>>
>>hi
>>
>>The only interest I saw historically in informs were from people who
>>were disappointed we didn't run over TCP. After some investigation,
>>people generally chose other means to maintain confidence that they
>>were not loosing information. I just didn't see informs used in
>>practice.
>>
>>Given we now run over TCP, I have difficulty seeing people using
>>acknowledged notifications in practice. The solution could be defined,
>>
>>
>
>
>
>>but I don't really know if there a lot of value in doing so.
>>
>>Sharon
>>
>>-----Original Message-----
>>From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]
>>Sent: Tuesday, November 22, 2005 9:32 AM
>>To: Waters, Glenn [CAR:IO47:EXCH]
>>Cc: Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org
>>Subject: Re: notification charter proposal
>>
>>
>>On Tue, Nov 22, 2005 at 09:00:20AM -0500, Glenn Waters wrote:
>>
>>
>>
>>>>b) The notification sender sends a notification and gets a
>>>>
>>>>
>>confirmation
>>
>>
>>>> that the notification was understood to the extend
>>>>
>>>>
>>that it could
>>be
>>
>>
>>>> handed over to an entity dealing with notifications. (This is
>>>>
>>>>
>>what
>>
>>
>>>> SNMP notifications actually do.)
>>>>
>>>>
>>>I don't think that there is enough value in sending a
>>>
>>>
>>response in this
>>
>>
>>
>>>case since there is little recourse the sender can take to
>>>
>>>
>>correct the
>>
>>
>>
>>>issue. There is the possibility the sender could reduce the message
>>>size but that can be handled in other ways (such as the receiver
>>>reconfiguring the max size the sender should send). I can't
>>>
>>>
>>think of
>>
>>
>>>what else a sender would possibly do with a response. Maybe
>>>
>>>
>>it would
>>
>>
>>>help to identify those items to help decide if a response would be
>>>useful.
>>>
>>>
>>Knowledge of the fact that you were not understood can be very useful,
>>
>>
>
>
>
>>even if you do not know how to make yourself understood.
>>
>>You are arguing from a very narrow protocol centric perspective and I
>>agree that from this protocol centric perspective there is hardly
>>something you can do. However, if you take a more system wide
>>perspective, then I think one can easily make a case for b) and even
>>for c).
>>
>>Note: I am not against a) nor am I against b) and c) - it is just
>>important for me that once we talk about adding notifications, we
>>better be clear what their semantics are and which role they can play
>>in a systems view.
>>
>>/js
>>
>>PS: There are also strong ties here to notification logging (see the
>> NOTIFICATION-LOG-MIB produced by the DISMAN WG). The information
>> whether a notification was "understood" can actually be used to
>> decide what remains in a log and what can be purged. Without such
>> information, the notification originator actually has to log
>> everything (and maybe rely on the receiver to clear log entries).
>>
>>--
>>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/>
>>
>>
>>
>
>--
>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/>
>
>
>--
>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/>
>
>--
>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/>
>
>
>
>
--
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/>