Subject: [MIB-DOCTORS] Question on using only InetAddress as an index

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 18 Mar 2009 00:58:03 -0500

Hello MIB Doctors,

The draft OSPFv3 MIB contains 2 tables which use
InetAddressType (ipv6) and InetAddress(SIZE(16)) as indexes,
so for example, here's the indexing of the ospfv3HostTable:

            INDEX           { ospfv3HostAddressType, 
                              ospfv3HostAddress } 
            ::= { ospfv3HostTable 1 } 
 
    Ospfv3HostEntry ::= SEQUENCE { 
            ospfv3HostAddressType 
                    InetAddressType, 
            ospfv3HostAddress 
                    InetAddress, 
   ...  

            } 
 
    ospfv3HostAddressType OBJECT-TYPE 
            SYNTAX          InetAddressType{ ipv6(2) }
            MAX-ACCESS      not-accessible 
            STATUS          current 
            DESCRIPTION 
                "The address type of ospfv3HostAddress. Only IPv6 
                global address type expected." 
            REFERENCE 
                "OSPF Version 2, Appendix C.6 Host route  
                parameters" 
            ::= { ospfv3HostEntry 1 } 

    ospfv3HostAddress OBJECT-TYPE 
            SYNTAX          InetAddress (SIZE (16))
            MAX-ACCESS      not-accessible 
            STATUS          current 
            DESCRIPTION 
                "The IPv6 Address of the Host. Must be an 
                IPv6 global address." 
            REFERENCE 
                "OSPF Version 2, Appendix C.6 Host route 
                parameters" 
            ::= { ospfv3HostEntry 2 } 

If the only possibility for an address is a global ipv6 address, 
then should only the InetAddress (SIZE(16)) be used and remove
the InetAddressType{ ipv6(2) } ?

Thanks,
  -Joan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Mar 2009 06:47:55 +0100

> the InetAddressType{ ipv6(2) } ?

If the MIB object in question never ever carries anything different
than an InetAddressIPv6 value, simply use InetAddressIPv6 instead of
the generic InetAddress and remove the InetAddressType constant. This
is for example done in the IPV6-MLD-MIB. This seem to affect several
places in the MIB module.

/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: "Randy Presuhn" <[email-masked]>
Date: Wed, 18 Mar 2009 12:29:25 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Joan Cucchiara" <[email-masked]>
> Cc: "MIB Doctors (E-mail)" <[email-masked]>; "Dan Joyal" <[email-masked]>
> Sent: Tuesday, March 17, 2009 10:47 PM
> Subject: Re: [MIB-DOCTORS] Question on using only InetAddress as an index
...
...

I agree with Juergen, with the proviso that this should be done only if
IPv6 addresses are the only thing that is architecturally possible.  If there
is any conceivable way that this thing could be used for other address
types (even if the current implementation only supports the one) then
it's probably worth retaining the general-purpose mechanism.

Randy

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 19 Mar 2009 00:57:25 +0100

The general purpose mechanism allows for future changes like
- add another type (for example ipv10 with associated size) to the index OBJECTs
- then change the current MODULE-COMPLIANCE to only require IPV6
- add a new MODULE-COMPLIANCE to allow for ipv6 and ipv10

If you use the TC of InetAddressIPv6, then such a change woul require to
deprecate/obsolete the current table and create a new table that allows
for IPv6 and IPv10.

It is probably veruy unlikely that such will happen, and if it does, IPv10 may be so
much different that things need to change anyway. But that is the kind of 
tradeoff to be made (or so I think).

Bert
  ----- Original Message ----- 
  From: Randy Presuhn 
  To: MIB Doctors (E-mail) 
  Sent: Wednesday, March 18, 2009 8:29 PM
  Subject: Re: [MIB-DOCTORS] Question on using only InetAddress as an index

  Hi -

  ...
  ...

  Randy

  _______________________________________________
  MIB-DOCTORS mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/mib-doctors