Rafael Martinez (Squid development) wrote:
Having now read 4001. I feel the squid tables with IP fall under section
1, pg 3, "type 1" objects.
Which leaves us with:
- "SHOULD implement" InetAddress
- "strongly discouraged" from using the split method
OK
Section 5 covers a table index usage case pretty close to the reality in
squid. That said, their way of neutral is way more complex than I had
thought.
Hmmm... Why ?
- Because backwards-compatibility (squid 2.X) is lost ?
- Because squid snmp_agent must be recoded ?
I was hoping to find a MIB that would map 1:1 (bonus for compatible)
possibly with type built-in as part of the field. Instead its another
layer and a type field in a neighboring leaf.
Oh well, could be worse.
We can almost borrow that bunch of specification for ours... Take a
look for the "diff" proposal below ( it is not commit )
To alleviate we have:
InetAddressIPv6 - "MAY be used either on its own or in conjunction
with InetAddressType, as a pair".
InetAddressIPv4 - same.
Making cachePeerAddr -> InetAddressIPv6 would be cleanest of all three
if not entirely neutral.
And coding IPv4 cachePeerAddr as IPv6-mapped addresses ?
This would also destroy backwards-compatibility, sizes are different.
Yes, True.
?? by My full reading of 4001 and skim of 2465 I get the opposite.
4001 appears to define enough available to use neutral fairly easily.
2465 still seems major overkill, and itself imports the IPv6Address TC
from somewhere else that we would otherwise be importing through it.
Absolute agree.
Some proposal.
===========================================================================
16,17c16,17
< Ipv6Address
< FROM IPV6-TC;
---
InetAddressType, InetAddress
FROM INET-ADDRESS-MIB;
722c722
< INDEX { cachePeerAddr }
---
INDEX { cachePeerAddressType, cachePeerAddress }
727c727,728
< cachePeerAddr IpAddress,
---
cachePeerAddressType InetAddressType,
cachePeerAddress InetAddress,
750,756c751,785
< cachePeerAddr OBJECT-TYPE
< SYNTAX IpAddress
< MAX-ACCESS read-only
< STATUS current
< DESCRIPTION
< " The IP Address of the peer cache "
< ::= { cachePeerEntry 2 }
---
cachePeerAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of Internet address by which the peer
is reachable."
::= { cachePeerEntry 2 }
cachePeerAddress OBJECT-TYPE
SYNTAX InetAddress (SIZE (1..64))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Internet address for the peer. The type of this
address is determined by the value of the peerAddressType
object. Note that implementations must limit themselves
to a single entry in this table per reachable peer.
The peerAddress may not be empty due to the SIZE
restriction.
If a row is created administratively by an SNMP
operation and the address type value is dns(16), then
the agent stores the DNS name internally. A DNS name
lookup must be performed on the internally stored DNS
name whenever it is being used to contact the peer.
Do we actually use the DNS type in peer cache?
If a row is created by the managed entity itself and
the address type value is dns(16), then the agent
stores the IP address internally. A DNS reverse lookup
must be performed on the internally stored IP address
whenever the value is retrieved via SNMP."
::= { cachePeerEntry 3 }
<snip remaining>
Looks great.
If you are OK coding that, Its a go from me now.
Amos
