Submitted MALLOC MIB -06

I just submitted draft -06.

Until it appears in the repository, it can be found on the
MALLOC site at
http://www.icir.org/malloc/draft-ietf-malloc-malloc-mib-06.txt

Detailed responses to MIB doctor review comments below.

-Dave

----------
1) Frank Strauss:
> ./MALLOC-MIB:169: use Integer32 instead of INTEGER in SMIv2
> ./MALLOC-MIB:987: use Integer32 instead of INTEGER in SMIv2
> 
> This is just a suggestion, not a MUST. It affects mallocScopeHopLimit 
> and madcapConfigResponseCacheInterval.

Bert Wijnen:
> - For integer-valued objects, if the value range is
>   between 0..2147483647 (inclusive) then:
>   - we prefer to use Unsigned32

Changed to Unsigned32.

2) Frank Strauss (also Mike Heard):
> ./MALLOC-MIB:11: identifier `NOTIFICATION-TYPE' imported from module 
> `SNMPv2-SMI' is never used
> ./MALLOC-MIB:14: identifier `DisplayString' imported from module
`SNMPv2-
> TC' is never used
> ./MALLOC-MIB:15: identifier `TEXTUAL-CONVENTION' imported from module 
> `SNMPv2-TC' is never used
> ./MALLOC-MIB:18: identifier `NOTIFICATION-GROUP' imported from module 
> `SNMPv2-CONF' is never used
> 
> These macros and type should be removed from the IMPORTS statement. 
> However, this is again not a syntacical MUST.

Done.

3) Frank Strauss:
>     there are different email addresses in the document's Author
>     Section and in the MIB's CONTACT-INFO, just in case one of them is
>     not valid.

Done.

4) Mike Heard:
> Security Considerations -- References to "RFC 2274 [12]" and 
> "RFC 2275 [15]" need to be changed to "RFC 2574 [RFC2574]" and 
> "RFC 2575 [RFC2575]", respectively.

Done.

5) Mike Heard:
> IPR Notices            -- The notices required by RFC 2026
> Section 10.4 (A) and (B) are MISSING and need to be added.

Done.

6) Mike Heard:
> Copyrights             -- There are two typos in the Full
> Copyright Statement.  (Note that these typos were present in 
> RFC 2026 Section 10.4 (C) but have been corrected in RFC 2223 
> Section 11.)

Done.

7) Mike Heard:
> References             -- authors for RFC 2571 are listed
> in the wrong order.

Fixed.  The wrong order was copied from rfc-index.txt, which
still contains the wrong order.

8) Mike Heard:
> E: f(malloc~1.mi2), (610,18) Index item "mallocRequestId" must be
> defined with syntax that includes a range
[...]
> The smicng warning about the index item mallocRequestId defined
> with a syntax that does not includes a range concerns an object
> whose syntax is Unsigned32.  In this case all of the possible
> values from 0 to 4294967295 inclusive are allowable index values.
> As long as the MIB module author agrees that zero is a valid index
> value for this table, then no correction is needed.  However, if
> the author intended to disallow zero-valued indices for
> mallocRequestEntry, as is usually done, then the SYNTAX for should
> be changed to include a range.  In either case the DESCRIPTION
> clause should be changed to say "arbitrary value" instead of
> "arbitrary integer".
[...]
> + -- REVIEWER's note:  suggest that the words "arbitrary
> + -- integer" be changed to "arbitrary value" (integers
> + -- are usually signed)

Added range (1..4294967295).
Changed "integer" to "value" since I really don't care either way.

9) Mike Heard:
(comments about apparent conflicts between the MALLOC MIB
and the draft -05 update to RFC 2851)

Draft -05 of the 2851 update was in error.  The specific cases 
in the MALLOC MIB had been previously discussed with the authors 
of that draft and they agreed that they would update that draft.  
Indeed, these changes have since appeared in draft -06, which
is now RFC 3291.

In fact, an earlier draft of the MALLOC MIB was in fact conformant 
to draft -05, and the changes were made in part as a result of 
pointing out how bad it looked.

To respond to 
> + -- This may not be necessary if the the usage rules in
> + -- <draft-ietf-ops-rfc2851-update-05.txt> are relaxed;
> + -- in that case, it is suggested that the DESCRIPTION
> + -- clauses for mallocAllocRangeFirstAddress and
> + -- mallocAllocRangeLastAddress state that
> + -- mallocScopeAddressType is the type discriminator.

