Re: draft-shafer-netconf-syslog-00.txt

[Shane Kerr <Shane_Kerr@isc.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Phil Shafer wrote:
> Shane Kerr writes:
>> Nicely done. One concern I have is difficulty for clients to actually
>> get historical messages without duplication.
> 
> The <start-time> doesn't really give a duplication-free guarantee,
> but one can increase the resolution of the log files (we optionally
> add milliseconds) to reduce the duplication.

I was hoping to allow a way for a client to:

1. Not lose log messages.
2. Not get duplicate log messages.

The client has no way to know what the resolution on the server is. The
only way I can think of for the client to remove duplicate messages is
to store all of the messages down to the resolution of the time.

So, if there is a 1-second resolution, the client would have to store
all of the messages that arrived in the same second as the last message.
That is:

2006-06-20T10:55:27 msg1
2006-06-20T10:55:27 msg2
2006-06-20T10:55:27 msg3

If the client disconnects and reconnects to the server, then selects a
<start-time>2006-06-20T10:55:27</start-time>, it would get all of these
again, and discard them as already seen. But it would *need* to pick
that time, in case a 4th message arrived that it did not want to miss.
(Minor issue here that the server must re-send these messages, but I
consider this will be a rare occurrence.)

Whether the resolution is 1-second or 0.1-second, the process is the same.

A client could attempt to minimize the buffer size by figuring out the
resolution of the time on the server. (For instance, by remembering the
smallest non-zero time difference between two events.)

It seems like a lot of work, for what I think is a reasonable set of
goals, which is why I suggested the addition/change.

>> Plus, using time means server clock skew would cause almost unlimited
>> confusion. :)
> 
> The value for <start-time> will most likely be the timestamp of the
> last message received from the server, assuming a connection failure.
> In this case, the timestamp will be assigned by the server and it
> will be interpreted by the server, so clock skew shouldn't matter.

My mistake. I should not have said "skew". I meant if the server jumps
the time forward or backwards.

>> I think it would be much nicer to assign a unique identifier to each
>> event. I recommend an increasing number. In this case, the server would
>> only need to output the number at the beginning of the answer (and maybe
>> periodically also). The client knows what the last event it received is,
>> because it increments for each one.
> 
> A sequence number will interfere with filtering, since the client
> won't see monotonically increasing numbers, as messages will be
> dropped.  It also introduces a number of complex issues that go
> against my KISS attitude, such as the lifespan of the sequence,
> sequences for multiple streams, and the interaction for messages
> that match multiple streams.  Not unsolvable, but not a priority.

True, filtering complicates things a bit, as do multiple streams. You're
probably right that it is a bit too complicated for the gain, and a
small buffer on the client is the way to go if one cares.

- --
Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEl7ykMsfZxBO4kbQRAqODAJwIeRzGXIKRYnU4EaoyRxCzNRfsaQCgnmWK
NJ5iQtTkAAKLQUhU/tUXQNk=
=cYrT
-----END PGP SIGNATURE-----

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