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

Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de> Tue, 14 March 2006 15:40 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJBdq-0006eO-9H; Tue, 14 Mar 2006 10:40:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJBdp-0006eJ-Al for disman@ietf.org; Tue, 14 Mar 2006 10:40:57 -0500
Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJBdn-0004pn-SO for disman@ietf.org; Tue, 14 Mar 2006 10:40:57 -0500
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id CCDA95407B; Tue, 14 Mar 2006 16:40:54 +0100 (CET)
Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29556-03; Tue, 14 Mar 2006 16:40:53 +0100 (CET)
Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id E3CCA53EE9; Tue, 14 Mar 2006 16:40:52 +0100 (CET)
Received: by boskop.local (Postfix, from userid 501) id 6B11F63242D; Tue, 14 Mar 2006 16:41:47 +0100 (CET)
Date: Tue, 14 Mar 2006 16:41:47 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Pekka Savola <pekkas@netcore.fi>
Subject: Re: [Disman] FW: draft-ietf-disman-remops-mib-v2-09.txt
Message-ID: <20060314154147.GA29871@boskop.local>
Mail-Followup-To: Pekka Savola <pekkas@netcore.fi>, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, "David Kessens (E-mail)" <david.kessens@nokia.com>, "Disman (E-mail) (E-mail)" <disman@ietf.org>
References: <7D5D48D2CAA3D84C813F5B154F43B15506AD785E@nl0006exch001u.nl.lucent.com> <Pine.LNX.4.64.0603141653280.740@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.0603141653280.740@netcore.fi>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, "David Kessens (E-mail)" <david.kessens@nokia.com>, "Disman (E-mail) (E-mail)" <disman@ietf.org>
X-BeenThere: disman@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@iu-bremen.de
List-Id: Distributed Management <disman.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/disman>, <mailto:disman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/disman>
List-Post: <mailto:disman@ietf.org>
List-Help: <mailto:disman-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/disman>, <mailto:disman-request@ietf.org?subject=subscribe>
Errors-To: disman-bounces@ietf.org

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