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/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
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
.
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
