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

[Pekka Savola <[e-mail]>]

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 
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.

>>>> 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.

Yes, those examples would be OK with just IPv4.

Nowhere does it say that those are IPv4-specific examples (and if it 
said, I'd have a problem with that because the spec needs to be 
IP-version -agnostic :), so the readers should assume they are generic 
examples, right?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings