🚀 go-pugleaf

I'm trying to make sense of the last few paragraphs of Section 5.3.2
"Problems with Naming" in _The Simple Book_:

        "Of course, it might be possible that there is no way to
    uniquely identify a particular entry in the table. ..."

        "A special "hack" can be used in this case.  If multiple
    rows in a table have the same key, the agent marks one of
    these rows as the primary.  The other rows with the same key
    are ... assigned an implementation-dependent, small, unique
    non-negative integer. To identify an instance of a secondary
    row, this integer is appended onto the instance identifier of
    the primary row."

My (embedded) protocol stack maintains a separate connection endpoint for
each possible TCP connection to a server.  New connection requests are
handled by finding the first entry in the table with the correct local
address/port in state LISTEN, copying the remote address/port information
from the packet into the entry, and setting the entry state to SYN-RECEIVED.
What this means for SNMP is that there are often a number of connection
endpoints with identical address/port information, i.e. local address
0.0.0.0, local port 8000, remote address 0.0.0.0, and remote port 0,
all in state LISTEN.  I'd like to make all these endpoints visible for
monitoring, since the number of "available" endpoints is an important
resource limitation.

Assuming three such entries, the text would seem to imply that the
corresponding instances of tcpConnState would be named:

    tcpConnState.0.0.0.0.8000.0.0.0.0.0
    tcpConnState.0.0.0.0.8000.0.0.0.0.0.1
    tcpConnState.0.0.0.0.8000.0.0.0.0.0.2

This is admittedly somewhat awkward to implement, since the resulting
instance identifiers aren't all the same length, but I could live with
that.  The nagging problem is that I can't find any support for this
"hack" in the SNMP or MIB RFCs or in any of the public implementations
I've looked at.

Is my interpretation correct?

Steve Tarr
Tektronix, Inc. GPID
stevet@pogo.wv.tek.com