[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ops-endpoint-mib-04.txt
> 4.1 Table Indexing
>
> When a generic Internet address is used as an index, both the
> InetAddressType and InetAddress objects MUST be used, and the
> InetAddressType object MUST come first in the INDEX clause.
>
> The IMPLIED keyword MUST NOT be used for an object of type
> InetAddress in an the INDEX clause. Instance subidentifiers are then
> of the form T.N.O1.O2...On, where T is the value of the
> InetAddressType object, O1...On are the octets in the InetAddress
> object, and N is the number of those octets.
I think this section is under-specified with regards to how
to handle INDEX clauses which require multiple addresses.
Some questions that should be answered by 4.1:
1) Must the InetAddressType object come IMMEDIATELY before the
InetAddress object in the INDEX? Or can there be other
objects in between? (the above text says the Type MUST come
first, but doesn't explicitly say whether the address MUST come
second, although the form shown does imply "immediately").
2) If you have multiple addresses in the INDEX, does every
address object require its own Type object, or if there is
only 1 type object, must a vanilla NMS assume it applies
to all address objects in the index? In other words,
is the form T.N.A1.A2.A2.A4.N.B1.B2.B3.B4 valid for a table
indexed by two addresses of the same type? The multicast
MIB has examples of this type of table, where state
is indexed by both a source address and a destination address
(which of course must be in the same address family).
If every address requires (or is allowed to have, if both
ways are valid) its own type, then the text about "must
come first" could be misinterpreted to mean the first
object in the index, rather than "immediately before
the address".
If only a single type object is allowed, then one cannot
represent tables with different types of addresses, so
I will assume this is not what is desired.
-Dave Thaler