RE: InetAddressType and InetAddress

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

On Sun, 17 Nov 2002, Wijnen, Bert (Bert) wrote:
>[Mike Heard:]
> > > The question is imminent, cause I have the malloc MIB on 
> > > the IESG agenda
> > > 
> > >     draft-ietf-malloc-malloc-mib-07.txt
> > 
> > I was the reviewer of this module, and I strongly agreed with the author
> > that the right thing to do is put a range restriction on the length of
> > InetAddress objects that are used as index objects.
> > 
> So I am not against putting a range restriction on those INDEX objects
> to try and meet the 128 subid concern.
> What I worry about is that they make the range to be just OK for the
> two protocols they currently support. If the range were (0..32) that would
> be fine with me. SO iwe ever would get an IPvx that has 32 octets for
> address space, it would still work.
> 
> Does that calrification help?

In the present case, there is no headroom to increase the upper
bound without decreasing the maximum length of another index
component.  The designer of the MIB module has stated in previous
responses to review comments that the particular tradeoff chosen
was made deliberately.  This is a judgement call of the sort that I,
for one, would prefer not to second-guess.  I'm attaching an excerpt
from Dave Thaler's reply that explains his positions.  These
explanations seem reasonable to me.

% Subject: Submitted MALLOC MIB -06
% Date: Fri, 17 May 2002 11:55:04 -0700
% Message-ID: <2E33960095B58E40A4D3345AB9F65EC1073840AD@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
% X-MS-Has-Attach: 
% X-MS-TNEF-Correlator: 
% Thread-Topic: Submitted MALLOC MIB -06
% Thread-Index: AcHxfJ/64xmMtacATR+xAlq4uxeNOAMVdsqA
% From: "Dave Thaler" <dthaler@windows.microsoft.com>
% To: <mankin@ISI.EDU>, <bwijnen@lucent.com>, <sob@harvard.edu>
% Cc: "C. M. Heard" <heard@pobox.com>,
%         "Frank Strauss" <strauss@ibr.cs.tu-bs.de>,
%         <steve.hanna@sun.com>, <schoenw@ibr.cs.tu-bs.de>,
%         "Bill Fenner" <fenner@research.att.com>, <malloc@catarina.usc.edu>
...
% > mallocScopeFirstAddress OBJECT - TYPE > SYNTAX InetAddress (SIZE (4. .20))
% > + -- REVIEWER's note:  beware that this SIZE restriction cannot be
% > + -- changed in future revisions of this MIB module.  That's OK if
% > + -- you are sure that SIZE(4..20) will not prevent you from doing
% > + -- something later that you want to be able to do.
% 
% It is understood and is okay.  No change.
...
% 22) Bert Wijnen:
% > -I see that you want to limit the InetAddressType values
% > to IPv4, IPv6, IPv4z and IPv6z (or so I think to understand).
% >   In that case, you MUST specify this in the compliance specs
% >   (see for example draft-ietf-diffserv-mib-16.txt where they
% >    do the same thing).
% 
% Mike Heard:
% > Many of the InetAddressType items are inaccessible INDEX items. 
% > SMIv2, unfortunately, does not allow those to be mentioned in 
% > compliance statements, nor does <draft-ietf-ops-rfc2851-update-05.txt>
% > provide any guidance.  Suggestions?
% 
% Juergen Schoenwaelder:
% > Yep, this is very unfortunate. The best thing you can do is to 
% > put text into a DESCRIPTION clause (and to hope that a future SMI 
% > does not have this problem).
% 
% Bert Wijnen:
% > So then it seems that the only place we can do it is in the 
% > object definition itself (as is done with the size for firstaddress). 
% > I guess we should then also subtype the InetAddressType in the 
% > object definition.
% > 
% > And as Juergen suggests, yes add something to the DESCRIPTION clause 
% > as well.
% > 
% > I wonder... if we get into this situation what we should do for the 
% > second occurance of InetAddress, which is not an index item. Juergen?
% 
% Juergen:
% > I think the implementation requirements wrt. 
% > address types should be defined in the conformance statement and not 
% > in the object type definition.  So what I suggested was to add text 
% > to a suitable DESCRIPTION clause in the conformance statement - not 
% > in the DESCRIPTION clause of the object type (or even sub-typing in 
% > the object type clause).
% 
% Bill Fenner:
% > RFC 2851 discourages subtyping, since that closes the door for 
% > evolution (e.g. something that subtyped RFC 2851's InetAddressType to 
% > allow only ipv4(1) or ipv6(2) would not be able to use addresses with 
% > associated zones (i.e. ipv4z(3) or ipv6z(4)) from 
% > draft-ietf-ops-rfc2851-update-05 ).
% 
% Bert:
% > So you are are suggesting to use DESCRIPTION clause
% > in CONFORMANCE statement instead of doing anything machine readable.....
% > 
% > Well.. they have now define a size limit on an InetAddress object. 
% > It is an INDEX object, so they must do that. They then used a size of 
% > 4..20, so that is the IPv4, IPV6 and IPv4z and IPv6z types basically. 
% > But no subtyping on the InetAddresType, which is also an INDEX object 
% > just before the InetAddress INDEX object.
% 
% Mike:
% > Actually, I think that Mr. Thaler has already this covered.  Each
% > InetAddressType INDEX object includes the following proviso in its
% > DESCRIPTION clause:
% > 
% >   Legal values correspond to the subset of address families
% >   for which multicast address allocation is supported.
% 
% Bill:
% > The argument against subtyping in the object definition is also an 
% > argument against SIZE(4..20), which is why I was suggesting simply 
% > restricting to (0..N) where N is enough to ensure that the OID doesn't
% > get too long.
% 
% Mike:
% > Right now one of the tables (the mallocScopeNameTable) only has two
% > sub-ids worth of headroom.  If the SIZE restriction on the InetAddress
% > index components is relaxed, then mallocScopeNameLangName will need a
% > to have is SYNTAX changed from LanguageTag (SIZE(1..92)) to something
% > more restrictive.  I would recomment against having different size
% > restrictions for different InetAddress index objects.
% 
% Mike already answered this the same way I would have.
% The DESCRIPTION clauses already contain the statement Mike quotes,
% and there is no longer 2 sub-ids of headroom as mentioned earlier.
% 
% 23) Bert Wijnen:
% > - I see that you specify a size limit of (4..20) for various
% >   InetAddress type objects. I think you do so because they are
% >   index objects, and RFC2851 (and also the revision that is
% >   in Last Call now) tell you to do so in case you use it in
% >   an index. But I wonder if the values 4..20 are the proper
% >   values to use here. The 4..30 seems appropriate in the
% >   compliance specs, but not in at the point where the objects
% >   are being defined. Probably a better limit here would be
% >   something like (0..32) or (0..64). I think this is explained
% >   in the update to RFC2851.
% 
% Since it's limited to IPv4, IPv6, IPv4z and IPv6z, 20 is indeed
% the max value, and it affects the max size of mallocScopeNameLangName
% as discussed under #13 above.  The example in the update to 2851 
% also imposes a size restriction where the objects are being defined, 
% and it uses 64 only because dns is legal in the example.
% No change.

In view of the reasoning above, I would recommend that the MALLOC-MIB be
accepted as written.

Mike