headers
Joel M. Halpern | 7 Mar 2006 00:10

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

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

This document is nearly ready for publication as a Proposed 
Standard.  I have one concern, described below, and a few minor comments.

The definition of the lookup tables bothers me.
The short form:
     The name of the MIB is NSLOOKUP.  The name of the operation is 
dns.  But the definition is not
     "perform a dns A or AAAA lookup."  It is, "do the equivalent of 
some API" that the host may or may not have.
     This is not a good functional definition.
The function is defined in very general terms.  It performs either a 
symbolic lookup to get an IP address, with further definition only in 
terms of the name of common API functions, or a reverser lookup to 
get from IP address to name, again with the functional requirement 
given in terms of an API name.  Given that these APIs are not 
standardized 9and no particular implementation is referenced) this is 
not a clear, implementable, interoperable definition.
I suspect that the intent here is to allow whatever the host would do 
with a typical application request to get this kind of 
information.  And that it is specifically vague so as to allow 
reference to caches or local configuration tables, as the host would perform.
However, the text does not say "Do what you would do for a local 
application."  It says "do something like these APIs."
If the intent is explicitly to cause local caching / config tables to 
be visible to the MIB, then we MUST say that.
If the intent is to perform a DNS lookup from that host (forward or
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 10 Mar 2006 15:32
Picon
Favicon

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

FYI and follow up.
I have not looked at this in detail yet (may not
get to it untill Tuesday next week). So forwarding
to WG for review/comment/response.

Bert

-----Original Message-----
From: owner-ops-dir <at> ops.ietf.org [mailto:owner-ops-dir <at> ops.ietf.org]On
Behalf Of Pekka Savola
Sent: Friday, March 10, 2006 11:23
To: Ops Directorate
Subject: draft-ietf-disman-remops-mib-v2-09.txt

On Thu, 9 Mar 2006, David Kessens wrote:
...

I don't usually look at MIB modules, but did take a peek at 
draft-ietf-disman-remops-mib-v2-09.txt.

A couple of comments below.

Substantial
-----------

I have a number of concerns about NSLOOKUP part of the MIB mobule.

1) It's not clear whether the host, given e.g., 'dns' as a lookup 
type, is only supposed to make a DNS lookup (which is what 'nslookup' 
does), or also consult /etc/hosts or equivalent (also possibly NIS or
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 11 Mar 2006 23:12
Picon
Favicon

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

OK, looked into this in some more detail.
Inline my responses. Document author or WG chair can chime
in if they want.

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen <at> lucent.com]
> Sent: Friday, March 10, 2006 15:32
> To: Disman (E-mail) (E-mail)
> Cc: David Kessens (E-mail); Pekka Savola (E-mail)
> Subject: [Disman] FW: draft-ietf-disman-remops-mib-v2-09.txt
> 
> 
> FYI and follow up.
> I have not looked at this in detail yet (may not
> get to it untill Tuesday next week). So forwarding
> to WG for review/comment/response.
> 
> Bert
> 
> -----Original Message-----
> From: owner-ops-dir <at> ops.ietf.org [mailto:owner-ops-dir <at> ops.ietf.org]On
> Behalf Of Pekka Savola
> Sent: Friday, March 10, 2006 11:23
> To: Ops Directorate
> Subject: draft-ietf-disman-remops-mib-v2-09.txt
> 
> 
> On Thu, 9 Mar 2006, David Kessens wrote:
> ...
>
(Continue reading)

Permalink | Reply | 502 comments |
headers
Pekka Savola | 13 Mar 2006 09:13
Picon

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

