[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog] Dbh re-Review of -mib-11, part 1,2,3
> -----Original Message-----
> From: Glenn M. Keeni [mailto:glenn@cysols.com]
> Sent: Wednesday, December 13, 2006 6:45 AM
> To: syslog@ietf.org
> 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