Subject: [malloc] RE: More MALLOC-MIB comments

From: "Dave Thaler" <[email-masked]>
Date: Fri, 2 Nov 2001 19:34:03 -0800

Response to one of Bill's two sets of comments:

> The Guid TC seems out of place here; a Guid isn't a MALLOC concept,
> right?  Also, the DESCRIPTION seems a little inadequate (like, how
> do you ensure that it's globablly unique, etc.)

ACTION: Changed as described below.

Changed mallocRequestGuid to mallocRequestLeaseIdentifier, with
syntax of OCTET STRING (SIZE (0..255)).
Removed the Guid TC, since that's the only place it was used.

> Comments describing TABLEs should probably be in the DESCRIPTION of
> either the Table or the Entry.  This applies to the mallocScopeTable,
> mallocScopeNameTable, mallocScopeExclusionTable, mallocRequestTable.

ACTION: Changed as suggested.

> Can there be overlapping ranges in the mallocScopeTable?  The
> DESCRIPTION of mallocScopeDivisible almost implies that there can,
> by saying that if it's divisible it must only allocate addresses
> out of a subrange; perhaps that subrange would also be in this table?
> The INDEX can't represent overlapping ranges if the overlap is at the
> beginning of the range.  If overlap is possible, adding the last
> address to the INDEX is probably wise (and adding it to the other
> tables that refer to rows of this one).  Alternately, an integer
> instance-of-this-first- address-value element could prevent the
> OID from getting too long.

ACTION: Updated DESCRIPTION of Table.

No, ranges cannot overlap.  ScopeDivisible only indicates whether
the range of the scope is divided up among multiple independent
organizations to allocate from.  IPv6 unicast-prefix-based addresses,
and IPv4 GLOP are examples of why the global ASM scopes are
divisible.  ZMAAP is an example of why the IPv6 link-local multicast
scope is not divisible.

> I'd rename FirstAddressType to AddressType and get rid of
> LastAddressType, since the INET-ADDRESS-MIB has relaxed these
> restrictions. Similarly you can get rid of mallocAllocRange{First,
> Last}AddressType, mallocScopeExclusion{First,Last}AddressType.

ACTION: Changed as suggested.

> The INDEX of mallocRequestEntry can't be a GUID, since GUID's can
> be too long to represent in an OID.  I dunno what makes sense
> here -- an arbitrary integer as the index, maybe.

ACTION: Changed as suggested.

Added an arbitrary integer as the index and moved GUID to read-only
(mallocRequestLeaseIdentifier) and added it to the madcapClientGroup,
since MADCAP uses a Lease Identifier, as do some other protocols
(like ZMAAP), but not all mechanisms do (e.g., SSM may not).
Also changed mallocAddressRequestGuid to mallocAddressRequestId,
since its main purpose is to identify the row in the mallocRequestTable.

-Dave