Subject: RE: mib-doctor review of draft-ietf-ipsp-spd-mib

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 19 Jan 2005 11:59:19 +0100

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

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

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

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

Further, I get from SMICng:

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

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

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

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

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

   spdTrueFilterInstance OBJECT IDENTIFIER ::= { spdTrueFilter 0 }

Not sure what you are trying to do here

   W: f(spd.mi2), (2174,20) Item "spdPacketPart" should have SIZE specified
   W: f(spd.mi2), (112,4) Textual convention "SpdIPPacketLogging" 
      defined but not used

   *** 1 error and 4 warnings in parsing

Bert
> -----Original Message-----
> From: Michael Baer [mailto:[email-masked]]
> Sent: Friday, January 14, 2005 09:43
> To: Wijnen, Bert (Bert)
> Cc: Harrie Hazewinkel; [email-masked]
> 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.
> 
>

---

From: Michael Baer <[email-masked]>
Date: Fri, 21 Jan 2005 18:00:14 -0800

>>>>> "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

-- 
Michael Baer
[email-masked]