David Harrington wrote:
Hi Eliot,
Having discussed this further with you and Rainer, I tend to agree the
changes are smaller than I originally thought.
So that the WG can properly assess this, can you produce an individual
draft with the proposed changes, so the WG can discuss the changes
This is precisely the sort of thing that RFC 3195 attempted. You want
authenticated source? You can have it. You want authenticated server?
You can have that too. You can even have unauthenticated server with
authenticated client. As we've just released a revision draft, I
suggest people
Sam,
I got involved recently because both chairs asked me to submit a draft
to revise 3195 to reflect the work of -protocol-19. I have done so.
And so perhaps you can help me.
The charter calls for a secure transport. The milestones say TLS
(something that could easily be changed without
Hi Chris,
I've taken a look at this document, and I have just two comments. In
section 4.2.2:
A client's certificate must be associated with a unique private key .
Private keys MUST NOT be shared between clients.
This is not part of the protocol, often beyond the control of the syslog
. This may include producing a message
on a
console, returning an error to a user (if there is one), or
writing a
file to disk, if possible.
Does the third paragraph eliminate the need for the first two
paragraphs?
dbh
-Original Message-
From: Eliot Lear [mailto:[EMAIL PROTECTED
Miao Fuyou wrote:
My perception is logging does not necesarily mean send events over network
to syslog server,. Webopedia says log is to record an action. If there is
no syslog connection available, it is still possible to log the message in
local storage.
Right. The issue here, however, is
tom.petch wrote:
A second class of applications cannot maintain an RTT estimate for a
destination, because the destination does not send return traffic. Such
applications SHOULD NOT send more than one UDP message every 3 seconds, and
SHOULD consider if they can use an even less aggressive rate
