FYI - I had recommended option 1.
/gww
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Friday, February 28, 2003 13:21
> To: Mreview (E-mail)
> Subject: FW: Question regarding address specs for IPv4-only protocol MIBs
>
> I have not checked the document yet... (I am in a conf call
> right now). But from the email text, I think option 1
> seems OK. Any objections (with arguments please).
>
> RFC3291 does not explicitly state this is allowed, but I think
> it is reasonable.
>
>
> Thanks,
> Bert
>
> -----Original Message-----
> From: Barr Hibbs [mailto:rbhibbs@pacbell.net]
> Sent: vrijdag 28 februari 2003 18:53
> To: Bert Wijnen (Bert)
> Cc: Richard Woundy; Glenn Waters
> Subject: Question regarding address specs for IPv4-only protocol MIBs
>
>
>
> Bert--
>
> my apologies for posing this last-minute question.
>
> Glenn Waters and I are the editors of an existing MIB draft,
> "draft-ietf-dhc-server-mib-07.txt" that we're about to update to the "-08"
> revision for submittal before the San Francisco working groups meeting.
> Rich Woundy has been acting as a third voice during the editing process.
>
> 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.
>
> 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.
>
> 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.)
>
> I support alternative one. Glenn also supports alternative one, agreeing
> with me that this subtree is very unlikely to have any reuse for DHCPv6.
> Rich agrees that the subtree will not be applicable to DHCPv6, but thinks
> that alternative two may be preferable.
>
> So, we are kicking the question to you for some guidance.
>
> As we wish to make the final I-D cutoff with the "-08" revision, if we do
> not have a reply from you, we'll submit the draft using alternative one
> and
> risk having to make later changes and resubmit.
>
> Thanks in advance for your guidance,
>
> --Barr Hibbs
> +1-(415)-648-3920