[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