Subject: Re: Schedule for remote operations work

From: Kenneth White <[email-masked]>
Date: Thu, 10 Sep 1998 06:39:44 -0400

Juergen,

Kenneth> In Chicago I asked if allowing for a symbolic name as a
Kenneth> target address, or in the case of traceroute returning the
Kenneth> DNS name of a hop, was needed.  I think the consensus was to
Kenneth> remove this from the ping and traceroute tables in order to
Kenneth> simplify them, but the function of determining what a
Kenneth> symbolic name would resolve to or what the symbolic name of
Kenneth> an address is at a remote host would be useful. The issuer of
Kenneth> a remote request may not have access to the same DNS
Kenneth> server(s) that a remote target does, also name resolution can
Kenneth> be locally defined at the target.

>Sounds like you want to return names coming from local name resolution
>configuration files and probably from other naming services like NIS
>in addition to DNS lookups. If this is true, than we should not call
>it a DNS lookup MIB. Further, I think it is important to know exactly
>what you got. Being able to get names of local significance which you
>can't easily convert back later on seems questionable, especially if
>you do not indicate what the response is based on (a DNS lookup, a
>local configuration file, a NIS lookup,...).

My only purpose is to enable building a complete remote ping or traceroute
function. The gethostbyname and gethostbyaddr functions as far I can
remember don't tell you where they got either the hostname or address.
Both ping and traceroute commands can show both address/name pairs.
I am concerned about adding subfunctions that I can't easily implement.

Are you objecting to the name of the function, the capabilities of the
function or the existence of the function?

I'm planning on accepting the direction of splitting the current MIB into
separate modules. For the purpose of this note let's focus just on
what I called a Remote DNS Lookup operation. As you and others pointed
out splitting out into separate modules enable future enhancement.
So we could expand this in the future if needed.

I tried to keep this function simple in order to meet my initial goal
of enabling a complete solution for a remote ping or traceroute
function and not attempting to expand the current ping or traceroute
commands with respect to DNS lookup. If you would like to see some
additions or changes made to the current remopsDnsLookupTable please
make a recommendation. I'm not entirely happy with the table lay-out.

As to the name of the corresponding MIB module how about DISMAN-LOOKUP-MIB?
I don't thing DISMAN-DNS-MIB is what we want since its not really a DNS
MIB.

Ken

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Sep 1998 17:31:54 +0200

>>>>> Kenneth White writes:

Kenneth> My only purpose is to enable building a complete remote ping
Kenneth> or traceroute function. The gethostbyname and gethostbyaddr
Kenneth> functions as far I can remember don't tell you where they got
Kenneth> either the hostname or address.  Both ping and traceroute
Kenneth> commands can show both address/name pairs.  I am concerned
Kenneth> about adding subfunctions that I can't easily implement.

Kenneth> Are you objecting to the name of the function, the
Kenneth> capabilities of the function or the existence of the
Kenneth> function?

All I want is a clear definition what the result of invoking a name
lookup through the remopsDnsLookupTable means. The functions
gethostbyname and gethostbyaddr do more than just DNS lookups. They
can return DNS names, NIS (aka YP) names, locally configured names and
probably others. If you want it to be "any locally known name" and
leave it open what this really is, than thats fine with me. But please
say what it is and don't call it a remote DNS lookup operation if it
returns non DNS names.
							Juergen

Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)