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

"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Tue, 14 March 2006 12:03 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ8Fl-0004yZ-Tq; Tue, 14 Mar 2006 07:03:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ8Fk-0004yU-IY for disman@ietf.org; Tue, 14 Mar 2006 07:03:52 -0500
Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ8Fk-00074n-4u for disman@ietf.org; Tue, 14 Mar 2006 07:03:52 -0500
Received: from ihemail1.lucent.com (h192-11-222-161.lucent.com [192.11.222.161]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2EC3jLb003892; Tue, 14 Mar 2006 06:03:46 -0600 (CST)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2EC3gbu009686; Tue, 14 Mar 2006 06:03:43 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <G3YWYGD2>; Tue, 14 Mar 2006 13:03:40 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15506AD785E@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: 'Pekka Savola' <pekkas@netcore.fi>
Subject: RE: [Disman] FW: draft-ietf-disman-remops-mib-v2-09.txt
Date: Tue, 14 Mar 2006 13:03:41 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Cc: "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
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

W.r.t.
> >> 2) In lookupCtlTargetAddressType (for example), the user is required
> >> to specify whether the address in IP->name conversion is IPv4 or IPv6
> >> address.  This is unfortunate; you should not need to specify that, as
> >> the lookup functions are able to figure it out on their own. You
> >> should be able to give also 'ip' which would do v4 lookup if the
> >> address is v4 or v6 lookup if the address is v6, as appropriate.
> >>
> >
> > The format is REQUIRED in order for the SNMP agent to be able to determine
> > (and validate) the content of the lookupCtlTargetAddress object itself.
> > So it is inherent in the use of these TCs, and not because it is
> > needed for underlying lookup functions.
> 
> But it would be possible to have a lookup type where the TC is 
> basically "any text string that is less than 50 characters in length?
> Because if you give an address to look up with 'nslookup', the 
> address is just an opaque text blob..
> 

Pekka, this may be true for how you pass the address to the underlying 
lookup function. But I think what you are after here does NOT belong
in the InetAddressType and InetAddress TCs (see RFC4001). So I would
strongly recommend to keep what we have. An implementation can choose
to just use the InetAddress value and pass that as is to the
underlying lookup functions which will then figure out what sort of
address it is. 

> >> 3) The specification includes a lot of 'getaddrinfo() or
> >> gethostbyname()' and 'getnameinfo() or gethostbyaddr()', but the
> >> latter functions do not support IPv6.  Is there any reason to mention
> >> those at all, because you can't implement this MIB mobule (so that it
> >> could support v6) just by using gethostbyname/gethostbyaddr?  I'd
> >> suggest just mentioning getaddrinfo/getnameinfo().
> >>
> >
> > They are listed as "for example", so I think that that is OK.
> 
> I have to disagree with this because the example doesn't work. (On the 
> other hand, if the spec said, "getaddrinfo() or gethostbyname() and 
> gethostbyname2()", then I think it would be workable though 
> deprecated by the latest IPv6 API documents.
> 

I guess the examples are IPv4 examples, no? 
Does it not work for that either? 
If it does work for IPv4, then I think the examples are fine.
If not even that, then maybe a better example can be used instead.

Bert
> >> Editorial
> >> ---------
> >>
> >> ==> usually (not sure about MIB modules), differences to 
> the previous
> >> RFC are listed in the draft, maybe in an appendix.  This 
> information
> >> is mostly available in the draft, but it's scattered in 3
> >> places.  Not
> >> sure if it'd make sense to sum it up.
> >>
> >>      traceRouteCtlPort OBJECT-TYPE
> >>         SYNTAX      Unsigned32 (1..65535)
> >>         UNITS       "UDP Port"
> >>         MAX-ACCESS  read-create
> >>         STATUS      current
> >>         DESCRIPTION
> >>             "Specifies the UDP port to send the traceroute
> >>             request to.  Need to specify a port that is not in
> >>             use at the destination (target) host.  The default
> >>             value for this object is the IANA assigned port,
> >>             33434, for the traceroute function."
> >>         DEFVAL { 33434 }
> >>         ::= { traceRouteCtlEntry 9 }
> >>
> >> ==> actually, most implementations use the UDP port number for the
> >> _first_ traceroute they send, incrementing the port number for next
> >> messages, so that you can distinguish which hop the replies came
> >> from.  So, the text may require a minor tweak.
> >>
> >
> > Fine. Even so the initial value would be the one to start from, no?
> >
> > So I do not see a need to add text.
> 
> Certainly, but the problem is that the text doesn't say "initial", so 
> the above description could be interpreted to be normative, 
> i.e., "all 
> the traceroute probes must originate from this port number".
> 
> The minor clarification can easily be addressed by rewording:
> 
> >>             "Specifies the UDP port to send the traceroute
> >>             request to.  Need to specify a port that is not in
> >>             use at the destination (target) host.  The default
> ...
> 
> to e.g.,:
> 
> >>             "Specifies the initial UDP port to send the traceroute
> >>             request to.  Need to specify a port that is not in
> >>             use at the destination (target) host.  The default
> 
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>