McDonald, Ira wrote:
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.
What is of particular concern is the way things are going in ISMS, where
because of the existing ASIs and elements of procedure a question came
up over how to signal back to the upper layers when a TCP connection has
failed. One solution was to simply ignore the problem and let the upper
layer deal with the problem as if the transport WERE unreliable. I
don't like that approach because it doesn't properly take advantage of
TCP's ability to alert the application to a network problem.
Related- we are currently in a bit of a scrum with ATIS TMOC over IPFIX
about application layer acknowledgments. There they want 100%
reliability "from disk to disk". That means that even a TCP ACK is not
sufficient because the recipient stack will have ACKed probably several
ms before that point.
Here is the question: what level of reliability is necessary for the
applications we have in mind? The above example is for accounting where
arguably money is involved. Are these notifications going to be used to
derive a revenue event (SLA management, for instance) such that if a
recipient crashes and the event is lost after having been acknowledged
somebody would be upset?
I don't envision that. Therefore I wouldn't include it. However, if
somebody wants it they can still have it by using BEEP. All of this
having been said...
Confusing the two is not helpful - NetConf is supposed to
behave the same over any transport.
If NETCONF is to behave the same over any transport then why have more
than one? Why are we going through a last call for THREE transports?