Re: FW: Question regarding address specs for IPv4-only protocol MIBs

["C. M. Heard" <heard@pobox.com>]

On Fri, 28 Feb 2003, Barr Hibbs (via Bert Wijnen) wrote:
> The focus of the MIB is for a DHCPv4 server.
> 
> Because there are so many fundamental differences between the v4
> and v6 protocols for DHC, we specifically chose to limit this
> MIB to DHCPv4 servers.  The memo defines two textual conventions
> which could be applicable to any DHC protocol device (servers,
> clients, and relay agents for v4 and v6) and defines two
> subtrees that are likewise pretty generic.
> 
> Only one subtree, for server configuration information, contains objects
> that represent IP addresses.
> 
> As the protocol messages, method of address allocation, and
> methods of identifying clients and leases are completely
> different between DHCPv4 and DHCPv6, we believe that this
> subtree could only be used for a DHCPv4 server.
> 
> Given that, our recent attempts at revising the "-07" draft to
> produce a new version have become clouded vis-à-vis the question
> of how to specify addresses in this subtree.
> 
> Alternative One:  specify the addresses using the
> InetAddressIPv4 convention -- this is, perhaps, the simplest
> approach.

For something that is IPv4-specific, this (IMnsHO) is the way to go.
I can see no downside at all.  (In fact for this application even
IpAddress would actually work just fine, although its use in new MIB
modules is discouraged because InetAddressIPv4 does the same job for
the same cost.)

> Alternative Two:  specify the addresses using the pair
> InetAddressType and InetAddress, including the enumeration
> clause "{ ipv4(1) }" for InetAddressType and the size clause
> "(SIZE(4))" for InetAddress, along with the text "An
> implementation is only required to support IPv4 addresses" in
> each object description -- this is slightly misleading because
> the subtree is not intended to ever be used for IPv6.

Having an InetAddressType variable which is allowed to assume only
one value adds no benefit whatsoever, at least as far as I can see.

> Alternative Three:  specify the addresses as in Two, but without
> the restricting enumeration and size clauses, adding explanatory
> text to the conformance section -- this unfortunately causes the
> OID subidentifier strings used in the index of four tables to
> exceed the maximum size (by as much as 382.)

This is a bad idea because it permits implementation of address
types other than the ones for which the MIB subtree is designed.  
The possibility of OID string overflow due to the lack of explicit
SIZE constraints is a red herring; I expect that 3291bis won't have
the same strong MUST language regarding SIZE constraints for
InetAddressType index items that RFC 3291 has, since one can get the
same result via other means.  But that's another discussion (see my
comments on 3291bis sent to the mibs@ops.ietf.org list).

Well, that's one mib reviewer's opinion, anyway.

Mike Heard