Hi Mark,
I'd change the title to "Verifiable Delivery" rather than "Guaranteed
Delivery" and propose that it be expanded a bit more. The sender can
either decide if it wants to verify that the delivery was successful,
or that is does not care if the mesages were received.
This can address the concerns for both the system performance as well as
the network bloat. As a default, the selector flag could be set to mark
the message that no acknowledgment of receipt is required from any of
the intermediates or from the final receiver. It would then be left to
the network/security administrators to effectively customize the setting
of the flag for their own network requirements.
As an operational example:
-By default all machines send messages to 'syslog' servers without
verification of receipt (as is consistent with today's implementation).
-Network security policy enforcement devices (firewalls, authentication
servers, CAs, etc.) send all event messages with receipt verification
enabled and with immediate acks.
-All network devices in Area 51 have verification enabled for messages
sent with a serverity of "really bad".
-Any messages sent from facility "XYZ" of any machine should also be sent
with verification enabled with the possiblity of a delayed ack.
It could be an implementation detail of how each application/machine
deals with the non-receipt of 'receipt confirmation requested' messages.
They could either choose to keep the message in the queue and contiue to
attempt delivery, or they could take some other action such as
application-suicide.
Thanks,
Chris
At 09:34 AM 10/26/99 -0500, Mark D. Roth wrote:
>(Note: This message discusses some implementation details of the new
>syslog on a Unix system, but only in as much as it relates to protocol
>design issues.)
---remainder deleted for brevity---
