> -----Original Message----- > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 13, 2006 6:45 AM > To: [EMAIL PROTECTED] > Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 1,2,3 > > Hi, > I have pruned the list of comments and renumbered them. > The following starts the discussion on the points raised > in Dbh re-Review of -mib-11, part 2. > > Cheers > > Glenn > > > 2.3 > > 9) syslEntCtlStorageType - is this definition exactly the > > > same as the > > > StorageType T-C? > I am not sure this is the same semantics as StorageType T-C. > Your text is somewhat unclear when it says "backed up by > non-volatile (permanent)" > > Response: > Will the following help: > syslogEntityControlStorageType OBJECT-TYPE > SYNTAX StorageType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object defines whether the parameters defined in > this row are kept in volatile storage and lost upon > reboot or are backed up by non-volatile or permanent > storage. > Conceptual rows having the value 'permanent' need not > allow write-access to any columnar objects in the row. > " > > That mimics the DESCRIPTION used in DISMAN-MIB e.g. > smLaunchStorageType > That will do, yes.
> > 2.4 > > 11) syslEntStarted and syslEntStopped - spell out MO. I don't > > > understand the second sentence; how does the manager > know what > > > syslEntOpsIndex is used? > Partially fixed. I still do not understand the second > sentence. Can > you reword this sentence? > > Response: > When a trap is received, the NMS/Operator needs to > figure out which > syslog "entity" the trap is about. This is done by using the > syslogEntityOperationsIndex instance identifier of the objects in > the notification. > > Will the following help? > > "The syslog entity corresponding to the notification will be > identified by the syslogEntityOperationsIndex > instance identifier > of the objects in the notification." Yes. Thanks. > 2.6 > > 14) The MIB module exposes some info from syslog, such as > > > last error. > > > The security considerations talk about securing snmp, but > > > that does > > > not make sense if you do not also secure the syslog > transport. > > > The > > > security considerations should recommend securing syslog to > > > match the > > > snmp security. > Not fixed. > > Response: > To me that appeared to be out of scope. That seems to be a matter > for the "security considerations" for syslog transport. No? > > Will something like the following suffice: > > "Under some circumstances securing SNMP will not make sense if > the syslog transport is not secured. It is > recommended that the > syslog transport be secured to match the security > level of SNMP." Let me just withdraw my comment. If the IESG wants something here, they can request it. > > 2.7 > > 17) I suspect you are not usinng xml2rfc. If not, you need to > > > make > > > sure all the boilerplates are up-to-date. Please check the > > > funding > > > statement and the intellectual property clauses. > Partially fixed. Needs updated boilerplates. > > Response: > Updated the boilerplate for the Copyright notice. > http://tools.ietf.org/tools/idnits/ > shows zero errors now. > Good. > > > > > Glenn M. Keeni wrote: > > Dave, > > Thanks for the detailed review. I count a total of > > 13 + 7 + 4 = 24 issues raised in the three mails. Let > > me go through these and try to figure out how to address > > the issues, hopefully by 18/12/2006. > > > > Cheers > > > > Glenn > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
