Mike,
     Thanks for the comments. Most of these have been incorporated
into the revised -03- draft. That should appear in the archives
shortly.
     My comments are inline.

      Glenn

Mike MacFaden wrote:
> On Fri, Feb 14, 2003 at 04:53:41AM -0800, Chris Lonvick wrote:
>
>>- Glenn Mansfield Keeni has the syslog-mib draft here:
>> http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-02.txt
>>and is looking for comments.
>
>
> fwiw...
>
> 1) One syntax error in this mib module:
> smilint 0.4.1 reports one syntax error:
>    syslogAllowedHostsTable : SEQUENCE OF type does not match row type
> Should read as follows
> syslogAllowedHostsTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF SyslogAllowedHostsEntry
Done. [This one fooled the mib-module validator at
http://www.simpleweb.org/Docs/ietf/mibs/validate/]
>
> 2) For the counter objects such as syslogProcMsgsReceived,
> I don't see what object one would poll to discover discontinuities.
> example: ifCounterDiscontinuityTime/rfc2863
> I'd like to throw out invalid samples
> if a proc dies and then restarts between polls
> for some syslogProcIndex. I suggest using something like
>
>   syslogProcStartedAt
>        SYNTAX      TimeStamp
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The time which this process was started."
>        ::= { syslogProcEntry 7 }
Done. Added syslogProcStartTime            TimeStamp.
>
> Some implementations will set syslogProcIndex to an
> underlying process id (pid), but pids might be reused.
>
> 3) I'd prefer having two objects instead of one for
> syslogProcMsgsIgnored. Tracking badly formed messages versus
> a configuration error should be easier for operators to debug.
Done. Added  syslogProcMsgsIllFormed        Counter32.

>
> 4) I recommend adding REFERENCE clauses to your objects.
> That way two implementations will have a higher probability of
> reporting consistent results that way. See section 3.13.3 of
> the document listed below.
Fully agree. I have planned to do that. But a major part of this
work remains pending in the revised draft.
>
> 5) syslogParamsProcDescr: is this a user definable string or
> something an implementation is supposed to define?
This is a user definable string.

>
> 6) syslogParamsConfFileName/syslogParamsPIDFileName:
> what should be stored if the
> config is loaded into memory (embedded system?). Hint: See
> RMON rfc2021/1757 OwnerString for example.
Have clarified in the description clause as follows:
     DESCRIPTION
       "The fullpath name of the configuration file where the
        syslog process'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
        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.
       "
>
> 7) I don't see a way to adminstratively disable/enable a given
> syslog processes. (like send a SIGTSTP signal) or to report
> present state of process (maybe that would be in hrSWRunTable/rfc2790?
> If so, maybe need to have a foreign key object to access that table.
> Also maybe a foreign key to access the udpTable or tcpConnTable

Have added 'suspended(2)' state to the syslogParamsProcessStatus. This
will allow the change of process atate to suspended.
>
> 8) Please change the name from DRAFT-IETF-SYSLOG-MIB to just SYSLOG-MIB

Done.
>
> 9) Not sure how this mib module can report a failure condition if it fails
> to save a config to a given file as defined in a typical syslog.conf
> See section 3.11 in the document listed below.
Have added
              syslogProcLastError            Integer32,
              syslogProcLastErrorTime        TimeStamp,

These should take care of the error reporting. The enumeration of the errors
remains to be done. Will be done in the next draft. Having done that I think
that something like a syslogProcLastErrorMsg would be helpful.
>
> 10) I would specify if objects are modifiable when rowStatus = active
> (see rfc1757 for example). See section 3.7 in the document listed below.
Done. The corresponding descriptions are revised.
I will need to qualify that all Objects except syslogParamsProcessStatus
can be modified only by deleting the row and recreating it.
syslogParamsProcessStatus can be changed even when syslogParamsRowStatus
is active.
>
> 11) On IP routers, one often wants to set the source ip address
> to use when sending via udp. Don't see how to set that here.

Done. Now we have  syslogCtlFwdActionSrcAddr in the syslogCtlFwdActionTable
that allows the specification of a source ip address.

>
> There might be other useful hints in Section 3 of:
> http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-bcp-12.txt

Thanks.




Reply via email to