Draft -06 of the 2851 update implies this is a MUST as well,
even if the suggestions therein are followed (which the MALLOC 
MIB does).  Updated all relevant DESCRIPTION clauses as a result
of the new "must", to make it explicit which object is the
type discriminator.

10) Mike Heard:
> the xyzFirstAddress objects in the mallocScopeTable,
> mallocAllocRangeTable, and mallocScopeExclusionTable all have
> size restrictions but the corresponding xyzLastAddress objects
> don't.  Unless the two endpoints of an address range can
> legitimately have difference sizes, please put the same size
> restrictions on both.

Done.  It was previously the way it way since xyzFirstAddress
is in the INDEX and hence had to have it, whereas xyzLastAddress
didn't.

11) Mike Heard:
>   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.

12) Mike Heard:
> + -- REVIEWER's note:  Presumably, deleting a scope which _is_
divisible
> + -- has the side effect of deleting the corresponding entries in the
> + -- mallocAllocRangeTable and in the mallocScopeExclusionTable.  If
that
> + -- is true, please say so in the DESCRIPTION clause above.

Agree.  Updated DESCRIPTION clause of mallocScopeDivisible.
Also done for similar issue of deleting an entry in the mallocRangeTable
having the side effect of deleting corresponding entries in the
mallocAddressTable.

13) Mike Heard:
>   mallocScopeNameLangName OBJECT-TYPE
>       SYNTAX     LanguageTag (SIZE(1..92))
> + -- REVIEWER's note:  if I have counted correctly, this restriction
> + -- results in a maximum OID length of 126 sub-identifiers for the
> + -- accessible object instances in this table.  OK if that's as
intended.

Actually I count 125, am I missing something?

mib-2 = 6 subids (.1.3.6.1.2.1)
malloc = 9 subids (mib-2.mallocMIB.mallocMIBObjects.1)
mallocScopeNameLangName = 12
(malloc.ScopeNameTable.mallocScopeNameEntry.1)
The INDEX contains
mallocScopeAddressType  :  1
mallocScopeFirstAddress : 20 max
mallocScopeNameLangName : 92 max
                         ---
                         125

I think this was left over from when the root was under something other
than mib-2 and hence the oid was longer.

Changed 92 to 95.

14) Mike Heard:
>  mallocAllocRangeTable OBJECT-TYPE
[...]
> + -- REVIEWER's note:  please add some text in the above DESCRIPTION
> + -- clause stating that address ranges for different rows must be
> + -- disjoint, must not overlap with address ranges covered by rows
> + -- in the mallocScopeExclusionTable, and must be contained within
> + -- the address range of the corresponding row of the
mallocScopeTable.
[...]
>  mallocScopeExclusionTable OBJECT-TYPE
> + -- REVIEWER's note:  please add some text in the above DESCRIPTION
> + -- clause stating that address ranges for different rows must be
> + -- disjoint and must not overlap with address ranges covered by rows
> + -- in the mallocAllocRangeTable, and must be contained within the
> + -- address range of the corresponding row of the mallocScopeTable.
> + -- Also, please state either that there are no rows in this table
> + -- corresponding to indivisible scopes or else state what an
excluded
> + -- range signifies in that case.

Done.  Updated with text almost verbatim from above.

15) Mike Heard:
> DESCRIPTION
[...]
> + -- REVIEWER's note:  it might be better style for values such as 
> "allocated",
> + -- "offered", etc. to be written as "allocated(1)", "offered(2),
etc.

Done.

16) Mike Heard:
>   mallocRequestClientAddressType OBJECT-TYPE
[...]
>               "The type of the address of the client to which this
>               allocation was (last) granted."
> + -- REVIEWER's note:  the description suggests to me that this object
> + -- applies only after an allocation is final, i.e., only after the
> + -- request state transitions to allocated(1).  If that's not what is
> + -- intended, then perhaps the text should read "The type of the
address
> + -- of the client that (last) requested this allocation."
(and same for mallocRequestClientAddress)

Accepted proposed replacement text.

17) Mike Heard:
>   mallocClientGroup OBJECT-GROUP
[...]
>               "The basic collection of objects providing management of
IP
>               multicast address allocation."
> + -- REVIEWER's note:  this is a verbatim copy of the mallocBasicGroup
> + -- description.  I think what was intended was someting like this:
> + --          "A collection of objects providing management of
multicast
> + --          address allocation in clients."
[...]
>   mallocClientScopeGroup OBJECT-GROUP
[...]
>               "A collection of objects providing management of
multicast
>               scope information."
> + -- REVIEWER's note:  should be "... scope information in clients."

