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

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?

What is this mechanism exactly?
Don't care because you mean optional-to-implement and don't
plan on implementing 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.

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.



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