> 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 ?
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.
> ?? 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. > > 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 } > 764c793 < ::= { cachePeerEntry 3 } --- > ::= { cachePeerEntry 4 } 773c802 < ::= { cachePeerEntry 4 } --- > ::= { cachePeerEntry 5 } 781c810 < ::= { cachePeerEntry 5 } --- > ::= { cachePeerEntry 6 } 789c818 < ::= { cachePeerEntry 6 } --- > ::= { cachePeerEntry 7 } 797c826 < ::= { cachePeerEntry 7 } --- > ::= { cachePeerEntry 8 } 805c834 < ::= { cachePeerEntry 8 } --- > ::= { cachePeerEntry 9 } 813c842 < ::= { cachePeerEntry 9 } --- > ::= { cachePeerEntry 10 } 821c850 < ::= { cachePeerEntry 10 } --- > ::= { cachePeerEntry 11 } 829c858 < ::= { cachePeerEntry 11 } --- > ::= { cachePeerEntry 12 } 837c866 < ::= { cachePeerEntry 12 } --- > ::= { cachePeerEntry 13 } 845c874 < ::= { cachePeerEntry 13 } --- > ::= { cachePeerEntry 14 }Received on Mon Oct 22 2007 - 02:09:34 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Oct 30 2007 - 13:00:03 MDT