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

[Michael Daniele <mwdaniele@adelphia.net>]

hi,

InetAddressType and InetAddress are a mechanism to form a
discriminated union.  they were defined in this manner primarily
to be unambiguous for MIB developers, and to model somewhat how
CHOICE would encode the same data.

yes, we could try to change the SMI.  but then you'd have to wait
for SNMPv4 (at the earliest).

yes, we did not necessarily need to require the "adjacency" of
type and address.

but i think it is the simplest and most easily documented mechanism,
and gives us the greatest chance for correct usage.

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

and if you only needed to specify one InetAddressType, you would save
a single sub-identifier.  is the situation then really that terrible?

regards,
mike


Fred Baker wrote:

> 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))