Subject: [malloc] Re: FW: Request for MIB Doctor review before IETF Last Call - malloc mib

From: Frank Strauss <[email-masked]>
Date: 12 Nov 2001 23:13:42 +0100

Hi!

Bert> Could one of you do you SMIlint checks and report back to
Bert> the authors and WG? Pls cc: myself and Allison Mankin too.

Please note that I just did a plain smilint check. I did not look
into any semantics. I even don't know what the purpose of this
MIB is other than known from it's name. ;-)

You can use smilint without installing it yourself by sending the
MIB(s) as plain text without any header and trailers to
[email-masked]. If there are non-RFC MIBs imported,
simply concatenate them in the appropriate order, e.g.

cat IANA-MALLOC-MIB MALLOC-MIB | Mail [email-masked]

./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.

./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.

./MALLOC-MIB:404: `InetAddress' object should have an accompanied preceding `InetAdressType' object
./MALLOC-MIB:638: `InetAddress' object should have an accompanied preceding `InetAdressType' object

I'd suggest to read draft-ietf-ops-rfc2851-update-05 for the details.
I did not delve into the semantics of the MALLOC-MIB, but I think the
usage of InetAdress does not conform to the intentions of
draft-ietf-ops-rfc2851-update-05, e.g. the SIZE(4..20) restrictions
in some cases.

 -frank

PS: Dave, 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.

---

From: "Dave Thaler" <[email-masked]>
Date: Mon, 12 Nov 2001 16:54:45 -0800

Below...

> and madcapConfigResponseCacheInterval.

I can change this, but I think it can be fixed after IESG/IETF last
call,
since it's just a suggestion.

> ./MALLOC-MIB:14: identifier `DisplayString' imported from module
`SNMPv2-
> TC' is never used

Likewise.
 
> draft-ietf-ops-rfc2851-update-05, e.g. the SIZE(4..20) restrictions

Per the attached email thread, the MALLOC-MIB is correct and the
rfc2851-update draft needs to be fixed.

>     Section and in the MIB's CONTACT-INFO, just in case one of them is

Both are valid, one forwards to the other.  (However, I'll probably
change one after IETF last call just to be consistent.)

Thanks,
-Dave 

Subject: FW: Comments on draft-ietf-ops-rfc2851-update-05.txt
From: "Dave Thaler" <[email-masked]>
To: <[email-masked]>
Date: Mon, 5 Nov 2001 17:38:26 -0800

[correcting the email alias]

-----Original Message-----
From: Dave Thaler 
Sent: Monday, November 05, 2001 5:34 PM
To: [email-masked]'; [email-masked]'
Subject: Comments on draft-ietf-ops-rfc2851-update-05.txt

Background:
> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Monday, November 05, 2001 3:11 PM
>
> Dave> Situation: a table INDEX'ed by an InetAddressType object and an
> Dave> InetAddress object that are not in the table itself.
> 
> Dave> My reading of the section 4 is that if an InetAddressType object
> Dave> occurs in the INDEX, but that object does not have an OID in the
> Dave> table itself, then the table MUST still have another
> Dave> InetAddressType column before any InetAddress columns in the
> Dave> table.  (And presumably its DESCRIPTION would typically say the
> Dave> value MUST be equal to the value of the InetAddressType object
> Dave> in the INDEX.)
> 
> Dave> Is this the intent?
> 
> Not really. For me, the INDEX components are kind of "logically
> registered" before any other columns of a table. The big question is
> how to describe this in an understandable way.
> 
> Since we are in IETF last call mode, I would like to ask you to bring
> this issue up on the <[email-masked]> and the <[email-masked]> or
> <[email-masked]> mailing lists.

The problematic text is (from Sect 4, 3rd para):
> The InetAddressType object must be registered before the InetAddress
> object(s) or InetAddressPrefixLength object(s).  In other words, the
> object identifiers for the InetAddressType object and the InetAddress
> object MUST have the same length and the last sub-identifier of the
> InetAddressType object MUST be less than the last sub-identifier of
> the InetAddress object.

Here's some suggested replacement text:
The InetAddressType object must be registered before the InetAddress
object(s) or InetAddressPrefixLength object(s).  In other words, either:
a) the object identifiers for the InetAddressType object and the
InetAddress
object MUST have the same length and the last sub-identifier of the
InetAddressType object MUST be less than the last sub-identifier of
the InetAddress object, or
b) the InetAddress object MUST be a columnar object in a table with an
InetAddressType object in the INDEX (preceding the InetAddress object if
it is also in the INDEX).
Furthermore, when an InetAddress object appears in the INDEX of another
table, it MUST be preceded in the INDEX of that table by an
InetAddressType object.

(I believe the above text covers all the cases where an INDEX can
contain a Type from the same or a different table, and perhaps an
Address from the same or a different table.)

-Dave