Subject: [Softwires] Benoit Claise's No Objection on draft-ietf-softwire-dslite-mib-13: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 17 Dec 2015 06:08:25 -0800

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

---

From: "Yu Fu" <[email-masked]>
Date: Fri, 18 Dec 2015 16:45:11 +0800

Dear Benort,

Thanks for your comment. Please see my reply online.

>>What does it mean: "other value would be unexpected"?

[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.

>>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:

   dsliteTunnelNumAlarm NOTIFICATION-TYPE
         ::= { dsliteNotifications 1 }

   So the warning will not show up.

Thanks again for your help. An updated version of the draft will submitted soon.

BR
Yu
-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf Of Benoit Claise
>>Sent: Thursday, December 17, 2015 10:08 PM
>>To: The IESG
>>Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
>>Subject: [Softwires] Benoit Claise's No Objection on draft-ietf-softwire-dslite-mib-13: (with COMMENT)

>>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.)

          SYNTAX InetAddressType
          MAX-ACCESS read-only
          STATUS current
          DESCRIPTION

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:805: warning: identifier `natv2InstanceIndex' differs from `Natv2InstanceIndex' only in case
>>mibs/NATV2-MIB:1689: warning: identifier `natv2PoolIndex' differs from `Natv2PoolIndex' only in case
>>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)
>>notification `dsliteAFTRPortUsageOfSpecificIpAlarm' is not reverse mappable
>>mibs/DSLite-MIB:13: [5] {import-unused} warning: identifier `DisplayString' imported from module `SNMPv2-TC' is never used

>>Also, I inquired about the "notification X  is not reverse mappable" to the MIB-doctors.
>>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.

         ::=  { dsliteMIB 0 }

>>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.)

>>Regards, Benoit

_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Benoit Claise <[email-masked]>
Date: Fri, 18 Dec 2015 11:35:11 +0100

Hi,
> Other value would be unexpected.
Right, but allowed or not?
If you know that ipv6 and ipv6z are not allowed, why not mention it?

>     So the warning will not show up.
Thanks.

Regards, Benoit
> .

---

From: "Yu Fu" <[email-masked]>
Date: Mon, 21 Dec 2015 14:15:29 +0800

Hi Benoit,

  A updated version has been submitted. Please help to check if your COMMENT has be resolved.

  >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-masked]] 
Sent: Friday, December 18, 2015 6:35 PM
To: Yu Fu; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Softwires] Benoit Claise's No Objection on draft-ietf-softwire-dslite-mib-13: (with COMMENT)

Hi,
> 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).

Thanks.

Regards, Benoit
>>> Cc: [email-masked]; [email-masked]; 
>>> [email-masked]; [email-masked]
>>> 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
>>> (https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-mib/ballo
>>> t/#benoit-claise) , I made some extra test with this MIB module.
>>> mibs/NATV2-MIB:368: warning: identifier `natv2SubscriberIndex' 
>>> differs from `Natv2SubscriberIndex' only in case
>>> mibs/DSLite-MIB:72: [2] {object-identifier-not-prefix} Object 
>>> identifier element `xxx' name only allowed as first element
>>> 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)
>>> `DisplayString' imported from module `SNMPv2-TC' is never used You could take care of the last 3 warnings.
>>> 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.