RE: pingCtlDSField in remops

If there is a need for a Dscp semantics only TC, why not use Dscp or
DscpOrAny from DIFFSERV-DSCP-TC (RFC 3289) which is imported by other
MIB modules. Alternatively, if the semantics covers the whole TOS
object, I would prefer to see a less Ping MIB oriented name and
semantics, that the TC could be imported for more generic TOS purposes,
like the sspmSourceProfileTOS in
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-rmonmib-ssp
m-mib-12.txt.

Regards,

Dan


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Randy Presuhn
> Sent: Sunday, July 10, 2005 3:59 AM
> To: [email protected]
> Subject: [Disman] 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
> 
> 
> 
> 
>