Subject: [malloc] FW: [Malloc] RE: MALLOC MIB comments

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

Looks like the actions in response to Steve Hanna's
comments were posted earlier.  The changes indicated
in the email below have been made.

-Dave

-----Original Message-----
From: Dave Thaler 
Sent: Monday, August 20, 2001 4:31 PM
To: Steve Hanna
Cc: [email-masked]
Subject: [Malloc] RE: MALLOC MIB comments

Steve, thanks for reviewing!

> Comments on draft-ietf-malloc-mib-04.txt
> 
> 1) Some objects seems to have incorrect MAX-ACCESS values.
>    This is more likely due to my misunderstanding of how
>    this value is used, but here are my concerns:
> 
>    mallocScopeFirstAddress and mallocScopeFirstAddressType
>    are marked as not-accessible. I think they should be
>    read-create, so that you can read their values and create
>    new entries in the Scope table (if allowed).

Any objects that appear in the INDEX clause of the table
are not-accessible, since one can read their values by
reading any other object in the table, since their value comes back
in the OID of the object read.

Hence, the status is correct (but thanks for asking).
 
>    mallocAllocRangeFirstAddress and mallocAllocRangeFirstAddressType
>    are also marked as not-accessible. I would expect these
>    to be read-create.

Same reason.
 
> 2) The description of mallocAllocRangeAdvertisable says
>    "The default value is true if the scope is divisible,
>    and is false otherwise." What do you mean by default?

If you create a new row in the table via SNMP and don't specify
a value for this object.

>    Do you mean that some program will set the value
>    to these values unless overridden by a human being?

Yes.

>    I suspect you just mean that most people will want to
>    set the value to true when the scope is divisible and
>    false otherwise. If that's what you mean, you should
>    say that.

It's not what I meant.  In MIBs, there's a DEFVAL clause
that you can put in the default value to be used during
row creation (it's just informative to humans, the clause
isn't used by the management station to do anything differently).
Here, we can't use a DEFVAL clause since there's not a single
default value for all cases, and hence the DESCRIPTION
specifies the default instead.
 
> 3) The description of mallocAllocRangeTotalRequestedAddrs
>    says "The approximate number of addresses in the range
>    which there is potential demand for among MAASs, as
>    determined by a Prefix Coordinator." I think that would
>    be more grammatically correct if it read "The approximate
>    number of addresses in the range for which there is
>    potential demand among MAASs, as determined by a Prefix
>    Coordinator."

Agree.

> 4) In the mallocServerGroup, there are several objects
>    missing that I would expect to find there.
> 
>    mallocScopeFirstAddress and mallocScopeFirstAddressType
>    are missing, as are mallocAllocRangeFirstAddress and
>    mallocAllocRangeFirstAddressType and
>    mallocScopeExclusionFirstAddress and
>    mallocScopeExclusionFirstAddressType and
>    mallocScopeNameLangName. I suspect that these are not
>    errors, but due to some strange MIB feature that
>    automatically includes them because they're indexes
>    of their tables and other elements of the tables are
>    included in this group. I dunno.

Yep, that's exactly right.  Objects which are not-accessible
don't appear in conformance groups.
 
>    mallocScopeLastAddressType is missing, but
>    mallocScopeLastAddress is there. I suspect that's an
>    error.

I think you're right.  Will fix.

> 5) In the mallocClientScopeGroup, mallocScopeSSM seems to
>    be missing.

Yep, will fix.

> 6) The description of mallocPrefixCoordinatorGroup says
>    that it is a "collection of notifications". I think
>    it's just a "collection of objects". Isn't that right?

Yep, will fix.

> 7) In the IANA-MALLOC-MIB, IANAmallocRangeSource still
>    includes an aap value. I don't think that's needed,
>    since development of AAP has been abandoned. If it is
>    later resuscitated, we can always ask IANA to assign
>    an IANAmallocRangeSource value to it.

Sounds reasonable.

Thanks again!

-Dave

_______________________________________________
Malloc mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/malloc

---

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

I'm acting on the last call comments received from
Brian Haberman, Bill Fenner, and Steve Hanna.

Here's the responses to Brian's comments.  I'll include
the other two in separate emails.

> 1. The DESCRIPTION of mallocScopeDivisible seems to allow ranges
>    in the mallocScopeTable to be disjoint.  If it is true, it means
>    that the entire range between the first and last address is not
>    usable?

ACTION: None.

Right.  For example, the IPv6 global scope is divisible.
The range of IPv6 unicast-prefix based addresses for each of your
global IPv6 unicast addresses would be rows in the
mallocAllocRangeTable.

> 2. mallocScopeNameScopeName defines a default value for v4, but not
>    v6.  Shouldn't the v6 default be, at a minimum, the generic scope
>    name defined in RFC 2373 (and its update)?

ACTION: Changed as suggested.

> 3. Should the DESCRIPTION of mallocAllocRangeLifetime mention where
>    that lifetime came from?  In unicast-prefix based v6 mcast
>    addresses, the associated prefix lifetime from the RA should be
>    used as the maximum lifetime of that prefix.

ACTION: None.

The lifetime for unicast-prefix based mcast addresses is debatable,
and I don't want this draft to be dependent on that rule (or any other
rules specified by other mechanisms).

> 4. I am confused on why the Request Table and the Address Table are
>    separate entities.  It seems like it should be possible to use
>    the Request Table to represent the same info that is being put
>    in the Address Table.

ACTION: None.

No, the Request Table can contain entries for which no addresses
are allocated, and hence cannot be represented in the Address Table.

> 5. madcapTotalErrors gives a total error count which, I assume, is
>    the sum of the specific error counters.  Would a total message
>    counter be useful as well (e.g. mapcapTotalMessage)?

ACTION: None.

Since this was just a question, not a justification, the default answer
should be not to add such an object.  The rationale for "no" is that
it's trivially derivable from other objects if needed, and so there's
no need to make agents implement it.

-Dave

---

From: "Dave Thaler" <[email-masked]>
Date: Mon, 5 Nov 2001 17:02:29 -0800

Here's the changes in response to the final set of
comments received during WG last call.

I submitted -05 today, and if you don't want to wait,
the document is currently available at
http://www.aciri.org/malloc/draft-ietf-malloc-malloc-mib-05.txt

-Dave

----------------------------------

> - Index length limits.  The OID length limit is 128 identifiers,
> so the root plus the lengths of the encoded objects in the INDEX
> has to be limited to make sure you don't end up with unrepresentable
> rows.

ACTION: Fixed.

Added (SIZE(4..20)) to the InetAddress objects used in indexes,
which range covers the sizes of IPv4 addresses through scoped IPv6
addresses.
Also added (SIZE(1..92)) to the LanguageTag object used in an INDEX,
so the total OID length will be < 128 in the mallocScopeNameTable.

> - Unconditionally optional groups.  There's no conformance statement
> referring to mallocClientScopeGroup or mallocPrefixCoordinatorGroup,
> so these are optional even on MADCAP clients or Prefix Coordinators.

ACTION: Fixed.

Added mallocClientScopeGroup to mallocClientCompliance as mandatory
for clients which maintain a list of multicast scopes.

Added mallocPrefixCoordinatorCompliance for prefix coordinators,
which contains the mallocBasicGroup and the
mallocPrefixCoordinatorGroup.

I also noticed that a number of newer writable objects didn't have
MIN-ACCESS statements of read-only in the compliances, and added
them to be consistent.