Subject: Re: rfc2925 - pingMIB - when do I flag error?

From: "Kenneth White" <[email-masked]>
Date: Thu, 31 May 2001 10:51:47 -0400

Hi,

>pingMIB rfc2925

>This is a pretty simple question, but long to explain.  So, I have
>some specific cases that if you can answer, will clear up the issue
>perfectly.

>From what I can tell, there are three ways to tell the user that
>something they have set in a pingCtlEntry is wrong:
>    - when they send the Set PDU for the pingCtlEntry MIB object,
>               reject that Set PDU with an error
>    - when they set pingCtlRowStatus to "active" for that row,
>               reject that Set PDU with an error
>    - after the test is started,
>               on each probe, mark pingProbeHistoryStatus with
>               the appropriate error (OperationResponseStatus)

>I have some specific cases where it is ambiguous on what I should do.

>Case 1.  Set pingCtlTargetAddress to a multicast address.

>Case 2.  Set pingCtlSourceAddress to a multicast address.

>Case 3.  Set pingCtlSourceAddress to an address that is not one of the
>         machine's interface addresses.

> MIB says:

> pingCtlTargetAddress OBJECT-TYPE
>    DESCRIPTION
>        "Specifies the host address to be used at a remote host for
>        performing a ping operation.  The host address type is
>        determined by the object value of corresponding
>        pingCtlTargetAddressType.
>        A value for this object MUST be set prior to transitioning
>        its corresponding pingCtlEntry to active(1) via
>        pingCtlRowStatus."

>  pingCtlSourceAddress OBJECT-TYPE
>    DESCRIPTION
>        "Use the specified IP address (which must be given
>        in numeric form, not as a hostname) as the source
>        address in outgoing probe packets.  On hosts with
>        more than one IP address, this option can be used
>        to force the source address to be something other
>        than the primary IP address of the interface the
>        probe packet is sent on.  If the IP address is not
>        one of this machine's interface addresses, an error
>        is returned and nothing is sent.  A zero length
>        octet string value for this object disables source
>        address specification.

>        The address type (InetAddressType) that relates to
>        this object is specified by the corresponding value
>        of pingCtlSourceAddressType."

>   MIB also says:
>   OperationResponseStatus ::= TEXTUAL-CONVENTION
>    DESCRIPTION
>         invalidHostAddress(11) - The IP address for a host
>              has been determined to be invalid.  Examples of this
>              are broadcast or multicast addresses."

>The only place OperationResponseStatus is used in the MIB is
>pingProbeHistoryStatus.  But, this assumes that test has started.
>If the test never starts, there are no pingProbeHistory entries.

>So, how do I flag the error each of these cases?

>Case 1.  Set pingCtlTargetAddress to a multicast address.

>    When user sets pingCtlTargetAddress
>    - I don't look at pingCtlTargetAddressType until the user tries to
>      set the row to active.  So, I have no way of knowing what the
>      data in pingCtlTargetAddress means until that time.  At that
>      point, I can evaluate if it is a multicast address
>    When user set RowStatus to active
>    - At this point, the test has not started.  There is not way for
>      me to relay to the user the error code "invalidHostAddress",
>      which seems to be the correct error for this scenario
>    After the test has started
>    - I can mark each pingProbeHistoryStatus of each
>      pingProbeHistoryEntry with "invalidHostAddress" for this test.
>      It seems pointless to go through the motions of the test when I
>      know it is going to fail for each probe.

>    Question 1.  Which one of the above do I do?

How about creating a single pingProbeHistoryEntry with a
pingProbeHistoryIndex
of 1 with pingProbeHistoryStatus set to invalidHostAddress(11). There would
be only the single entry.

>Case 2.  Set pingCtlSourceAddress to a multicast address.

>    Much like Case 1, except I can infer what the address type is
>    when user sets pingCtlSourceAddress because the MIB says:
>     "Use the specified IP address (which must be given
>      in numeric form, not as a hostname) as the source address"
>    However, this would be inconsistent with how errors are flagged
>    on pingCtlTargetAddress.

