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

[Juergen Quittek <[e-mail]>]

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?

There are some arguments on the networks management side to stick to these TCs.
[I think we can agree on the point that on the application side
(traceroute) it does not matter how its parameters had been encoded
before they were applied.]

But on the network management side, the InetAddress TCs are the known
and common way to encode an Internet address.  It is not a convenient
way, but I am glad there is a single common one that fits most cases.
(after deprecation of the IpAddress TC from RFC 2578, that was IPv4 only).

We might want to ask the authors of RFC 4001, why they did the encoding
with two objects (which I do not really like).  Is it for allowing to add
consistency checks and increase safety?  Or are there other reasons?
But anyway, I would rather use them then invent a different encoding in
each new MIB module.  Because this would mean that I need to convert
IP addresses from one MIB module to another.  This would also mean that
I need a collection of IP address encoding and decoding routines, one
per different encoding.

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

This sounds good.  But the right place to discuss this is probably the
[e-mail] mailing list and not the review of the remops MIB
modules that use the TC that was agreed on to be used for this purpose.

Before a MIB module runs through IESG review, it runs through a MIB doctor
review.  If you use an opaque string for Internet addresses in a MIB module,
it will be very hard to find a MIB doctor that would NOT strongly recommend
you using the InetAddress TCs of RFC 4001 instead.

There are guidelines for authors and reviewers on MIB modules (RFC 4181)
They RECOMMEND using the InetAddress TCs.

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

I just checked the I-D for occurrences of gethostbyname and gethostbyaddr
They never listed alone, but always as "getaddrinfo() or gethostbyname()"
or "getnameinfo() or gethostbyaddr()".  So the new IP-agnostic function
is mentioned first and the old IPv4-only function is mentioned second.

If you assume that there might be implementers that run into problems
because they try to use gethostbyname for IPv6, we can add a statement
on that.  But I do not think that this is necessary.

I agree that the standard should support both, IPv4 and IPv6 well.
I do not agree that a standard necessarily need to be IP-agnostic,
because there are indeed differences between v4 and v6.

I don't think the remops MIB specifications should require that every
implementation of these modules MUST support both v4 and v6.  Pure
v6 implementation should be supported as well as pure v4 implementations.

While ignoring the choice of the implementer, it seems to be helpful
to give the implementer good guidance in any case by mentioning the most
common functions (s)he will find on a device for implementing a module.
And these are getxxxxinfo functions as well as the gethostbyxxxx functions.
If there were commonly known v6-only functions, it would be beneficial
to list them too.

Thanks,

    Juergen Q.

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