Re: DS MIB - please review this list...

[Fred Baker <fred@cisco.com>]

At 11:32 AM 2/24/2001 -0800, Andrew Smith wrote:
>>>7. There was a question on the list about why we have both
>>>diffServSixTupleClfrDstAddrType and diffServSixTupleClfrSrcAddrType
>>>instead of plain diffServSixTupleClfrAddrType
>>
>>Chnaged back to plain diffServSixTupleClfrAddrType

Folks, I'd appreciate your comment here. The reference is to the diffserv 
MIB, which you may find posted as draft-ietf-diffserv-mib-08.txt, and an 
update currently posted as 
ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-09.txt.

The data structure is a six-tuple filter - IP Addresses, port ranges, and 
so on.

DiffServSixTupleClfrEntry ::= SEQUENCE {
     diffServSixTupleClfrId           Unsigned32,
     diffServSixTupleClfrDstAddrType  InetAddressType,
     diffServSixTupleClfrDstAddr      InetAddress,
     diffServSixTupleClfrDstPrefixLength  INTEGER,
     diffServSixTupleClfrSrcAddrType  InetAddressType,
     diffServSixTupleClfrSrcAddr      InetAddress,
     diffServSixTupleClfrSrcPrefixLength  INTEGER,
     diffServSixTupleClfrDscp         DscpOrAny,
     diffServSixTupleClfrProtocol     Unsigned32,
     diffServSixTupleClfrDstL4PortMin SixTupleClfrL4Port,
     diffServSixTupleClfrDstL4PortMax SixTupleClfrL4Port,
     diffServSixTupleClfrSrcL4PortMin SixTupleClfrL4Port,
     diffServSixTupleClfrSrcL4PortMax SixTupleClfrL4Port,
     diffServSixTupleClfrStatus       RowStatus
}

In RFC 2851, there is a stricture, which Andrew calls out below, that says 
that we have to identify the type of an address twice in this data 
structure. In reality, it can only match an IPv4 header or an IPv6 header, 
and therefore the two addresses will invariably be in the same format.

Can you argue the case for the stricture, generally or (better) in this 
application? Are you trying to build a compound object or CHOICE (aka 
NetworkAddress) in an SMI which eschews both compound objects and 
CHOICE-typed objects? If so, wouldn't it be better to (finally) fix the SMI 
and leave this alone?

>I don't think we should make this change: if you look back at pre-history, 
>we had a single AddrType and we were asked (not sure by whom) to change it 
>to include separate ones for Src and Dst, so as to be consistent with the 
>usage described in RFC 2851. Here's the TC definition from there:
>
>InetAddress ::= TEXTUAL-CONVENTION
>      STATUS       current
>      DESCRIPTION
>          "Denotes a generic Internet address.
>
>           An InetAddress value is always interpreted within the
>           context of an InetAddressType value. The InetAddressType
>           object which defines the context must be registered
>           immediately before the object which uses the InetAddress
>           textual convention. In other words, the object identifiers
>           for the InetAddressType object and the InetAddress object
>           MUST have the same length and the last sub-identifier of
>           the InetAddressType object MUST be 1 less than the last
>           sub-identifier of the InetAddress object.
>
>           When this textual convention is used as the syntax of an
>           index object, there may be issues with the limit of 128
>           sub-identifiers specified in SMIv2, STD 58. In this case,
>           the OBJECT-TYPE declaration MUST include a 'SIZE' clause
>           to limit the number of potential instance sub-identifiers."
>      SYNTAX      OCTET STRING (SIZE (0..255))