On Tue Oct 26 10:33 1999 -0500, Chris M. Lonvick wrote:
> I'd change the title to "Verifiable Delivery" rather than "Guaranteed
> Delivery" and propose that it be expanded a bit more. The sender can
Yeah, that's probably a better label.
> 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.
Please correct me if I'm misinterpretting you, but you seem to be
saying that the verifyable delivery option should be a configurable
parameter at the daemon level. However, it needs to be selectable at
the API level because the user process will need the ability to select
verifyable delivery before the message even gets to the local syslogd.
Also, just on general principles, I think that the application code is
in the best position to determine which behavior makes sense, because
the system or network administrator isn't usually familiar with all
the intricacies of the code.
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
