Re: mib-doctor review of draft-ietf-ipsp-spd-mib

[Michael Baer <baerm@xxxxxxxxxxxxxxx>]

>>>>> "Bert" == Bert Wijnen <Wijnen> writes:

    Bert> Just another nit:
    Bert> REVISION     "200401070000Z"            -- 7 January 2004
    Bert> DESCRIPTION  "Initial version, published as RFC ZZZZ."
    Bert> -- RFC-editor assigns ZZZZ

    Bert> -- ZZZZ: To be assigned by IANA
    Bert> ::= { mib-2 xxx }


    Bert> ZZZZ (the RFC-number) gets assigned and filled in by RFC-Editor.

    Bert> The xxx (branch under mib-2) gets assigned by IANA.

oops, search/replace error, I changed the comment back to xxx

    Bert> Further, I get from SMICng:

    Bert> W: f(spd.mi2), (71,21) The first revision should match the last
    Bert> update for MODULE-IDENTITY spdMIB
    Bert> W: f(spd.mi2), (197,4) Row "spdEndpointToGroupEntry" has indexing
    Bert> that may create variables with more than 128 sub-ids

    Bert> The DESCIPRION clause of the tableEntry should have a warning for
    Bert> implementations to watch out for more than 128 subids.
    Bert> See the draft-ietf-ops-mib-review-guidelines-03.txt
    Bert> For example:
    Bert> Implementors need to be aware that if the size of
    Bert> spdEndGroupAddress exceeds xxx octets then OIDs of column
    Bert> instances in this table will have more than 128 sub-
    Bert> identifiers and cannot be accessed using SNMPv1, SNMPv2c, or
    Bert> SNMPv3.

    Bert> You need to check how much xxx is, smilint is your friend

Smilint is my friend :).  There would be a lot more errors without
it.  At one point, though, the smilint checks got deleted from our
Makefile and there were a large number of missed errors because of
it.

I was ignoring the warnings in this case, though, as the
spdEndGroupAddress is limited to being of type ipv4 or ipv6 (by
spdEndGroupAddrType I think), so it should only be 4 or 16 octets
and the OID limit isn't hit.  But I just added text to the
DESCRIPTION clause indicating both the practical lengths currently
possible (i.e. 4 and 16 octets) as well as the actual OID sub
identifier limits for this variable (115).

    Bert> E: f(spd.mi2), (915,4) Item "spdTrueFilter" must not have
    Bert> items registered below it

    Bert> caused by: 
    Bert> spdTrueFilter OBJECT-TYPE
    Bert> SYNTAX      Integer32
    Bert> ... snip ..

    Bert> spdTrueFilterInstance OBJECT IDENTIFIER ::= { spdTrueFilter 0 }

I don't think this is illegal (although I can see why SMICng didn't
like it).  It as actually copied from the DISMAN-EVEN-MIB:
sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 }.  The main
reason this object was created is that it is used as a defval for a
variablePointer typed object.  The variablePointer needs to point
to an actual instance of an object and not just the definition.

    Bert> Not sure what you are trying to do here

    Bert> W: f(spd.mi2), (2174,20) Item "spdPacketPart" should have
    Bert> SIZE specified

How the size limit is reached is discussed in the DESCRIPTION clause
(this is only true in the last version I sent out as this
description was updated from Harrie's initial comments).

    Bert> W: f(spd.mi2), (112,4) Textual convention "SpdIPPacketLogging" 
    Bert> defined but not used

SpdIPPacketLogging is meant to be used directly by any action MIB's
that are used in conjunction with the SPD-MIB.  It's also used less
directly (i.e. in a non-SMI syntactical fashion) by the
spdPacketPart notification object and the spdPacketNotfication
notification.  A value of this type is actually the initial value
used in deciding the SIZE of spdPacketPart object above.

    Bert> *** 1 error and 4 warnings in parsing

    Bert> Bert
    >> -----Original Message-----
    >> From: Michael Baer [mailto:baerm@xxxxxxxxxxxxxxx]
    >> Sent: Friday, January 14, 2005 09:43
    >> To: Wijnen, Bert (Bert)
    >> Cc: Harrie Hazewinkel; ipsec-policy@xxxxxxxx
    >> Subject: Re: mib-doctor review of draft-ietf-ipsp-spd-mib
    >> 
    >> 
    >> >>>>> "Bert" == Bert Wijnen <Wijnen> writes:
    >> 
    Bert> One thing that immediately caught my eye when quickly
    Bert> browsing this response was:
    >> 
    >> The current draft is attached.  The comments below should be fixed
    >> in it, but I haven't gone through all of Harries previous comments.
    >> 
    >> 


-- 
Michael Baer
baerm@xxxxxxxxxxxxxxx