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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

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