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?

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.

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?

Thanks,
  Bill