remaining remops MIB issues

Dear all,

After addressing the major issues raised by the MIB doctor for the
rmops MIB modules, there is still a list of minor issues for which
there are suggested solutions that need confirmation on this list.

Please have a look at the list below.  Particlarly, please check
the suggestion for the DESCRIPTION clause of object lookupCtlRc.

You will find all updates in

  <ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-disman-remops-mib-v2-07.txt>

The differences to version -06 are highlighted at

  <ftp://ftp.netlab.nec.de/pub/internet-drafts/diff-06-07.html>

Thanks,

    Juergen
-- 
Juergen Quittek        [email protected]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de


=======================================================
>> MIB review <draft-ietf-disman-remops-mib-v2-06.txt>:


>> - I am wondering what traceRouteCtlMiscOptions is good for other than
>>   proprietary extensions which IMHO should go into table augmentations.
>>   Otherwise, we could put opaque options in almost all tables. I suggest
>>   to document how this object is actually used by existing implementations
>>   or to deprecate or even obsolete it.

We had this discussion already on this mailing list and decided to keep
the object as it is.


>> - Saying "The compliance statement for the DISMAN-TRACEROUTE-MIB."  in
>>   the description clause of a compliance statement when there are
>>   multiple compliance statements for the same module is mildly
>>   confusing. I suggest to add more meat when this compliance statement
>>   applies. (I notice that this comment actually also applies to the
>>   other MIB modules - I am not repeating it there to save space and
>>   time.)

replaced OLD
            "The compliance statement for the DISMAN-NSLOOKUP-MIB."
with NEW
            "The compliance statement for SNMP entities which
            fully implement the DISMAN-NSLOOKUP-MIB."

and analogously changed the other two MIB modules.


>> - The minimum compliance statement correctly says that some objects
>>   must be readonly when some optional tables are not supported. I
>>   think some similar statements should be made for the full compliance
>>   statement since some tables are optionally there as well.

Fixed it for traceRouteHopsLastGoodProbe.


>> - The lookupCtlRc object suggests to report errno on systems
>>   that have it. Note that errno is only significant if the
>>   getnameinfo/getaddrinfo function returns EAI_SYSTEM. I think
>>   this object should be described in terms of the standard return
>>   codes of the getnameinfo/getaddrinfo functions.

Yes, the original DESCRIPTION clause
        "The system-specific return code from a lookup
        operation.  All implementations MUST return a value
        of 0 for this object when the remote lookup
        operation succeeds.  A non-zero value for this
        objects indicates failure.  It is recommended that
        implementations that support POSIX errno values
        as defined in IEEE standard 1003.1 use these values
        for this object to aid a management application in
        determining the cause of failure."
does not apply to getaddrinfo() and getnameinfo(), see RFC 3493.
It does not appear to be feasible to have common return codes for
different pplications.

Therefore, we should weaken the recommendation, for example like
        "The system-specific return code from a lookup
        operation.  All implementations MUST return a value
        of 0 for this object when the remote lookup
        operation succeeds.  A non-zero value for this
        objects indicates failure.  It is recommended that
        implementations return the error codes that are generated
        by lookup function used."


>> - Not sure what a primary host address is or how I determine that.

removed this term from object descriptions of pingCtlSourceAddress and
traceRouteCtlSourceAddress.