Subject: <draft-ietf-disman-remops-mib-07.txt> comments

From: [email-masked]
Date: Thu, 17 Feb 2000 08:16:47 -0500

Hi,

I would like to thank David Partain for his review. The following are his
comments with their proposed
resolution:

David>Here are the issues that I've found.  After this (brief) list,
David>you'll find language edits in the form of a unified diff.  If you
David>wish to have some other form for this information, please let me
David>know.

David>1. pingCtlTrapGeneration is a BITS object, which means that all
David>   three of the options (probeFailure, testFailure,
David>   testCompletion) can be set at the same time.  This seems wise
David>   since you might want all three kinds of notifications.
David>   However, pingCtlTrapFilter is supposed to be used to control
David>   both when the probeFailure and testFailure traps are sent.
David>   That is, you cannot control sending of both probeFailure and
David>   testFailure separately.

Right. The filter object applies to both. I agree that it would be better
to break this object in to two and proposed replacing pingCtlTrapFilter
with pingCtlTrapProbeFailureFilter and pingCtlTrapTestFailureFilter:

 pingCtlTrapProbeFailureFilter OBJECT-TYPE
    SYNTAX      Unsigned32 (0..15)
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The value of this object is used to determine when
        to generate a pingProbeFailed NOTIFICATION.

        Setting pingCtlTrapGeneration
        to probeFailure(0) implies that a pingProbeFailed
        NOTIFICATION is generated only when the number of
        successive probe failures as indicated by the
        value of pingCtlTrapProbeFailureFilter fail within
        a given ping test."
    DEFVAL { 1 }
    ::= { pingCtlEntry 14 }

 pingCtlTrapTestFailureFilter OBJECT-TYPE
    SYNTAX      Unsigned32 (0..15)
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The value of this object is used to determine when
        to generate a pingTestFailed NOTIFICATION.

        Setting pingCtlTrapGeneration to testFailure(1)
        implies that a pingTestFailed NOTIFICATION is
        generated only when the number of ping failures
        within a test exceed the value of
        pingCtlTrapTestFailureFilter."
    DEFVAL { 1 }
    ::= { pingCtlEntry 15 }

David>   Is this intentional or am I missing something?

Its what was intended. I think two objects instead of 1 is an improvement.

David>   Was the thinking perhaps that you could only set to one of
David>   these?  If so, it needs to be INTEGER.  If not, there need to
David>   be two filter objects.

No. All of the BITS options can be selected. The filter object was
intended to apply to both pingProbeFailed and pingTestFailed NOTIFICATION
generation.

David>2.
David>   a. Shouldn't the syntax of pingCtlSourceAddress be
David>      IpHostAddress if you're going to require that it be an IP
David>      address in numeric form?

Yes, thanks for catching this. I've made the change.

David>   b. Also, this object says in its description, "The address
David>      type (HostAddressType) that relates to this object is
David>      specified by the corresponding value of
David>      pingCtlTargetAddressType."  That seems wrong to me.  Why
David>      should the target address type be the same as the source
David>      address type?  That would mean that I cannot ping an IPv6
David>      machine from an IPv4 machine.  Furthermore,
David>      pingCtlTargetAddressType would also include DNS names,
David>      which are explicitly excluded from the possibilities for
David>      pingCtlSourceAddress.

There are two issues here. First is should the source address object
allow use of DNS names. I think not since in this case you would use
this option to force what IP address gets set in the packet and not
want to use DNS to resolve to an address. The second part to this is
should the type of address be restricted to be the same as that of
the target address. I think it would be better to remove this restriction.
A type object wouldn't be needed since if we don't allow DNS names then
the length of the octet string would be sufficient to determine type.

David>3. The same comment as 2.b applies to traceRouteCtlSourceAddress.

Agreed.

David>4. It doesn't seem very reasonable to me that you'd want 4billion
David>   rows in a table.  Any reason pingCtlMaxRows isn't limited?  Is
David>   it just that getting agreement on what it would be would be
David>   difficult?

David>   The same applies to the other MaxRows objects.

Its been a while but I think I had limits that due to discussion
were taken out. Basically, isn't this essentially implementation
dependent?

David accepted this response.

