Re: Re: MIB Doctor review: publish draft-ietf-disman-remops-mib-v2-06.tx t

On Sun, Jul 10, 2005 at 01:44:13AM +0200, Juergen Quittek wrote:
> NEW
> pingCtlDSField OBJECT-TYPE
>    SYNTAX      Unsigned32 (0..255)
>    MAX-ACCESS  read-create
>    STATUS      current
>    DESCRIPTION
>        "Specifies the value to store in the Differentiated
>        Services (DS) Field in the IP packet used to
>        encapsulate the ping probe.  The DS Field is defined
>        as the first 6 bits of the Type of Service (TOS) octet
>        in the IPv4 header or as the first 6 bits of the
>        Traffic Class octet in the IPv6 header, respectively.

I suggest to replace "first 6 bits" with "six most significant bits"
to actually use the language proposed in RFC 3260.
 
>        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.  DS Field usage is often not supported
>        by IP implementations and not all values are supported.
>        Refer to RFC 2474 and RFC 3260 for guidance on usage of
>        this field.
> 
>        The value of pingCtlDSField corresponds to the value
>        of the TOS octet or the Traffic Class Octet,
>        respectively.  This implies that it has to be divided
>        by 4 (or bitwise shifted right by 2) in order to
>        extract the encoded DS Field value."

I think the first sentence can be misunderstood in the sense that 
the value of pingCtlDSField is actually copied to the value of
the TOS octet or Traffic Class Octet. What about this:

	 The most significant bits of the pingCtlDSField correspond
         to the six bits of the DS Field. The remaining two bits
         have no meaning and must be ignored."

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany