Re: draft-ops-endpoint-mib-04.txt

[Mike Daniele <daniele@zk3.dec.com>]

Dave Thaler wrote:

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

I agree.  Thanks for pointing this out.
My opinions are offered below.

Mike

>
> Some questions that should be answered by 4.1:
> 1) Must the InetAddressType object come IMMEDIATELY before the
>    InetAddress object in the INDEX?

Yes.

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

Yes.

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

No.

>  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