On Sat, 11 Mar 2006, Wijnen, Bert (Bert) wrote:
> OK, looked into this in some more detail.
> Inline my responses. Document author or WG chair can chime
> in if they want.
...
>> Substantial
>> -----------
>>
>> I have a number of concerns about NSLOOKUP part of the MIB mobule.
>>
>> 1) It's not clear whether the host, given e.g., 'dns' as a lookup
>> type, is only supposed to make a DNS lookup (which is what 'nslookup'
>> does), or also consult /etc/hosts or equivalent (also possibly NIS or
>> other similar directories as specified by /etc/nsswitch.conf or
>> equivalent) if appropriate.
>>
>
> Possibly that could be clarified somewhat. I think it is an implementation
> matter (the way I interpret it), but even that could be stated.
> If WG chair and author/editor agree, pls sens a proposed piece of text
> that I can tell RFC-Editor to add.

Agreed.  I don't think this is a major issue itself, but if the intent 
is to give consistent results across implementations, some things need 
to be said about this.

>> 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
(Continue reading)

Permalink | Reply | 503 comments |
headers
Randy Presuhn | 13 Mar 2006 20:35
Picon

Fw: [Gen-art] Re: LC Review: draft-ietf-disman-remops-mib-v2-09.txt

Hi -

More comments.  Reponses, particularly from implementors, would be
most welcome.

Randy

----- Original Message ----- 
> From: "Brian E Carpenter" <brc <at> zurich.ibm.com>
> To: "Joel M. Halpern" <joel <at> stevecrocker.com>
> Cc: "Randy Presuhn" <randy_presuhn <at> mindspring.com>; "Bert Wijnen" <bwijnen <at> lucent.com>; "Dan >
Romascanu" <dromasca <at> avaya.com>;
<quittek <at> ccrle.nec.de>; <wkenneth <at> us.ibm.com>
> Sent: Monday, March 13, 2006 4:35 AM
> Subject: Re: [Gen-art] Re: LC Review: draft-ietf-disman-remops-mib-v2-09.txt
>

> All,
>
> I have tuned the cc list.
>
> Is there any reason the draft doesn't simply cite the socket API
> standard to define the lookup functions? I'm a bit confused
> about versions, but I believe that the latest version of
> the Open Group/POSIX 'Networking Services' standard is the right one.
>
> RFC 3493 could also be cited for IPv6 but isn't standards track.
>
> Anyway, a firm citation, and clarification of the caching vs direct
> resolution issue seems to be needed.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 14 Mar 2006 13:03
Picon
Favicon

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

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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Pekka Savola | 14 Mar 2006 16:03
Picon

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

On Tue, 14 Mar 2006, Wijnen, Bert (Bert) wrote:
>>>> 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.
...
>
> 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.

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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Juergen Schoenwaelder | 14 Mar 2006 16:41
Picon

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

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juergen Quittek | 15 Mar 2006 00:23
Picon

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

Pekka,

--On 3/14/06 5:03 PM +0200 Pekka Savola wrote:

> On Tue, 14 Mar 2006, Wijnen, Bert (Bert) wrote:
>>>>> 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.
> ...
>>
>> 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.
>
> 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?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juergen Quittek | 15 Mar 2006 01:10
Picon

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

Joel,

Thank you for your comments.
Please see replies inline.

--On 3/6/06 6:10 PM -0500 Joel M. Halpern wrote:

> I was selected as General Area Review Team reviewer for this specification
> (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> This document is nearly ready for publication as a Proposed Standard.
> I have one concern, described below, and a few minor comments.
>
> The definition of the lookup tables bothers me.
> The short form:
>      The name of the MIB is NSLOOKUP.  The name of the operation is dns.

The MIB module specification does not necessarily require an implementation
to use DNS.  So the operation is name lookup.

>      But the definition is not "perform a dns A or AAAA lookup."  It is,
>      "do the equivalent of some API" that the host may or may not have.
>      This is not a good functional definition.

Indeed.  But this is the intention of the MIB module.  Usually, there
is more value in finding out with what result an actual name is resolved
at a remote host than what DNS delivers to this host as resolution.

> The function is defined in very general terms.  It performs either a
(Continue reading)

Permalink | Reply | 4 comments |

Gmane