RE: Initial review of draft-nelson-rfc2618bis-00.txt

["David B Harrington" <ietfdbh@comcast.net>]

Hi Dave,

Everybody is a little fuzzy on MIB rules ;-)
I am copying my response to the MIB Doctors, to see if they have any
different recommendations.

If you are going to copy the RFC2618 mib module into your document,
then to deal with the upgrade from IPv4-only support to IPv4/v6
support, you should:

1) deprecate the IPAddress object (radiusAuthServerAddress)

2) add the new InetAddress objects (radiusAuthServerInetAddressType
and radiusAuthServerInetAddress) to the original table, as Mike
suggested.

3) Is there a semantic difference between
radiusAuthClientServerPortNumber and
radiusAuthClientServerInetPortNumber? I personally recommend against
defining a new port object just because it keeps the port and address
together, but other MIB Doctors might advise you to make the change of
port while changing the address anyway.

4) write a compliance clause that calls for use of the new object, not
the old. Deal with backwards compatability by deprecating the old
compliance clause and add a new compliance clause that includes the
new address objects and does not include the deprecated object.
Implementations can always support both compliance clauses if they
choose.

5) In the DESCRIPTION clause of the table or the entry, or in comments
contained within the MIB module, you could suggest that
implementations which choose to support both compliance clauses SHOULD
mirror IPv4 addresses in both the old and new objects. 

You also need to discuss what should be done when there is a non-IPv4
InetAddress - I presume in this case the old object should *not be
instantiated* - a query for that object will not return any
radiusAuthServerAddress, and will return an SNMPv3 exception
(noSuchInstance, I think) or an SNMPv1 error (noSuchName, I think).
(It would be incorrect to do something like return a
radiusAuthServerAddress of 0.0.0.0).

I think you would also need to specify that an implementation MUST NOT
have different addresses in radiusAuthServerAddress and
radiusAuthServerInetAddress. It would probably be acceptable to have
an IPv6-formatted IPv4 address in the InetAddress and the IPv4 format
of the same address in the IPAddress object.

Note from RFC3291:
"A single host system may be configured with multiple addresses (IPv4
   or IPv6), and possibly with multiple DNS names.  Thus it is
possible
   for a single host system to be accessible by multiple
   InetAddressType/InetAddress pairs.

   If this could be an implementation or usage issue, the DESCRIPTION
   clause of the relevant objects must fully describe which address is
   reported in a given InetAddressType/InetAddress pair."

So it is possible that there is an IPv6 InetAddress, and
radiusAuthServerAddress COULD be used to store the IPv4 address of the
same server; I feel uneasy about doing this, because it would tend to
prolong the use of the deprecated radiusAuthServerAddress object, and
would have forward-compatibility issues for applications that only
supported the InetAddress objects, and only supported IPv4
communications; it could not retrieve the IPv4 address of the server.
I would prefer to see one row for the IPv6 InetAddress, and another
row for the IPv4 InetAddress.

In any case, the MIB module (when separated from the surrounding text)
should be clear on how this should be handled.

David Harrington
dbharrington@comcast.net

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Wednesday, May 11, 2005 11:16 AM
> To: ietfdbh@comcast.net
> Subject: RE: Initial review of draft-nelson-rfc2618bis-00.txt
> 
> Hi Dave,
> 
> So...  I'm going to implement the MIB Doctor recommendations for the
> updated RADIUS MIBs.
> 
> In summary, the drafts will contain the tables from RFCs 
> 2618-2621 with
> the IPv4-only format address objects changed from "current" to
> "deprecated".  New tables will be added (in parallel) with IPv4/IPv6
> format address objects.  To promote backwards compatibility, the
> compliance statements will require both old and new tables to be
> instantiated when IPv4 addresses are in use, and only the new tables
> when IPv4 addresses are not in use (i.e. IPv6 only).
> 
> I have a question, however.  Assuming we use the "dual 
> tables" strategy,
> do I deprecate only the IPv4 address objects in the old 
> tables?  Or do I
> deprecate the entire old table?  Or do I deprecate nothing, and
leave
> the fancy explanations to the compliance statements?
> 
> I'm a little fuzzy on the details.
> 
> Thanks!
> 
> Regards,
>  
> Dave
>  
> David B. Nelson
> Enterasys Networks, Inc.
> 50 Minuteman Road
> Andover, MA 01810-1008
> Phone: (978) 684-1330  
> E-mail: dnelson@enterasys.com
>  
> 
>