Re: DISMAN-PING-MIB questions: default address type, message interval and pingCtlDSField

Hi -

> From: "Bill Fenner" <[email protected]>
> To: <[email protected]>
> Sent: Friday, October 27, 2006 12:11 PM
> Subject: [Disman] DISMAN-PING-MIB questions: default address type,message interval and pingCtlDSField
>
>
> I'm implementing a manager that uses the DISMAN-PING-MIB, and
> have three questions.
>
> 1. RFC 4560 says:
>           A single SNMP PDU can be used to create and start a remote
>    ping test.  Within the PDU, pingCtlTargetAddress should be set to the
>    target host's address (pingCtlTargetAddressType will default to
>    ipv4(1)), pingCtlAdminStatus to enabled(1), and pingCtlRowStatus to
>    createAndGo(4).
> However, the DEFVAL of pingCtlTargetAddressType is unknown, and
> that's the value that the agent I'm testing against uses when you
> don't specify it.  It seems that the agent is right, based on the
> MIB, and the text that says that the addresstype has a default of
> ipv4(1) is wrong?

It looks like this is a long-standing error in the document.  The same
problem exists in RFC 2925.  The error was introduced in the changes
from draft-ietf-disman-remops-mib-07.txt to produce the draft
draft-ietf-disman-remops-mib-08.txt. in August / Spetember of 2000.
The only relevant discussion I could find is in Ken White's
message of August 28, 1999 (see ftp://ftp.ietf.org/ietf-mail-archive/disman/)
and that doesn't explain why the change was made to the DEFVAL.

I can see two ways to correct this.  Either would result in an erratum:
  a) fix the DEFVAL, since the change wasn't agreed in the WG
      as far as I can tell (please correct me if I'm wrong and just
      couldn't find or remember the discussion).
  b) fix the single-PDU text.  someone will need to count the bytes
      to see if the additional varbind would take us over the limit.

> 2. There's no object that explicitly talks about the interval between
> probes when the probe is successful.  If I set pingCtlProbeCount=15 and
> leave pingCtlTimeOut=3, I naively assumed that when the probe response
> was received, it would wait less time (I assumed 1 second, since that's
> what UNIX ping defaults to) to send the next probe.  I thought that
> partly because of the wording in section 3.1.2:
>
>    Using the maximum value for the parameters defined within a pingEntry
>    can result in a single remote ping test's taking at most 15 minutes
>    (pingCtlTimeOut times pingCtlProbeCount), plus whatever time it takes
>    to send the ping request and to receive its response over the network
>    from the target host.
>
> If the probes are always spaced pingCtlTimeOut (plus RTT) apart, then
> this really means "*at least*" 15 minutes, right?  Saying "at most"
> made me think it could take 15 seconds if the tests completed
> successfully.

15 minutes is the largest amount of time that could be contributed to the
total time dues to the (pingCtlTimeOut times pingCtlProbeCount)
component.  The "plus" is an essential part of the total formulation.
Using "at least" would be wrong - 15 minutes is indeed the maximum
contributed by that component (it could be much less if smaller
values are chosen for pingCtlTimeOut or pingCtlProbeCount)
to the total time.

In short, the text looks ok to me.

> 3. I don't understand the discussion of the use of pingCtlDSField.
> Since zero is a valid value for the DSCP/ToS field in the IP header,
> and is in fact the value that most senders fill in, I don't understand
> how zero can mean that this function of filling in the DSCP/ToS field
> is not supported.  The DESCRIPTION says:
>
>            This option can be used to determine what effect an
>            explicit DS Field setting has on a ping response.
>            Not all values are legal or meaningful.  A value of 0
>            means that the function represented by this option is
>            not supported.
>
> and the compliance says
>            OBJECT pingCtlDSField
>            MIN-ACCESS  read-only
>            DESCRIPTION
>                "Write access is not required.  If write access is
>                not supported, return a 0 as the value of this object.
>                A value of 0 means that the function represented by
>                this option is not supported."
>
> Since the default value is zero, and zero is a valid value, a manager
> can't use the value of zero to know that write access is not
> supported.  In fact, the agent that I'm testing against puts zero
> into the row if the value isn't specified in the set that creates
> it (unsurprisingly, since that's the DEFVAL) but also supports write
> access:
>
> frogbits% ./pset 'pingCtlTargetAddressType."test"."test"' i ipv4 'pingCtlTargetAddress."test"."test"' x c014e128
'pingCtlRowStatus."test"."test"' i createAndWait
> DISMAN-PING-MIB::pingCtlTargetAddressType."test"."test" = INTEGER: ipv4(1)
> DISMAN-PING-MIB::pingCtlTargetAddress."test"."test" = Hex-STRING: C0 14 E1 28
> DISMAN-PING-MIB::pingCtlRowStatus."test"."test" = INTEGER: createAndWait(5)
> frogbits% ./pget 'pingCtlDSField."test"."test"'
> DISMAN-PING-MIB::pingCtlDSField."test"."test" = Gauge32: 0
> frogbits% ./pset 'pingCtlDSField."test"."test"' u 160
> DISMAN-PING-MIB::pingCtlDSField."test"."test" = Gauge32: 160
>
> I'm inclined to simply ignore the claim that zero means not supported,
> and try to set it anyway and let an SNMP error tell me that it's not
> supported.  Is there anything wrong with that tactic?
...

Nope.  As I understand it...

The language could have been been better.
If the feature is not supported, the object should read as zero.
If read as zero, no conclusion is possible about whether the
feature is supported. If read as non-zero, the feature is supported.

Randy