Right.  Changed as suggested.

18) Bert Wijnen:
> - The MODULE-IDENTITY macro has a CONTACT-INFORMATION clause 
>   that now lists the author. These days, we prefer to also list
>   the WG chair(s) and the mailing list and archive information.
>   That way, it is easier for people to locate people and or
>   discussions about the MIB. You can take RFC2571 as an example.

Done.  (RFC2571 doesn't list the archive information, but
I added it anyway.)

19) Bert Wijnen:
> - The MODULE-IDENTITY macro has a revision clause:
> 
>     REVISION     "200111051200Z" -- November 5, 2001
>     DESCRIPTION
>             "Initial version." 
>   Where I would prefer to see:
> 
>     -- revision log
> 
>     REVISION     "200111051200Z" -- November 5, 2001
>     DESCRIPTION
>             "Initial version, published as RFC xxxx."
>             -- RFC-Editor assigns xxxx
> 
>   Please also add a revision clause to the ianaMallocMIB

Done.

20) Bert Wijnen:
> - I see the use of IMPLIED. As you may know, in the SMIng WG, the
>   consensus seems to be that IMPLIED was a bad idea. There is
>   the feeling that we should deprecate or obsolete the use of 
>   the IMPLIED keyword. So maybe you want to consider to not use
>   it...!! I do understand the sorting issue. Not sure how
>   important the sorting issue is.

The sorting issue is that with IMPLIED, strings appear in 
alphabetical order, which is how humans expect things to look.
Without IMPLIED, strings appear in order by length, and then
alphabetically within a given length.

I don't understand why it's a bad idea.  No change, since you
didn't seem adamant about it.

21) Bert Wijnen:
> - Pointer to RFC 1766 probably should be changed to reference
>   to RFC 3066 (which obsoletes 1766). WOuld it be good to add
>   a reference too? I understand that the RFC2932 (from whihc
>   you import the LanguageTag TC) was before 3066 and so it uses
>   1766. But that should be updated next time around too!.
>   Or maybe you just do not refer to 1766, since the TC in RFC
>   2932 already refers to it?

Changed mention of 1766 to 3066.  Didn't add a REFERENCE, since
it really belongs in the TC in 2932.

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.

24) Bert Wijnen:
> - In the MODULE COMPLAINCEs part... 
>   We have started to ask people to specify two sets of 
>   compliances, that is if you want to allow for a read-only
>   implementation of the MIB.
[...]
>  (see for example draft-ietf-diffserv-mib-16.txt where they
>  do the same thing).

This sounds like a good idea.
Done.

25) Bert Wijnen:
> - You might want to split references in normative and informative
>   references. It is coming... and by the time this gets to IETF
>   Last Call.. it probably is needed/or seriously wanted.
>   See: http://www.rfc-editor.org/policy.html towards the bottom

I think the official MIB boilerplate at
http://www.ops.ietf.org/mib-boilerplate.html
should be updated first, so the rest of us don't have to guess
at what the correct breakdown is among those.

I just checked and the latest RFC (the long awaited RFC 3291 Textual 
Conventions for Internet Network Addresses) does not split references,
so no change yet.  I can do so after the new boilerplate is agreed
upon (during the 48 hour author check period if not before).

26) Bert Wijnen:
>    Any additions or changes to the contents of this MIB module
>    require either publication of an RFC, or Designated Expert
>    Review as defined in the Guidelines for Writing IANA
>    Considerations Section document.  The Designated Expert will
>    be selected by the IESG Area Director(s) of the Transport
>    Area."
> 
> "publication of an RFC" is the piece that bothers me a bit. It 
> allows for Informational, Experimental, April-1st RFCs to 
> be sufficient. I would rather see something like:
> "publication of a standards track or BCP RFC"

It is worded as the WG agreed (I believe the intent was to allow
Experimental, etc., especially since AAP, if published, would be
Experimental).  If you're saying you or the IESG find that 
unacceptable, then I can change the text accordingly, since there's
still the Designated Expert Review provision which could be used
for such cases.

27) Bert Wijnen:
> I do not see anything about the presistency of the MIB objects and 
> table entries. Either we need StorageType objects or we need to 
> describe in the table DESCRIPTION clauses what the persistency 
> characterisctics are.

Added StorageType objects to all writable tables.

28) Dave Thaler:
> Exclusion Table should have been removed when AAP was removed.

Issue discussed on mailing list.  Consensus was to remove it.
Done.