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 PROTECTED] > Sent: Wednesday, April 04, 2007 1:52 PM > To: syslog > Cc: David Harrington > Subject: [Syslog] draft-ietf-syslog-device-mib-15 > > 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 > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
