Tom,
>
>
> Getting there; recall that my initial problem is one of understanding what it
> is
> the MIB caters for. I had expected the MIB to cater for a pure Sender, in
> order
> to configure it with where to send what, and I am slightly suprised at that
> omission. As ever, it is a question
llowing sysplex as a single operating system)? If
> not,
> what makes it a group?
It means that there may be more than one Syslog daemons running on different
ports
/network addresses. The grouping is a feature not a necessaity. I think that it
is
providing flexibility that will be nee
Tom,
Apologies for the delay in responding.
> I have had a look at the syslog MIB, and am confused, at a fairly fundamental
> level, about the relationship of the MIB to the other documents, RFC3164 and
> syslog-protocol. The last two have a common framework/architecture, spelt out
> at the begi
Chris,
I have reviewed the earlier protocol document and I will certainly review
the new protocol document.
Glenn
Balazs Scheidler wrote:
> On Wed, 2005-12-07 at 11:51 -0800, Chris Lonvick wrote:
>
>>Hi All,
>>
>>I've spoken to a few of you about reviewing the documents. Would those of
>>
to the header.
>
> Rainer
>
>
>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards
>>Sent: Wednesday, November 23, 2005 3:04 PM
>>To: Glenn Mansfield Keeni; [EMAIL PROTECTED]
>>Subject: RE: [S
Chris,
You seem to have dropped the last deliverable which is in good shape
> - A MIB definition for syslog will be produced.
I would strongly recommend that we include it. It is an important aspect
of the protocol. Some effort has gone into it. And it is the least
controversial [there a
Chris/Rainer,
> we continue to use ... at the start of syslog messages. This will
> allow current receivers to continue to receive messages and put them in
> the right bins. Does anyone disagree with this?
Complete agreement.
>
>
> The WG has agreed to use the timestamp Rainer has in the curr
Folks,
A few minor comments on draft-ietf-syslog-transport-udp-05
a. Page 10.1
the text says
"This transport does not provide for strong sender authentication".
That sort of seems to imply that "weak sender authentication" is provided
for. Is that the intent ?
To me it app
Hi,
A few small points that I noticed while reviewing the latest 15.txt draft
are given below. Apologies for noticing some of these so late in the day.
Cheers
Glenn
+=+
Comments
a. page 7 Section 4 Basic Princip