W.r.t.
Based on the errors/warnings I get from both SMICNG and SMILINT, I
wonder how how an IETF Last Call can go out for a MIB module in this
shape.
I did not look at any MIB details yet.
I get this from SMICng:
Since SMICng is a commercial tool for which I don't have a
license I have not been able to validate the MIB against it.
I can however comment on the Smilint output which appears to
flag the same issues.
Understood. If your SYNTAX is clean by smilint, then it most probably
passes SMICng as well.
And I get this from smilint:
C:\bwijnen\smicng\work>smilint -m -l 6 -s ./MGMD-STD-MIB
./MGMD-STD-MIB:39: [3] {revision-missing} revision for last
update is
missing
I believe this is flagged because of the placeholder XXX for
the IANA allocated MIB number.
Nope... a REVISION clause is missing
./MGMD-STD-MIB:90: [2] {size-illegal} illegal size restriction for
non-octet-string parent type `InetAddressType'
./MGMD-STD-MIB:100: [2] {sequence-type-mismatch} type of
`mgmdHostInterfaceQuerierType' in sequence and object type
defi nition
do not match
./MGMD-STD-MIB:246: [2] {size-illegal} illegal size restriction for
non-octet-string parent type `InetAddressType'
All of the size-illegal errors are based on the
InetAddressType redefinition. In email comments returned by
Dave Thaler it was specifically requested that all
InetAddressType objects should have the
syntax:
SYNTAX InetAddress (SIZE(4|16))
That is possible. But you have put it on the InetAddressType
So I have ignored these errors. If there is a preferred or
more correct way to descibe this size restriction then please say so.
For InetAddressType you possibly want to subtype and indicate that
only IPv4 and IPv6 are allowed.
Is unknown not allowed?
For InetAddressType you also may want to limit the allowable
types to IPv4 and IPv6 (possibly also unknown)??
./MGMD-STD-MIB:256: [2] {sequence-type-mismatch} type of
`mgmdRouterInterfaceQuerierType' in sequence and object type de
finition do not match
All sequence-type-mismatch errors are a direct consequence of
the InetAddress error above. If the InetAddressType object
does not produce a size-illegal error then these should also
disappear.
./MGMD-STD-MIB:487: [2] {size-illegal} illegal size restriction for
non-octet-string parent type `InetAddressType'
./MGMD-STD-MIB:494: [2] {sequence-type-mismatch} type of
`mgmdHostCacheAddressType' in sequence and object type
definiti on do
not match
./MGMD-STD-MIB:590: [2] {size-illegal} illegal size restriction for
non-octet-string parent type `InetAddressType'
./MGMD-STD-MIB:597: [2] {sequence-type-mismatch} type of
`mgmdRouterCacheAddressType' in sequence and object type
defini tion do
not match
./MGMD-STD-MIB:644: [2] {subtype-illegal} subtyping not allowed
The TimeTicks modification was made to clarify the legal
value of the mgmdRouterCahceExpiryTimer which can never be
zero. Again, the change was requested by various Magma folks
and seemed perfectly valid. Perhaps you can suggest a more
correct way to specify a range refinement for this object?
RFC2578 states:
7.1.8. TimeTicks
The TimeTicks type represents a non-negative integer which represents
the time, modulo 2^32 (4294967296 decimal), in hundredths of a second
between two epochs. When objects are defined which use this ASN.1
type, the description of the object identifies both of the reference
epochs.
For example, [3] defines the TimeStamp textual convention which is
based on the TimeTicks type. With a TimeStamp, the first reference
epoch is defined as the time when sysUpTime [5] was zero, and the
second reference epoch is defined as the current value of sysUpTime.
The TimeTicks type may not be sub-typed.
So you CANNOT subtype it.
If you need the different range, then define your own sort of
titmeticks thing. Using an Unsigned32.
And if I look at your definitions
mgmdRouterCacheExpiryTime OBJECT-TYPE
SYNTAX TimeTicks (1..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value represents the time remaining
before the Group Membership Interval state expires. The
value must always be greater than or equal to 1."
::= { mgmdRouterCacheEntry 6 }
Then oit CLEARLY is NOT a TIMETICKS SYNTAX as per the above description
of TimeTicks.
./MGMD-STD-MIB:751: [2] {size-illegal} illegal size restriction for
non-octet-string parent type `InetAddressType'
./MGMD-STD-MIB:756: [2] {sequence-type-mismatch} type of
`mgmdInverseHostCacheAddressType' in sequence and object type d
efinition do not match
./MGMD-STD-MIB:798: [2] {sequence-type-mismatch} type of
`mgmdRouterCacheAddressType' in sequence and object type
defini tion do
not match
./MGMD-STD-MIB:835: [2] {size-illegal} illegal size restriction for
non-octet-string parent type `InetAddressType'
./MGMD-STD-MIB:842: [2] {sequence-type-mismatch} type of
`mgmdHostSrcListAddressType' in sequence and object type
defini tion do
not match
./MGMD-STD-MIB:910: [2] {sequence-type-mismatch} type of
`mgmdRouterCacheAddressType' in sequence and object type
defini tion do
not match
./MGMD-STD-MIB:796: [3] {sequence-no-column} SEQUENCE element #1
`mgmdRouterInterfaceIfIndex' is not a child node under
`mgmdRouterInverseCacheEntry'
All of the following errors occur due to the use of
previously defined objects in a reverse lookup table. In an
earlier version of the MIB there were new objects defined for
these tables with the same meaning, however it was pointed
out by David McWalter on the list that a reverse lookup table
should use the same objects as previously defined. This does
appear to confuse smilint. I am not an expert by any means on
this so would appreciate guidance on the correct approach. In
the meantime this seemed acceptable given that the errors
were all level 3 and above.
I did not claim that all warnings are prohibited.,
The following may in act be OK.
I'd have to check deeper.
./MGMD-STD-MIB:784: [5] {index-element-not-accessible}
warning: exactly
one index element of row `mgmdRouterInverseCache Entry' must be
accessible
./MGMD-STD-MIB:909: [3] {sequence-no-column} SEQUENCE element #1
`mgmdRouterCacheAddressType' is not a child node under
`mgmdRouterSrcListEntry'
./MGMD-STD-MIB:909: [3] {sequence-no-column} SEQUENCE element #2
`mgmdRouterCacheAddress' is not a child node under `mgm
dRouterSrcListEntry'
./MGMD-STD-MIB:909: [3] {sequence-no-column} SEQUENCE element #3
`mgmdRouterCacheIfIndex' is not a child node under `mgm
dRouterSrcListEntry'
./MGMD-STD-MIB:102: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:258: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:496: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:524: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:599: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:620: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:758: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:844: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:862: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:917: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
Please advise on how you would like to see this MIB adjusted
since all items flagged as errors appeared valid to me for
the reasons provided.
They CLERLY are not all valid. Read the InetAddress and InetAddressType
DESCRIPTION clauses and SYNTAX in RFC4001 and you will see that what
you did is worng, I tried to explain that above as well.
Also the TimeTicks issue is NOT acceptable, see above.
Bert
Many Thanks,
Julian Chesterfield
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf