[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Syslog] RE: Request for Reviewers - draft-ietf-syslog-device-mib-09.txt
Bert,
I have revised and submitted draft-ietf-syslog-device-mib-11.txt.
The actions taken for each of the points raised are given in the
attached document. Please let me know if any of the points have not
been addressed adequately.
Cheers
Glenn
Wijnen, Bert (Bert) wrote:
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
dharrington@huawei.com
dbharrington@comcast.net
ietfdbh@comcast.net
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
1. First some SMICng error messages resulting from syntax checking:
=>
=> C:\bwijnen\smicng\work>smicng syslog.inc
=>1a W: f(syslog.mi2), (47,17) REVISION value "200609R04000Z" is not
=> a valid extended UTC time
=>1b E: f(syslog.mi2), (97,15) Name of "auth" duplicates an existing one
=>1c E: f(syslog.mi2), (102,15) Name of "cron" duplicates an existing one
=>1d E: f(syslog.mi2), (54,20) Sub-Id for item "syslogMIB" must be
=> "number" or "name(number)" format
=>1e W: f(syslog.mi2), (245,4) Sequence "SyslDevOpsEntry" and Row
=> "syslEntOpsEntry" should have related names
=>1f W: f(syslog.mi2), (418,4) Sequence "SyslDevCtlEntry" and Row
=> "syslEntCtlEntry" should have related names
=>1g 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
=>
Action. Fixed 1a-1f
changed the duplicate instances of auth and cron to
auth1, auth2, cron1, cron2
changed: SyslDevOpsEntry -> SyslogEntityOperationsEntry
syslEntOpsEntry -> syslogEntityOperationsEntry
SyslDevCtlEntry -> SyslogEntityControlEntry
syslEntCtlEntry -> syslogEntityControlEntry
+------------------------------------------------------------+
2 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?
Action. Response:
The entity that handles syslog messages is called an "application" in
[RFCPROT] and a device in [RFC3164]. That is what the text above intends
to say.
Looks OK to me. Let me know if you want to change the wordings.
+------------------------------------------------------------+
3 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.
=>
Action. Fixed.
Added TRANSPORT-ADDRESS-MIB[RFC3419] to the text on section 3
(and 7.1 Normative References).
+------------------------------------------------------------+
4 Page 6:
=>
=> LAST-UPDATED "200511250000Z" -- 25th November, 2005
=>
=>4a While in the DESCRIPTION clause you have a copyright of 2006!!??
=>
=>4b 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.
=>
Action. Fixed 4a-4b.
+------------------------------------------------------------+
5 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
=>
=>5a I think the "RFC yyyy" should read "RFC XXXX" in order to bein sync
=> with the RFCEd. note.
=>5b 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."
=>
Action. Fixed 5a-5b.
+------------------------------------------------------------+
6 The read-write objects under syslogSystem MUST add text to the
DESCRIPTION clauses that state the expected persistency behaviour.
Action. Fixed.
Added text
"The value of this object SHOULD remain unchanged
across reboots of the managed entity."
to the DESCRIPTION clauses for all the read-write objects under
syslogSystem.
+------------------------------------------------------------+
7 For
syslogDefaultTransport OBJECT-TYPE
SYNTAX TransportAddressType
=>7a
=> 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?
=>
=>7b
=> Same question of course for syslEntCtlTransport object.
Action. Fixed 7a, 7b
replaced
syslogDefaultTransport OBJECT-TYPE
SYNTAX TransportAddressType
and
syslEntCtlTransport OBJECT-TYPE
SYNTAX TransportAddressType
by
syslogDefaultTransportDomain OBJECT-TYPE
SYNTAX TransportDomain
and
syslogEntityControlTransportDomain OBJECT-TYPE
SYNTAX TransportDomain
+------------------------------------------------------------+
8 >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.
Action. Fixed.
Changed "Ops" to "Operations".
The table name is changed to syslogEntityOperationsTable.
There are two tables syslogEntityControlTable and
syslogEntityOperationsTable
one is for control and the other for operations
statistics and information.
+------------------------------------------------------------+
=>9 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 }
=>
=>9a I think that in the description clause I would state that this table
=> is to have control over the configuration of syslog Entities.
=>
=>9b I think I would name it
=>
=> syslogEntityCtlTable or syslogEntityControlTable
=>
=>
=>9c 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.
=>
Action. Fixed 9a-9c
revised DESCRIPTION of syslogEntityControlTable.
changed syslEntCtlTable -> syslogEntityControlTable
fixed SyslDevCtlEntry -> SyslogEntityControlEntry
+------------------------------------------------------------+
10 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
=>Action. Fixed.
=> changed: SyslDevOpsEntry -> SyslogEntityOpsEntry
=> syslEntOpsEntry -> syslogEntityOpsEntry
=> ^^^
=>11 Same story for:
=> syslEntCtlTable OBJECT-TYPE
=> SYNTAX SEQUENCE OF SyslDevCtlEntry
Action. Fixed.
changed: SyslDevCtlEntry -> SyslogEntityControlEntry
syslEntCtlEntry -> syslogEntityControlEntry
+------------------------------------------------------------+
12 For
=> syslEntCtlEntry OBJECT-TYPE
=> SYNTAX SyslDevCtlEntry
=> MAX-ACCESS not-accessible
=> STATUS current
=> DESCRIPTION
=> "The parameters pertaining to a syslog process."
=> INDEX { syslEntOpsIndex }
=> ::= { syslEntCtlTable 1 }
=>
=>12a 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).
=>
=>12b 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.
=>
Action. Fixed 12a, 12b
a. syslogEntityOperationsTable AUGMENTS syslogEntityControlTable
b. added syslogEntityOperationsCounterDiscontinuityTime object
added text to the Counter32 objects about the discontinuities
+------------------------------------------------------------+
13 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?
Action. Fixed.
renamed the object
from syslEntOpsLastMsgDeliveredTime
to syslogEntityOperationsLastMsgTransmittedTime.
revised the DESCRIPTION of the object
+------------------------------------------------------------+
14 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?
=>
Action. Fixed.
Revised the DESCRIPTION. process-> entity
+------------------------------------------------------------+
=>15 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,
=> "
=>
=>15a
=> First, I would change "is serviced" into "is instantiated" or "is supportted".
=>15b
=> 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.
=> "
Action. Fixed.
a. Revised the DESCRIPTION.
b. Revised the SYNTAX to Integer32 (0..2147483647)
+------------------------------------------------------------+
16 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.
=> "
=>
=>16a
=> 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.
=>
=>16b
=> For syslEntCtlProcDescr I wonder if this value is/can be used
=> anywhere else. If yes, pls say something about it.
Action. Fixed.
Revised the DESCRIPTION clause
+------------------------------------------------------------+
17 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 }
=>
=>17a
=> I am not sure what "if a hostname is specified..." means.
=> If it is a FQDN, then the InetAddressType would be 'dns'
=>17b
=> 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.
=>
=>17c
=> You MUST also add some text that states that the format of this address
=> is controlled by the value of the corresponding syslEntCtlBindAddrType
=> object.
Action. Fixed 17a, 17b, 17c.
Revised the DESCRIPTION clause.
+------------------------------------------------------------+
18 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 }
=>
=>18a
=> I wonder where is/are the syslogCtlSelectionTable and the
=> syslogCtlLogActionTable tables defined? I cannot find them
=> so I am not sure what this means.
=>18b
=> 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.
Action. Fixed 18a, 18b.
Revised DESCRIPTION clause.
Removed references to syslogCtlSelectionTable and
syslogCtlLogActionTable.
+------------------------------------------------------------+
19
=> 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 }
=>
=>19a
=> What is "the process" ??
=>19b
=> I think I would add a DEFVAL for syslEntCtlStorageType
=> Any value that the WG feels appropriate is fine.
=>
Action. Fixed.
a. Changed process -> entity.
b. added DEFVAL { nonVolatile } to syslEntCtlStorageType
+------------------------------------------------------------+
20 For syslEntCtlRowStatus
=>20a
=> - s/iff/if/
=>20b
=> - 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.
Action. Fixed 20a, 20b.
a. changed iff->if.
b. added text in the DESCRIPTION about objects that
be changed when this object is in state ''active'' or in
''notInService''.
+------------------------------------------------------------+
21
=> The two NOTIFICATIONs could easily be combined into a
=> syslogEntitySTatusChanged NOTIFICATION-TYPE
=> Just a minor optimization I guess
Action. Fixed.
+------------------------------------------------------------+
22 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?
Action. Fixed.
Revised the DESCRIPTION clauses of the Objects in syslogEntityControlGroup
+------------------------------------------------------------+
23 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.
=> "
Action. Fixed.
The Compliance section has been revised.
+------------------------------------------------------------+
24 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.
Action. Fixed.
The Compliance section has been revised.
Full compliance can be claimed with syslogFullCompliance1 now.
+------------------------------------------------------------+
25 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.
Action. Fixed.
+------------------------------------------------------------+
=>26 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.
Action. Fixed.
+------------------------------------------------------------+
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog