Subject: [MIB-DOCTORS] InetAddress and InetAdressType (draft-perrault-behave-natv2-mib-04 compilation)

From: Benoit Claise <[email-masked]>
Date: Tue, 09 Jun 2015 22:56:56 +0200

Hi Dave,

One question regarding draft-perrault-behave-natv2-mib-04 compilation.
Copying the draft-perrault-behave-natv2-mib-04 authors.

timeout 10 smilint -s -e -l 6 mibs/NATV2-MIB 2>report.txt

mibs/NATV2-MIB:359: [5] {identifier-case-match} warning: identifier 
`natv2SubscriberIndex' differs from `Natv2SubscriberIndex' only in case
mibs/NATV2-MIB:104: [6] {previous-definition} info: previous definition 
of `Natv2SubscriberIndex'
mibs/NATV2-MIB:785: [5] {identifier-case-match} warning: identifier 
`natv2InstanceIndex' differs from `Natv2InstanceIndex' only in case
mibs/NATV2-MIB:130: [6] {previous-definition} info: previous definition 
of `Natv2InstanceIndex'
mibs/NATV2-MIB:1642: [5] {identifier-case-match} warning: identifier 
`natv2PoolIndex' differs from `Natv2PoolIndex' only in case
mibs/NATV2-MIB:147: [6] {previous-definition} info: previous definition 
of `Natv2PoolIndex'
mibs/NATV2-MIB:2019: [5] {inetaddress-inetaddresstype} warning: 
`InetAddress' object should have an accompanied preceding 
`InetAdressType' object
mibs/NATV2-MIB:2029: [5] {inetaddress-inetaddresstype} warning: 
`InetAddress' object should have an accompanied preceding 
`InetAdressType' object

I'm not concerned about the first warnings, which are fine IMO, but I 
wonder about the last two.

This relates to:
natv2PoolRangeBegin OBJECT-TYPE
     SYNTAX InetAddress
     MAX-ACCESS read-only
     STATUS current
     DESCRIPTION
         "Lowest address included in this range. The type of address
          (IPv4 or IPv6) is given by natv2PoolAddressType
          in natv2PoolTable."
     ::= { natv2PoolRangeEntry 4 }

natv2PoolRangeEnd OBJECT-TYPE
     SYNTAX InetAddress
     MAX-ACCESS read-only
     STATUS current
     DESCRIPTION
         "Highest address included in this range. The type of address
          (IPv4 or IPv6) is given by natv2PoolAddressType
          in natv2PoolTable."
     ::= { natv2PoolRangeEntry 5 }

 From RFC 4001:

    InetAddress ::= TEXTUAL-CONVENTION
         STATUS      current
         DESCRIPTION
             "Denotes a generic Internet address.

              An InetAddress value is always interpreted within the context
              of an InetAddressType value.  Every usage of the InetAddress
              textual convention is required to specify the InetAddressType
              object that provides the context.  It is suggested that the
              InetAddressType object be logically registered before the
              object(s) that use the InetAddress textual convention, if
              they appear in the same logical row.

Should we be concerned?
On the other hand, I see natv2PoolAddressType in the description clause.

Regards, Benoit

---

From: Dave Thaler <[email-masked]>
Date: Tue, 9 Jun 2015 21:44:46 +0000

Yes the last two should be fixed.  I believe there are tools that rely on having an InetAddressType in the same table and won’t work correctly.

Also, as an aside, there’s a typo in the tool output… InetAdressType should be InetAddressType

From: MIB-DOCTORS [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Tuesday, June 9, 2015 1:57 PM
To: David Harrington
Cc: [email-masked]; MIB Doctors (E-mail)
Subject: [MIB-DOCTORS] InetAddress and InetAdressType (draft-perrault-behave-natv2-mib-04 compilation)

Hi Dave,

mibs/NATV2-MIB:359: [5] {identifier-case-match} warning: identifier `natv2SubscriberIndex' differs from `Natv2SubscriberIndex' only in case
mibs/NATV2-MIB:104: [6] {previous-definition} info: previous definition of `Natv2SubscriberIndex'
mibs/NATV2-MIB:785: [5] {identifier-case-match} warning: identifier `natv2InstanceIndex' differs from `Natv2InstanceIndex' only in case
mibs/NATV2-MIB:130: [6] {previous-definition} info: previous definition of `Natv2InstanceIndex'
mibs/NATV2-MIB:1642: [5] {identifier-case-match} warning: identifier `natv2PoolIndex' differs from `Natv2PoolIndex' only in case
mibs/NATV2-MIB:147: [6] {previous-definition} info: previous definition of `Natv2PoolIndex'
mibs/NATV2-MIB:2019: [5] {inetaddress-inetaddresstype} warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object
mibs/NATV2-MIB:2029: [5] {inetaddress-inetaddresstype} warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object

I'm not concerned about the first warnings, which are fine IMO, but I wonder about the last two.

This relates to:

From RFC 4001:

    STATUS      current

    DESCRIPTION

Should we be concerned?

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Tue, 09 Jun 2015 23:52:32 +0200

On 09/06/2015 23:44, Dave Thaler wrote:
>
> Yes the last two should be fixed.  I believe there are tools that rely 
> on having an InetAddressType in the same table and won’t work correctly.
>
> Also, as an aside, there’s a typo in the tool output…InetAdressType 
> should be InetAddressType
>
Well spot Dave.

Regards, B.
>
> *From:*MIB-DOCTORS [mailto:[email-masked]] *On Behalf Of 
> *Benoit Claise
> *Sent:* Tuesday, June 9, 2015 1:57 PM
> *To:* David Harrington
> *Cc:* [email-masked]; MIB Doctors 
> (E-mail)
> *Subject:* [MIB-DOCTORS] InetAddress and InetAdressType 
> (draft-perrault-behave-natv2-mib-04 compilation)
>
> Hi Dave,
>

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 9 Jun 2015 19:22:26 -0400

+1

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: Dave Thaler [mailto:[email-masked]] 
Sent: Tuesday, June 09, 2015 5:45 PM
To: Benoit Claise; David Harrington
Cc: [email-masked]; MIB Doctors (E-mail)
Subject: RE: [MIB-DOCTORS] InetAddress and InetAdressType (draft-perrault-behave-natv2-mib-04 compilation)

Hi Dave,

This relates to:

 

Should we be concerned?

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2015 08:55:11 +0200

> should be InetAddressType

Fixed in the upstream sources.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Tom Taylor <[email-masked]>
Date: Wed, 10 Jun 2015 12:33:30 -0400

There is a constraint that all address ranges assigned to the same 
address pool must have the same address type. I guess if the tools 
require specification for each range, that constraint has to go into the 
DESCRIPTION clause at the address range level, instead of the present 
arrangement.

Tom Taylor

On 09/06/2015 7:22 PM, ietfdbh wrote:
> +1
>
> David Harrington
>
> [email-masked] <mailto:[email-masked]>
>
> +1-603-828-1401
>
> *From:*Dave Thaler [mailto:[email-masked]]
> *Sent:* Tuesday, June 09, 2015 5:45 PM
> *To:* Benoit Claise; David Harrington
> *Subject:* RE: [MIB-DOCTORS] InetAddress and InetAdressType
> *Cc:* [email-masked]
> <mailto:[email-masked]>; MIB Doctors
> (E-mail)

---

From: Benoit Claise <[email-masked]>
Date: Fri, 12 Jun 2015 16:11:26 +0200

MIB doctors,

What's your guidance on this one?
> require specification for each range, that constraint has to go into 
> the DESCRIPTION clause at the address range level, instead of the 
> present arrangement.
Regards, Benoit
> .

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Jun 2015 17:34:23 +0200

Benoit,

RFC 4001 says this:

The description of natv2PoolRangeBegin and natv2PoolRangeEnd both
specify in the description clause which InetAddressType object is
relevant - so this is fine. Having the associated InetAddressType
registered before the InetAddress object is a suggestion but not a
MUST. And this suggestion does not apply here since the
InetAddressType in in a different row.

Now, let me try to check whether I understand the table indexing.  The
natv2PoolEntry is indexed by { natv2PoolInstanceIndex, natv2PoolIndex
} while the natv2PoolRangeEntry is indexed by {
natv2PoolRangeInstanceIndex, natv2PoolRangePoolIndex,
natv2PoolRangeRowIndex }. This seems to be OK, the natv2PoolRangeTable
seems to be an extension table of natv2PoolTable. (I would probably
have used natv2PoolInstanceIndex and natv2PoolIndex in the
natv2PoolRangeEntry but this is more a style question.)

Bottom line: I think what is in draft-perrault-behave-natv2-mib-04.txt
is actually OK.

/js

On Fri, Jun 12, 2015 at 04:11:26PM +0200, Benoit Claise wrote:
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors