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