Subject: RE: [Syslog] RE: Request for Reviewers - draft-ietf-syslog-device -mib-09.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 13 Nov 2006 18:05:43 +0100

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:[email-masked]]
> Sent: Wednesday, November 08, 2006 14:56
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]
> 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
> >>>> [email-masked] 
> >>>> [email-masked]
> >>>> [email-masked]
> >>>>
> > 
> > _______________________________________________
> > Syslog mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/syslog
> 
> 

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