>    Question 2.  Should I handle Case 2 just like Case 1?
>    Question 3.  Is invalidHostAddress appropriate in indicating
>                 incorrect values for both pingCtlTargetAddress and
>                 pingCtlSourceAddress, or was it meant to indicate
>                 errors on only pingCtlTargetAddress?

>Case 3.  Set pingCtlSourceAddress to an address that is not one of the
>         machine's interface addresses.

>    The description of pingCtlSourceAddress (above) says:

>    "If the IP address is not
>     one of this machine's interface addresses, an error
>     is returned and nothing is sent."

>    Question 4.  Does that mean:
>        A.  flag an error immediately when pingCtlSourceAddress is set
>         B.  flag an error when RowStatus is set to active and don't
>             send any probes or create any pingProbeHistoryEntry's
>         C.  don't send any probles, but create pingProbeHistoryEntry's
>             at the specified interval
>             each with the pingProbeHistoryStatus == invalidHostAddress
>    B. seems like the right answer.  C seems silly

Case 2 and 3 are really the same. How to handle an invald source address.
My opinion is that if you can detect the error when the set is made then
reject the set on the source address object. If you can't during the set
then use the approach as with case 1 and create an historyEntry with an
error status. The intent, at least in my mind, was that the enumerations
for OperationResponseStatus would grow over time.

Regards, Ken

---

From: Paul Fraley <[email-masked]>
Date: Thu, 31 May 2001 11:42:22 -0700

Just FYI,

based on K. White's response, this is what I chose to do.

If see something glaring wrong, let me know.

Assumptions:
------------
    - I am assuming three ways to tell user of an error
        A. error on the Set PDU of variable in error
        B. error on the Set PDU of RowStatus variable to active
        C. when user does Set PDU on AdminStatus variable to enabled,
           "start" the test (accept the set without error), create the
           pingProbeResultsEntry and one pingProbeHistoryEntry setting the
           pingProbeHistoryStatus to the correct error

    - the validity of a value when you set the value and when the test
      is actually run are two different things.  Example, what may be an
      invalid interface index for pingCtlIfIndex when the variable is set
      may be valid when the test is actually run.

    - I can not intrepret an address if I do not know what type of the
      address is.  I can not assume that what is placed in AddressType is
      what the user wants until the user attempts to set RowStatus to active

In the table below, there is the error Scenario, the Method by which telling
the user there was an error and the Error Code the user sees.

Scenario                                         Method  Error Code
-------------------------------------------------   ---  -----------------
 1 fail to set pingCtlTargetAddress or              B    InconsistentValue
   pingCtlTargetAddressType

 2 set pingCtlSourceAddressType but do not               no problem
   set pingCtlSourceAddress

 3 set pingCtlSourceAddress but do not              B    InconsistentValue
   set pingCtlSourceAddressType

 4 set pingCtlTargetAddress to multicast address    B    InconsistentValue

 5 set pingCtlSourceAddress to multicast address    B    InconsistentValue

 6 set pingCtlTargetAddress to broadcast address    C    invalidHostAddress

 7 set pingCtlSourceAddress to broadcast address    C    invalidHostAddress

 8 set pingCtlSourceAddress to an address that does C    invalidHostAddress
   not correspond to any interface on this host

 9 specify pingCtlIfIndex, interface not active     C interfaceInactiveToTarget

10 specify pingCtlIfIndex interface non-existant    C interfaceInactiveToTarget

11 set pingCtlTargetAddressType to something        A    wrongValue
   besides unknown(0), ipv4(1), ipv6(2), dns(16)

12 set pingCtlSourceAddressType to something        A    wrongValue
   besides unknown(0), ipv4(1), ipv6(2)

13 set pingCtlTargetAddress or pingCtlSourceAddress A    wrongLength
   to a value that is larger than 255 bytes

14 set pingCtlTargetAddressType to dns(16)          C    unableToResolveDnsName
   set pingCtlTargetAddress to a hostname that can
   not be resolved

Issues:
-----------------
- where is unknownDestinationAddress used?
- should scenarios 4,5 be handled like 5,6?