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

From: Randy Presuhn <[email-masked]>
Date: Fri, 12 Jun 2015 16:12:56 -0700 (GMT-07:00)

Hi -

The DESCRIPTION of natv2SubscriberInternalPrefix should
identify natv2SubscriberInternalPrefixType as providing
its address type.  Likewise for
natv2AddressMapInternalAddressType and natv2AddressMapInternalAddress
natv2AddressMapInternalMappedAddressType and natv2AddressMapInternalMappedAddress
natv2AddressMapExternalAddressType and natv2AddressMapExternalAddress
natv2PortMapExternalAddressType and natv2PortMapExternalAddress
natv2PortMapInternalAddressType and natv2PortMapInternalAddress
natv2PortMapInternalMappedAddressType and natv2PortMapInternalMappedAddress.

The textual conventions definition states:
         Every usage of the InetAddress
         textual convention is required to specify the InetAddressType
         object that provides the context.

The relationship between natv2PoolAddressType and
natv2PoolRangeBegin and natv2PoolRangeEnd is already
properly documented in the DESCRIPTION clauses, so
I see no problem there.

There is a *suggestion* in the TC's definition:
         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.

But that same text makes it clear that the objects *may* appear in different
rows, so I see no problem at all with this.

Randy

>From: Benoit Claise <[email-masked]>
>Sent: Jun 12, 2015 7:11 AM
>To: Tom Taylor <[email-masked]>, ietfdbh <[email-masked]>, 'Dave Thaler' <[email-masked]>
>Cc: [email-masked], "'MIB Doctors (E-mail)'" <[email-masked]>
>Subject: Re: [MIB-DOCTORS] InetAddress and InetAdressType (draft-perrault-behave-natv2-mib-04 compilation)
>
>MIB doctors,
>
>What's your guidance on this one?
>> 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.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 16 Jun 2015 16:42:46 -0400

Updated DESCRIPTION clauses as indicated.

Tom Taylor