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
- [Disman] FW: draft-ietf-disman-remops-mib-v2-09.t… Wijnen, Bert (Bert)
- RE: [Disman] FW: draft-ietf-disman-remops-mib-v2-… Wijnen, Bert (Bert)
- RE: [Disman] FW: draft-ietf-disman-remops-mib-v2-… Pekka Savola
- RE: [Disman] FW: draft-ietf-disman-remops-mib-v2-… Wijnen, Bert (Bert)
- RE: [Disman] FW: draft-ietf-disman-remops-mib-v2-… Pekka Savola
- Re: [Disman] FW: draft-ietf-disman-remops-mib-v2-… Juergen Schoenwaelder
- RE: [Disman] FW: draft-ietf-disman-remops-mib-v2-… Juergen Quittek
- RE: [Disman] FW: draft-ietf-disman-remops-mib-v2-… Juergen Quittek
- RE: [Disman] FW: draft-ietf-disman-remops-mib-v2-… Pekka Savola