Subject: [Syslog] draft-ietf-syslog-device-mib-15

From: "tom.petch" <[email-masked]>
Date: Wed, 4 Apr 2007 13:52:15 +0200

A few more suggestions on this thorny matter:-(

I like the change to [references] in the object descriptions - but I would
suggest moving the paragraph which tells the RFC Editor what to do up the
document to the first time that RFCPROT occurs. And label it as a Note to the
RFC Ed. because that is what it is (unless we wait on the publication of the
other RFC before submitting this one which could delay it for nine months)

In the statistics entries, I suggest that 'should have a zero value' is more
accurate than 'will have a zero value'  (really it is 'SHOULD be zero' but I do
not think that that is allowed in a MIB module).

s2  'A relay forwards /some/  ... ' suggest /some or all/

s3 statistics now include received, sent, relayed and discarded so I would
mention all those options here.

SyslogRoles confuses me; I read the earlier text in s2 as sender/receiver being
the lower layer and collector/relay/originator as being the application; in
which case, I expect the Roles to be collector/relay/originator ie relay
includes both sender and receiver in the lower layer sense in which they are
used elsewhere.

SyslogEncapsulation - what did we decide about Syslog-Sign; I have lost track.

suggest removing
   --syslogControlTable
   --
   --
   --syslogOperationsTable
   --

syslogControlBindPort - might there be a default of 514?

syslogOperationsMsgsTransmitted - I would prefer syslogOperationsMsgsSent since
we talk elsewhere of Sender and not Transmitter.  The two terms are near
synonyms but could confuse a non-native speaker

syslogOperationsMsgsDropped
           "The number of messages that could not be queued
            for transmission by the syslog sender.
I am unclear what this means; it sounds to me like an implementation detail.  In
general, I would expect there to be other reasons, other resource shortages, why
messages could not be sent and would prefer a more generic description with
'could not be queued' as an eg rather than the sole cause

syslogOperationsCounterDiscontinuityTime
OBJECT-TYPE
             counters, viz., counters with OID prefix

I would suggest Object Descriptor rather than OID prefix

syslogOperationsMsgsMalFormed -  the reference to s6.3 is a reference to
structured data whereas the text in this I-D only talks of header; I know of no
reference for malformed headers, although it has surfaced on the list, without,
as I recall, any conclusion.

Tom Petch

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 10 Apr 2007 08:35:25 +0200

Tom,

I have documented the generic design of almost (all?) syslog
implementations I know. Of course, there are some slight differences if
you look at the code, but the logical functions are present. Find it
here:

http://www.rsyslog.com/module-Static_Docs-view-f-/generic_design.html.ph
tml

Rainer

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2007 1:52 PM
> To: syslog
> Cc: David Harrington
> Subject: [Syslog] draft-ietf-syslog-device-mib-15
> 
> In the statistics entries, I suggest that 'should have a zero value'
is
> more
> SyslogEncapsulation - what did we decide about Syslog-Sign; I have
lost
> track.