Hi Benoit,
A updated version has been submitted. Please help to check if your COMMENT
has be resolved.
For the warnings as below:
>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)
[Yu]: These warnings are due to the fact that the row objects have index
objects of type InetAddress which have size limit.
We have added the size limit in the SYNTAX of the definition for the
InetAddress index objects.
The warnings will not show up.
BR
Yu
-----Original Message-----
From: Benoit Claise [mailto:[email protected]]
Sent: Friday, December 18, 2015 6:35 PM
To: Yu Fu; 'The IESG'
Cc: [email protected]; [email protected];
[email protected]; [email protected]
Subject: Re: [Softwires] Benoit Claise's No Objection on
draft-ietf-softwire-dslite-mib-13: (with COMMENT)
Hi,
> Dear Benort,
>
> Thanks for your comment. Please see my reply online.
>
>>> What does it mean: "other value would be unexpected"?
>>> Is this allowed or not?
> [Yu]: For the DS-Lite scenario, AFTR translate the private IPv4 address to
> the public IPv4 address as a NAT device.
> In the definition of RFC4001:
> ipv4(1): An IPv4 address as defined by the InetAddressIPv4 textual
> convention.
> ipv6(2) : An IPv6 address as defined by the InetAddressIPv6 textual
> convention.
> ipv4z(3): A non-global IPv4 address including a zone index as defined
> by the InetAddressIPv4z textual convention.
> ipv6z(4): A non-global IPv6 address including a zone index as defined
> by the InetAddressIPv6z textual convention.
>
> So the address type of the external address defined in
> dsliteNATBindMappingExtAddressType is IPv4(1) and the address type of the
> internal address defined in dsliteNATBindMappingIntAddressType is IPv4z(3).
> Other value would be unexpected.
Right, but allowed or not?
If you know that ipv6 and ipv6z are not allowed, why not mention it?
>
>>> 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
> [Yu]: For the above warning, we will improve the OID layout of the DS-Lite
> MIB to be compliant with RFC 4181 as below:
>
> dsliteNotifications OBJECT IDENTIFIER
> ::= { dsliteMIB 0 }
>
> dsliteTunnelNumAlarm NOTIFICATION-TYPE
> ::= { dsliteNotifications 1 }
>
> So the warning will not show up.
Thanks.
Regards, Benoit
>
> Thanks again for your help. An updated version of the draft will submitted
> soon.
>
> BR
> Yu
> -----Original Message-----
>>> From: [email protected] [mailto:[email protected]]
>>> On Behalf Of Benoit Claise
>>> Sent: Thursday, December 17, 2015 10:08 PM
>>> To: The IESG
>>> Cc: [email protected]; [email protected];
>>> [email protected]; [email protected]
>>> Subject: [Softwires] Benoit Claise's No Objection on
>>> draft-ietf-softwire-dslite-mib-13: (with COMMENT) Benoit Claise has
>>> entered the following ballot position for
>>> draft-ietf-softwire-dslite-mib-13: No Objection When responding,
>>> please keep the subject line intact and reply to all email addresses
>>> included in the To and CC lines. (Feel free to cut this introductory
>>> paragraph, however.)
>
>>> Please refer to
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-mib/
>>> --------------------------------------------------------------------
>>> --
>>> COMMENT:
>>> --------------------------------------------------------------------
>>> --
>>> Let me append my COMMENT.
>>> Since the companion MIB document didn't compile
>>> (https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-mib/ballo
>>> t/#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
>
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires
>
>
> .
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
