[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: mib-doctor review of draft-ietf-ipsp-spd-mib
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: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.
>
>