Ballot for draft-ietf-softwire-dslite-mib
Yes
No Objection
No Record
Note: This ballot was opened for revision 11 and is now closed.
This may be because this is not my area, but it wasn't immediately obvious what is meant by "the number of the current IPv4 Session" and "the number of the current IPv6 Session." Is that an internal identifier for statistics-gathering purposes? If you think it's worth clarifying, feel free.
Let me append my COMMENT. Since the companion MIB document didn't compile (https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-mib/ballot/#benoit-claise) , I made some extra test with this MIB module. Thanks for addressing Dave Thaler's recommendations. The only point that looks under specified to me is: dsliteNATBindMappingExtAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Address type for the mapping's external address. A value other than IPv4(1) would be unexpected." ::= { dsliteNATBindEntry 4 } dsliteNATBindMappingIntAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "Address type of the mapping's internal address. A value other than ipv4z(3) would be unexpected." ::= { dsliteNATBindEntry 8 } What does it mean: "other value would be unexpected"? Is this allowed or not? timeout 10 smilint -s -e -l 6 -p mibs/NATV2-MIB mibs/DSLite-MIB 2>report.txt You can access any intermediately created files, the processing report (which might be empty if no errors or warnings have been found), and output files (in case of a conversion request) for reading and download from a temporary server directory for approx. 24 hours. While processing your request the following errors and/or warnings have been found: mibs/NATV2-MIB:368: warning: identifier `natv2SubscriberIndex' differs from `Natv2SubscriberIndex' only in case mibs/NATV2-MIB:109: info: previous definition of `Natv2SubscriberIndex' mibs/NATV2-MIB:805: warning: identifier `natv2InstanceIndex' differs from `Natv2InstanceIndex' only in case mibs/NATV2-MIB:135: info: previous definition of `Natv2InstanceIndex' mibs/NATV2-MIB:1689: warning: identifier `natv2PoolIndex' differs from `Natv2PoolIndex' only in case mibs/NATV2-MIB:153: info: previous definition of `Natv2PoolIndex' mibs/NATV2-MIB:2074: warning: `InetAddress' object should have an accompanied preceding `InetAddressType' object mibs/NATV2-MIB:2087: warning: `InetAddress' object should have an accompanied preceding `InetAddressType' object mibs/DSLite-MIB:72: [2] {object-identifier-not-prefix} Object identifier element `xxx' name only allowed as first element mibs/DSLite-MIB:29: [2] {module-identity-registration} illegal module identity registration mibs/DSLite-MIB:118: [5] {index-exceeds-too-large} warning: index of row `dsliteTunnelEntry' can exceed OID size limit by 392 subidentifier(s) mibs/DSLite-MIB:198: [5] {index-exceeds-too-large} warning: index of row `dsliteNATBindEntry' can exceed OID size limit by 189 subidentifier(s) mibs/DSLite-MIB:681: [5] {notification-not-reversible} warning: notification `dsliteTunnelNumAlarm' is not reverse mappable mibs/DSLite-MIB:692: [5] {notification-not-reversible} warning: notification `dsliteAFTRUserSessionNumAlarm' is not reverse mappable mibs/DSLite-MIB:712: [5] {notification-not-reversible} warning: notification `dsliteAFTRPortUsageOfSpecificIpAlarm' is not reverse mappable mibs/DSLite-MIB:5: [5] {import-unused} warning: identifier `Gauge32' imported from module `SNMPv2-SMI' is never used mibs/DSLite-MIB:5: [5] {import-unused} warning: identifier `TimeTicks' imported from module `SNMPv2-SMI' is never used mibs/DSLite-MIB:13: [5] {import-unused} warning: identifier `DisplayString' imported from module `SNMPv2-TC' is never used You could take care of the last 3 warnings. Also, I inquired about the "notification X is not reverse mappable" to the MIB-doctors. Here is Jürgen Schönwälder's answer: SNMPv1 identifies notifications in a different way that SNMPv2c/SNMPv3 does and SMIv2 notification definitions are reverse mappable if they are registered OID.0.X and smilint generates this warning if they are not. This is the reason why the generally suggestion MIB OID layout has a notifications branch registered with the subidentifier 0. The MIB module in question has dsliteNotifications OBJECT IDENTIFIER ::= { dsliteMIB 0 } dsliteTraps OBJECT IDENTIFIER ::= { dsliteNotifications 1 } and the notification registered below dsliteTraps. I do not think this serves any purpose - if authors would simply follow RFC 4181 appendix D the problem would not show up. (And in general, we talk about notifications not traps in SMIv2.) See also section 4.7 of RFC 4181. Authors, please improve your MIB module to be compliant with RFC 4181. Regards, Benoit
mib doctor review will cause a substantial revision.