David Harrington (co-chair of the Syslog WG) specifically asked me
for a review of documents in WG Last Call.
I am not subscribed to the SYSLOG WG mailing list, so pls copy
me explicitly on any reactions that you want me to see.
Bert
----- draft-ietf-syslog-device-mib-09.txt
First some SMICng error messages resulting from syntax checking:
C:\bwijnen\smicng\work>smicng syslog.inc
W: f(syslog.mi2), (47,17) REVISION value "200609R04000Z" is not
a valid extended UTC time
E: f(syslog.mi2), (97,15) Name of "auth" duplicates an existing one
E: f(syslog.mi2), (102,15) Name of "cron" duplicates an existing one
E: f(syslog.mi2), (54,20) Sub-Id for item "syslogMIB" must be
"number" or "name(number)" format
W: f(syslog.mi2), (245,4) Sequence "SyslDevOpsEntry" and Row
"syslEntOpsEntry" should have related names
W: f(syslog.mi2), (418,4) Sequence "SyslDevCtlEntry" and Row
"syslEntCtlEntry" should have related names
E: f(syslog.mi2), (418,4) Row "syslEntCtlEntry" may not have
columns with MAX-ACCESS of read-write if any column is read-create
*** 4 errors and 3 warnings in parsing
I see on page 3, sect 2:
status or the occurence of events. These messages are handled by what
has come to be known as the syslog application[RFCPROT] or device
[RFC3164]. In this document we refer to a syslog application or
Mmm RFCPROT and RFC3164 are both a protocol spec, not an "application"
or a "devie", are they?
I see on page 5:
The SyslogMIB module uses textual conventions defined in INET-
ADDRESS-MIB[RFC4001], TRANSPORT-ADDRESS-MIB[RFC4001] and SNMP-
FRAMEWORK-MIB[RFC3411].
I believe that the TRANSPORT-ADDRESS-MIB is described in RFC3419
and not in RFC4001.
Page 6:
LAST-UPDATED "200511250000Z" -- 25th November, 2005
While in the DESCRIPTION clause you have a copyright of 2006!!??
Further it is in conflict with the latest revision clause
REVISION "200609R04000Z" -- 9th September, 2006
AND... that one has an R in there that is not valid either.
Page 6:
Copyright (C) The Internet Society (2006). The initial
version of this MIB module was published in RFC yyyy;
for full legal notices see the RFC itself. Supplementary
information may be available at:
http://www.ietf.org/copyrights/ianamib.html.
"
-- RFC Ed.: replace XXXX with the actual RFC number & remove this
-- note
I think the "RFC yyyy" should read "RFC XXXX" in order to bein sync
with the RFCEd. note.
Further, I do NOT think that the copyrights for iana maintained MIB
modules is applicable here. I think you picked up the incorrect
template for MIB copyright. So probably you need to use:
Copyright (C) The Internet Society (2006). This version of this
MIB module is part of RFC XXXX; see the RFC itself for full
legal notices."
The read-write objects under syslogSystem MUST add text to the
DESCRIPTION clauses that state the expected persistency behaviour.
For
syslogDefaultTransport OBJECT-TYPE
SYNTAX TransportAddressType
I wonder how you represent syslog-transport over tls.
I guess you could use "unknown" but that seems not very satisfactory.
You could use one of the tcp transports I guess, but you would loose
the info about the fact that it is over tls, no?
Same question of course for syslEntCtlTransport object.
>From the DESCRIPTION clause of
syslEntOpsTable OBJECT-TYPE
SYNTAX SEQUENCE OF SyslDevOpsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing information about the syslog entities
serviced by an SNMP agent.
I cannot see why the "Ops" string is in the name???
It is OK if that is what the WG wants, but personally, I would
rather name it
syslogEntityTable
which seems a much more meaningfull name.
For
syslEntCtlTable OBJECT-TYPE
SYNTAX SEQUENCE OF SyslDevCtlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing static information about
the syslog entity.
"
::= { syslogDevice 2 }
I think that in the description clause I would state that this table
is to have control over the configuration of syslog Entities.
I think I would name it
syslogEntityCtlTable or syslogEntityControlTable
I further note that I find it a naming inconsistency to use "sysl"
as the prefix here instead of "syslog". This happens in the above
2 tables only. The rest of the MIB module nicely has syslog as
prefix.
I see:
syslEntOpsTable OBJECT-TYPE
SYNTAX SEQUENCE OF SyslDevOpsEntry
MAX-ACCESS not-accessible
Normal practice is that the SEQUENCE OF would in tis case be:
syslEntOpsTable OBJECT-TYPE
SYNTAX SEQUENCE OF SyslEntOpsEntry
^^^
Same story for:
syslEntCtlTable OBJECT-TYPE
SYNTAX SEQUENCE OF SyslDevCtlEntry
For
syslEntCtlEntry OBJECT-TYPE
SYNTAX SyslDevCtlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The parameters pertaining to a syslog process."
INDEX { syslEntOpsIndex }
::= { syslEntCtlTable 1 }
I wonder if this is a sparse augmentation (it seems so because
otherwise it might have been an AUGMENTs).
I wonder though if this is intentional or accidental.
I personally think I would have made this the base table
and maybe used an AUGMENTS for the read-only (syslEntOpsTable).
The Counter32 object in the syslEntOpsTable MUST specify if/when
a discontinuity can occur and which timer indicates such discontinuity.
Probably the only discontinuity is when the SNMP agent restarts,
but I am not sure. If so it would be sysUptime that serves as the
discontinuity timer.
For:
syslEntOpsLastMsgDeliveredTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The local time when the last message was delivered
by the syslog process.
"
I would think it is better to say "was relayed or sent"?
Because you do not actually know (in many cases) if the
message indeed does get delivered to the other end, do you?
For:
syslEntOpsLastError OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A description of the last error that was encountered
by this process.
"
I am not sure I understand what "this process" is?
Is it the agent (I guess not)? Is it the syslog entity?
Or is it something else?
For:
syslEntOpsReference OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If the Host resource MIB is serviced on the host then
this entry will have the value of the hrSWRunIndex
of the corresponding entry in the hrSWRunTable.
Otherwise this object will be inaccessible,
"
First, I would change "is serviced" into "is instantiated" or "is supportted".
Further I see that hrSWRunIndex is defined as:
hrSWOSIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
So I would expect the SYNTAX for syslEntOpsReference to also be
SYNTAX Integer32 (1..2147483647)
But... The last sentence of the DESCRIPTION clause says:
Otherwise this object will be inaccessible,
(should have a period at the end instead of a comma by theway)
and that is also something that is VERY UNCLEAR.
Maybe a "nosuchInstance" exception would be better.
Maybe the best is to define the object as:
syslEntOpsReference OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If the Host resource MIB is instantiated on the host then
this entry will have the value of the hrSWRunIndex
of the corresponding entry in the hrSWRunTable.
The special value of zero indicates that the Host resource
MIB is not instantiated.
"
I see:
syslEntCtlTable OBJECT-TYPE
SYNTAX SEQUENCE OF SyslDevCtlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing static information about
the syslog entity.
"
First I am not sure it is really static, because it allows to change
the values. But in any event, I would describe that this table is
intended to configure syslogEntities.
For syslEntCtlProcDescr I wonder if this value is/can be used
anywhere else. If yes, pls say something about it.
For:
syslEntCtlBindAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The specific IP address or hostname the syslog process
will bind to. If a hostname is specified, the IPv4 or
IPv6 address corresponding to the hostname will be used.
"
::= { syslEntCtlEntry 3 }
I am not sure what "if a hostname is specified..." means.
If it is a FQDN, then the InetAddressType would be 'dns'
And yoiu MUST specify when that name is resolved into an IP address.
But probably you mean that if it is just some local hostname, that
in that case an IPv4 or IPv6 address shoudl be specified. That is not
100% clear to me though. So pls clarify.
You MUST also add some text that states that the format of this address
is controlled by the value of the corresponding syslEntCtlBindAddrType
object.
For:
syslEntCtlConfFileName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The fullpath name of the configuration file where the
syslog entity's message selection and corresponding
action rules will be read from.
Data is loaded from this file into the
syslogCtlSelectionTable and the syslogCtlLogActionTable.
If the objects loaded from the file specified by this
object have an access level of read-create, this file MUST
be writable so that modifications to the corresponding
objects, if any, will be effected in this file.
If the system does not support the specification of a
configuration file, this field will not be accessible.
"
DEFVAL { "/etc/syslog.conf" }
::= { syslEntCtlEntry 7 }
I wonder where is/are the syslogCtlSelectionTable and the
syslogCtlLogActionTable tables defined? I cannot find them
so I am not sure what this means.
I think that instead of
If the system does not support the specification of a
configuration file, this field will not be accessible.
I would make this object a zero-length string. Much cleaner
and much easier on both agent and NMS.
For:
syslEntCtlStatus OBJECT-TYPE
SYNTAX INTEGER {
unknown (1),
started (2),
suspended(3),
stopped (4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The status of the process.
"
DEFVAL { unknown }
What is "the process" ??
I think I would add a DEFVAL for syslEntCtlStorageType
Any value that the WG feels appropriate is fine.
For syslEntCtlRowStatus
- s/iff/if/
- I am surprised to see that one needs to go to notInService
state in order to change any column in the row. There are
various that could very well be changed (maybe even all)
while in active state. And such is much easier on both
agent and manager.
The two NOTIFICATIONs could easily be combined into a
syslogEntitySTatusChanged NOTIFICATION-TYPE
Just a minor optimization I guess
I would think/hope that there is some relation between theobjects in the
syslogSystemGroup and those in the syslogDevCtlGroup.
For example, if no maxMessage size is specified in syslEntCtlMaxMessageSize,
then the maxmessagesize from syslogDefaultMaxMessageSize is used?
But the DESCRIPTION clauses of the OBJCTS say nothing about this,
so I am not sure how to determine which value to use when?
I think I would change
syslogCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities
which implement the SYSLOG-MIB.
"
Into something like:
syslogFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which implement
the SYSLOG-MIB with support for writable objects. Such an
implentation can be both monitored and configured via SNMP.
"
I am not sure I completely understand the intent of
syslogNotificationCompliance. Is it the idea that an implementation
can claim compliance to just send notifications and nothing else?
If so, you may want to make that clear.
Even then, I think I would include the syslogNotificationGroup in
both the other two MODULE-COMPLIANCE statements, so that if you
support it all, you only have to claim compliance with a single
MODULE-COMPLIANCE statement.
On page 27 I see:
Even if the network itself is secure (for example by using IPSec),
I know that at least one of the SECURITY ADs will want you to
s/IPSec/IPsec/.
The latest MIB security template has the fix already in it.
I see quite a few places where you use "MIB" while I think what you
mean is the/a "MIB Module". I know this is a nit. Nevertheless,
it seems you need to do a revision to at least fix the syntax errors,
so might as well addres this.
Bert
----------- original review message:
> >
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt
> > >
> > > Transmission of syslog messages over UDP
> > >
> >
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07
> > > .txt
> > >
> > > TLS Transport Mapping for SYSLOG
> > >
> >
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03
> > > .txt
> > >
> > > Syslog Management Information Base
> > >
> >
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx
> > > t
> > >
> > > Signed syslog Messages
> > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt
> > > (We expect this document to be updated this week.)
> > >
> > > David Harrington
> > > [EMAIL PROTECTED]
> > > [EMAIL PROTECTED]
> > > [EMAIL PROTECTED]
> > >
> >
>
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
