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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 14 Mar 2006 13:03:41 +0100

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
>

---

From: Pekka Savola <[email-masked]>
Date: Tue, 14 Mar 2006 17:03:26 +0200 (EET)

...
> underlying lookup functions which will then figure out what sort of

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.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 14 Mar 2006 16:41:47 +0100

> (letting the MIB module implementation to figure it out) would be 

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

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 15 Mar 2006 00:23:26 +0100

Pekka,

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

> 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
[email-masked] 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.

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