Re: RFC 4293 - ipAddressTable

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

On Wed, Oct 10, 2007 at 02:33:58PM -0500, Greg.Rabil at ins.com wrote:

> It is my understanding that the ipAddressTable roughly replaces the
> ipAddrTable.  However, the ipAdEntAddr OID is "read-only" in RFC2011,
> whereas the ipAddressAddrType and ipAddressAddr OIDs defined in RFC 4293
> are "not-accessible".  Similarly, the pertinent OIDs of the
> ipAddressPrefixTable are "not-accessible".  Am I missing something
> obvious here?

See section 7.7 of RFC 2678. The top of page 29 describes the two
circumstances under which auxiliary objects (table index objects) are
not-readonly:

: (1)  within a MIB module originally written to conform to SMIv1, and
:      later converted to conform to SMIv2; or
: 
: (2)  a conceptual row must contain at least one columnar object which is
:      not an auxiliary object.  In the event that all of a conceptual
:      row's columnar objects are also specified in its INDEX clause, then
:      one of them must be accessible, i.e., have a MAX-ACCESS clause of
:      "read-only".

In other words, RFC 4293 follows the SMIv2 rules where the only way to
retrieve auxiliary not-accessible objects (table index objects) is to
decode the values encoded in the object identifiers of the table
objects.

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------