[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
Thanks.
I wil re-review. But may take a few weeks.
I have quite a few MIB documents in my queue for review.
Bert
> -----Original Message-----
> From: Glenn M. Keeni [mailto:glenn@cysols.com]
> Sent: Wednesday, November 08, 2006 14:56
> To: Wijnen, Bert (Bert)
> Cc: syslog@ietf.org
> Subject: 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
>
>