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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf