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

--On 7/9/2005 11:20 PM +0200 Juergen Schoenwaelder wrote:

> On Sat, Jul 09, 2005 at 06:20:44PM +0200, Juergen Quittek wrote:
>
>> Please find replies on Juergen's comments below.
>> I will cover a few of the comments in separate messages.
>
> I will only respond to those things where I believe the proposed
> resolution needs more discussion or you are expecting input from
> me. (Means I am happy with the other proposed edits.)
>
>> Would you be fine with
>> OLD
>>   In addition, the DISMAN-PING-MIB module and the DISMAN-TRACEROUTE-MIB
>>   modules each have a deprecated compliancy statement that was current
>>   in RFC 2925.
>> NEW
>>   In addition, the DISMAN-PING-MIB module and the DISMAN-TRACEROUTE-MIB
>>   modules each have a deprecated compliancy statement that was current
>>   in RFC 2925. Semantically, the new full compliancy statements are
>>   identical with the deprecated ones. But the object groups in the
>>   compliancy sections needed to be restructured which is reflected by
>>   the new full compliancy statements.
>
> This is precisely what I was looking for as it tells me why the original
> compliance statement has been deprecated. Thanks.
>
>> > - The description of the DSCP parameter needs to be reworked to
>> >  actually match RFC 3260. Note that there are actually only 6 bits
>> >  and not 8 bits.
>>
>> Suggestion: let's use the TC Dscp from MIB module DIFFSERV-DSCP-TC
>> (RFC 3289) for the SYNTAX clause and add RFC 3260 to the references:
>
> [...]
>
> This unfortunately does not work as you are changing the encoding on
> the wire. Unsigned32 has a different tag than Integer32. So we have
> to keep our own definition and we have to align the description
> clause with the current RFC 3260 terminology.

I see.
It is not just the data type.  Also the bits are shifted.

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 }


Thanks,

    Juergen Q.
-- 
Juergen Quittek        [email protected]        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de