[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: InetAddressType and InetAddress



At 03:18 AM 11/17/2002 +0100, Wijnen, Bert (Bert) wrote:
>What do we do with this....
>
>If someone wants to limit the values for InetAddressType and
>InetAddress to a subset of those defined in INET-ADDRESS-MIB,
>then my current recommendation is this (example from diffserv)
>
>  diffServMultiFieldClfrAddrType OBJECT-TYPE
>    SYNTAX         InetAddressType
>    MAX-ACCESS     read-create
>    STATUS         current
>    DESCRIPTION
>       "The type of IP address used by this classifier entry.  While
>       other types of addresses are defined in the InetAddressType
>
>
>       textual convention, and DNS names, a classifier can only look at
>       packets on the wire. Therefore, this object is limited to IPv4
>       and IPv6 addresses."
>    ::= { diffServMultiFieldClfrEntry 2 }
>
>  diffServMultiFieldClfrDstAddr OBJECT-TYPE
>    SYNTAX         InetAddress
>    MAX-ACCESS     read-create
>    STATUS         current
>    DESCRIPTION
>       "The IP address to match against the packet's destination IP
>       address. This may not be a DNS name, but may be an IPv4 or IPv6
>       prefix.  diffServMultiFieldClfrDstPrefixLength indicates the
>       number of bits that are relevant."
>    ::= { diffServMultiFieldClfrEntry 3 }
>
>And then in the MODULE-COMPLIANCE they sepcify:
>
>    OBJECT diffServMultiFieldClfrAddrType
>    SYNTAX  InetAddressType { unknown(0), ipv4(1), ipv6(2) }
>    DESCRIPTION
>       "An implementation is only required to support IPv4 and IPv6
>       addresses."
>
>    OBJECT diffServMultiFieldClfrDstAddr
>    SYNTAX  InetAddress (SIZE(0|4|16))
>    DESCRIPTION
>       "An implementation is only required to support IPv4 and globally
>       unique IPv6 addresses."
>
>Sofar so good. But now what if one wants to use the same thing for
>an InetAddressType and an InetAddress that are used as INDEX objects.
>Cause now:
>- one needs to limit the size of InetAddress to not go over 128 subids
>  (I know some find this a CLR... so we could do away with it)
>- one cannot include INDEX objects (not-accessible) in the 
>  MODULE-COMPLIANCE. 
>
>So what do we do about this. I thought I had brought this up with someone
>(Juergen? or mibs list) some time ago, but I cannot find the discussion
>and or outcome in my mail archives.

This issue comes up in Cisco MIB reviews all the time.
We routinely put OBJECT clauses like you have above in
the DESCRIPTION clause of the MODULE-COMPLIANCE statement.
(Take out the double quotes of course.)

The SMI should be changed to allow OBJECT clauses for INDEX
objects.  There is no reason they should be prohibited because
an INDEX object is prohibited from being present in an
OBJECT-GROUP list.  While I'm on a rant, forcing INDEX objects
to (usually) be MAX-ACCESS not-accessible is one of the dumbest
things we ever did in the SMI.  All of these CLRs (and 100s more!)
make MIB writing confusing.  I want the SMIng WG to rewrite
RFC 2580 (but that's another thread ;-) 

>The question is imminent, cause I have the malloc MIB on the IESG agenda
>
>    draft-ietf-malloc-malloc-mib-07.txt
>
>Thanks,
>Bert 

Andy