Re: FW: draft-ietf-disman-remops-mib-v2-09.txt

Juergen Schoenwaelder <[email protected]> Tue, 14 Mar 2006 16:41:47 +0100
Newsgroups gmane.ietf.disman
Message-ID <[email protected]>
On Tue, Mar 14, 2006 at 05:03:26PM +0200, Pekka Savola wrote:

> So, I guess the first order problem we have here is that while RC 4001 
> provides sufficient detailed TC's, it does not provide a standards 
> track mechanism of saying "this is an IP address, but I don't care 
> which IP version".
> 
> The secondary issue which isn't yet clear to me is what is the benefit 
> of using RFC 4001 TC's as the mandatory (or only) types in this 
> context.  I.e., is there harm to network management or the protocol in 
> allowing an arbitrary text string (with a maximum length) as input?
> 
> Either way, I don't care too much because I'm not going to use 
> NSLOOKUP MIB myself, but it seems really backwards if we depend either 
> on implementation specific InetAddress hacks or requiring the user to 
> specify the address type to look up.  Any approach that would require 
> allowing the user to specify an IP address without specifying its type 
> (letting the MIB module implementation to figure it out) would be 
> great.

The theory says that MIB modules are primarily programmatic interfaces
and this might help to understand why the TCs are defined the way they
are. In other words, the smart parsing task is left to the application
that talks SNMP to the agent implementing this MIB module.

One can sure question this division of work but I guess this reaches
far out of the scope of this particular MIB module we have on the
table.

Also note that this is a revision of a MIB module which means that any
design changes have drastic consequences to implementations. We would
have to deprecate objects and implementations would have to deal with
multiple versions of the MIB module. Given the costs involved, this
makes sense only if something is truely broken. I do not think the
usage of the InetAddress TCs is of that broken nature (but I must
admit that I am somewhat biased as someone who wrote the InetAddress
family of TCs).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany