[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.1 > > 5) is there a mismatch between transportaddresstype and
    > > syslEntCtlService? Is there a transportAddressType for this
    > > type of
    > > "address"?
    Not fixed.
    I think you are using an enumeration to identify the format of the
    value in the next object, and then using a format in the next object
    that does not match any of the enumerated choices. This is obviously
    wrong.

Response:
    That is not what we are doing.

    syslogEntityControlTransportDomain maps onto a transport domain.
          e.g. transportDomainUdpIpv4
    syslogEntityControlService maps onto a port number
          e.g. 512

    Let me know if I got this wrong.


2.2 > > 6) syslEntCtlConfFileName - using lots of abbreviations in
    > > the  name
    > > makes it hard for people to remember how the words were
    > > abbreviated.
    > > It would be better to use something like syslogEntCtlFilename.
    > > Why do
    > > we need Ent in the name? we never deal with anything other than
    > > entities, do we? syslogControlFile would be much easier to
    > > remember
    > > than syslEntCtlConfFileName.
    Fixed (mostly).

Response:
    What is the remaining problem?

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


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."

2.5 > > 13) why are notifications not mandatory for compliance?
    syslogFullCompliance2 says this means support for writable
    objects and
    notifications, but th enotification group has been left out
    of the manadatory-groups.

    If the intention is to leave out the notification, I would like to
    know why this is desirable.

Response:
    The intention is to leave out the notification.

      syslogFullCompliance2 MODULE-COMPLIANCE
          STATUS  current
          DESCRIPTION
              "The compliance statement for SNMP entities which
               implement the SYSLOG-MIB with support for writable
               objects. Such an implementation can
               be both monitored and configured via SNMP.
              "
          MODULE -- this module
          MANDATORY-GROUPS {
              syslogDefaultGroup,
              syslogEntityOperationsGroup,
              syslogEntityControlGroup
          }
          ::= { syslogCompliances 2 }

    The reason is to retain the possibility of a compliant
    implementation that does not support notifications.

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."

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.





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