David>5. In several places, Counter32 objects are assigned an initial
David>   value.   This is in contradiction with RFC 2578, page 23,
David>   which states, "Counters have no defined "initial" value, and
David>   thus, a single value of a Counter has (in general) no
David>   information content."  In practice, I doubt that what is in
David>   this document is a problem, but the fact that
David>   traceRouteHopsProbeResponses is zero could either mean that
David>   it's just been initialized or that there have been 4294967295
David>   previous responses and we've just wrapped.

David>   So, although I think it's not going to be a practical problem,
David>   it does not strictly follow the SMI.

I understand that counters have to be polled in order to determine
deltas within an interval however the "counters" in this case indicate
where you are in a test. I think it would be OK to change the following
objects to Unsigned32:

     pingResultsProbeResponses
     pingResultsSentProbes
     traceRouteResultsTestAttempts
     traceRouteResultsTestSuccesses
     traceRouteHopsSentProbes
     traceRouteHopsProbeResponses

David>6. It is conceivable that some lookup implementations might
David>   return a negative number to be put into lookupCtlRc.  Perhaps
David>   Integer32 is better than Unsigned32.

Right. Glade you caught this. The text talks about negative values while
the TC is incorrect. I have changed it to Integer32.

David>If you so desire, I can go through it again, but I believe that
David>the MIBs are fundamentally sound and implementable.  Obviously, I
David>haven't implemented them, but I believe that I could in a fairly
David>straightforward manner.

David>I've compiled all three modules with both mosy and smicng with no
David>problems.  I don't have a version of smicng that supports RFCs
David>2578-80 (no one but d.perkins does) though.

David also recommended that the REMOPS MIBs use the textual conventions
as defined within the endpoint MIB:

draft-ops-endpoint-mib-06.txt        | draft-ietf-disman-remops-mib-07.txt
                                     |
InetAddressType ::= TC               | HostAddressType ::=
TEXTUAL-CONVENTION
    SYNTAX  INTEGER {                |   SYNTAX  INTEGER {
              unknown(0),            |     none(0),
              ipv4(1),               |     dnsName(1),
              ipv6(2),               |     ipv4(2),
              dns(16)                |     ipv6(3)
            }                        |   }
                                     |
InetAddress ::= TC                   | HostAddress ::= TEXTUAL-CONVENTION
    SYNTAX                           |  SYNTAX
     OCTET STRING (SIZE (0..255))    |    OCTET STRING (SIZE (0..255))
                                     |
                                     |
none                                 | IpHostAddress ::= TEXTUAL-CONVENTION
                                     |   DESCRIPTION
                                     |   "The textual convention for
                                     |   specifying an IP host address.
                                     |   The type of address can be
                                     |   determined by the octet string
                                     |   length:
                                     |     OCTETs    ADDRESS TYPE
                                     |     0       not specified
                                     |     4          ipv4
                                     |     16          ipv6"
                                     |     SYNTAX OCTET STRING (SIZE
(0..16))
                                     |

Since IpHostAddress doesn't have a corresponding TC in the endpoint MIB the
best solution would be to add a corresponding type object using the
InetAddressType TC, convert use of HostAddress to InetAddress and then in
the compliance statements indicate that only a subset of the address types
must
be implemented.

Bert wants the following changes made:

- import mib-2 instead of experimental,
- use   ::= { mib-2 xx } -- to be assigned by IANA
- add a REVISION clause aka:
       REVISION     "200001210000Z"-- same date/time as LAST-UPDATED
       DESCRIPTION-- XXXX assigned by RFC Editor
           "Initial version, published as RFC XXXX."

I have made these changes. Unless I hear objections to the proposed changes
I will
update the I-D and submit a new draft in the next week or so,

Ken

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Feb 2000 15:53:20 +0100

>>>>> wkenneth  writes:

David> b. Also, this object says in its description, "The address type
David> (HostAddressType) that relates to this object is specified by
David> the corresponding value of pingCtlTargetAddressType."  That
David> seems wrong to me.  Why should the target address type be the
David> same as the source address type?  That would mean that I cannot
David> ping an IPv6 machine from an IPv4 machine.  

[...]

Note that the latest ID of the endpoint MIB requires that you have
InetAddressType/InetAddress pairs.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>