pingCtlDSField in remops

Hi -

> From: "Juergen Quittek" <[email protected]>
> To: <[email protected]>; "Juergen Quittek" <[email protected]>
> Cc: <[email protected]>
> Sent: Saturday, July 09, 2005 4:44 PM
> Subject: Re: [Disman] Re: MIB Doctor review: publishdraft-ietf-disman-remops-mib-v2-06.tx t
...
> Here is something that should be compatible with the old definition:
>
> OLD
>  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 Type of Service (TOS) octet in a IPv4 header
>         or as the Traffic Class octet in a IPv6 header.
>
>         The value of this object must be a decimal integer
>         in the range from 0 to 255.  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 for
>         guidance on usage of this field."
>     REFERENCE
>         "Refer to RFC 2474 for the definition of the
>         Differentiated Services Field and to RFC 1812
>         Section 5.3.2 for Type of Service (TOS)."
>     DEFVAL { 0 }
>     ::= { pingCtlEntry 22 }
> 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.
>
>         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."
>     REFERENCE
>         "Refer to RFC 2474 and RFC 3260 for the definition of
>         the Differentiated Services Field."
>     DEFVAL { 0 }
>     ::= { pingCtlEntry 22 }
...

The added text makes it sound like this object is only about the DSCP,
rather than the entire TOS octet.  I think this matters because the
two bit positions that RFC 2474 and 3260 call "currently unused" that
are in fact used by RFC 3168 for ECN.

With perfect foresight we should have made this into two objects, but
we didn't.  I think the next best thing is to say that the six high bits go
to the DSCP, and the two low bits go to the ECN field, which would be
more consistent with this object's original definition in terms of the
TOS octet, rather than just talking about DSCPs.

I suggest adding text and a reference to RFC 3168 for the two
low-order bits.

Randy