Subject: Re: [Disman] Re: MIB Doctor review:publishdraft-ietf-disman-remops-mib-v2-06.txt

From: Juergen Quittek <[email-masked]>
Date: Fri, 01 Jul 2005 13:57:34 +0200

Randy,

Juergen Schoenwaelder and I had a discussion for two hours this morning.

Since Juergen's comments were quite constructive, we could easily
agree on most of his suggestions.  However, we identified a few issues
that need to be discussed on the mailing list.

I will post the list of minor changes to the mailing list over the weekend.
Next week I will send individual mails explaining the issues that need
mailing list discussion.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

--On 6/29/2005 10:56 AM +0200 Juergen Schoenwaelder wrote:

> On Wed, Jun 29, 2005 at 10:59:48AM +0300, Romascanu, Dan (Dan) wrote:
>
>> May 4 - you forwarded the MIB Doctor review to the list
>> May 5 - you asked 'Does anyone on this mailing list *disagree*' with
>> JuergenS's recommendations from the review. The way you asked the
>> question silence means consent
>> Same day - JuergenQ answers that he agrees with JuergenS's
>> recommendations with some exceptions that he would try to discuss 'on
>> the phone in the next days'.
>>
>> Did the conversation between the two Juergens happen?
>
> Not yet.
>
>> Are we waiting for an I-D update from JuergenQ, or for something else?
>
> At the end, this is what we are waiting for.
>
> /js
>
> --
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 2 Jul 2005 12:14:10 -0700

Hi -

Thanks for the update!
I hope we can get this wrapped up before the i-d submission deadline.

Randy

> From: "Juergen Quittek" <[email-masked]>
> To: <[email-masked]>; "Romascanu, Dan (Dan)" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; "Disman" <[email-masked]>
> Sent: Friday, July 01, 2005 4:57 AM
> Subject: Re: [Disman] Re: MIB Doctorreview:publishdraft-ietf-disman-remops-mib-v2-06.txt
>
> Randy,
>

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 03 Jul 2005 00:54:24 +0200

Randy,

> I hope we can get this wrapped up before the i-d submission deadline.

This depends on the amount of discussion and editing that will be required
for solving the issue of the DNS query functions.  My guess is that we will
be able to solve it until Paris and have the new version immediately after.

    Juergen Q.

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 2 Jul 2005 16:25:30 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>; "Disman" <[email-masked]>
> Sent: Saturday, July 02, 2005 3:54 PM
...
> be able to solve it until Paris and have the new version immediately after.
...

Would holding a disman WG session in Paris help?

Randy

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 03 Jul 2005 23:02:48 +0200

Hi Randy,

I think most issues can well be solved on the mailing list.
The only issue that could be a discussion item of the session
is the idea behind the DISMAN-NSLOOKUP-MIB.

Basically, it is showing the actual name/address resolution at
the remote device.  But should it be just what DNS delivers to the
device or should the local configuration of name resolution be included?

Still, solving this point does not fill the agenda of a
DISMAN WG meeting.

    Juergen

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 4 Jul 2005 12:10:08 -0700

Hi -

> Sent: Sunday, July 03, 2005 2:02 PM
> Subject: Re: [Disman] Re: MIBDoctorreview:publishdraft-ietf-disman-remops-mib-v2-06.txt
...
> device or should the local configuration of name resolution be included?

As a technical contributor...

The operation is described in terms of the gethostbyname()
and gethostbyaddr() APIs, rather than protocol interactions.
Consequently, my interpretation is to use whatever those APIs
(or their equivalents) return on that system.  Whether the APIs
invoke DNS, NIS, a local database, something else, or some
combination isn't a consideration.

If this MIB is being used to diagnose application outages, this
seems a reasonable interpretation.  I believe our thinking was
that if the objective was to diagnose problems with the DNS
infrastructure itself, one would employ RFC 1611 / 1612.

Those have been declared Historic, so perhaps that rationale
might no longer be as sensible.  However, given where we are
in the process with this document, I think we should leave things
as they are: the table is populated with results from
gethostbyname() and gethostbyaddr().  If this isn't sufficiently
clear in the i-d, then I wouldn't object to adding a clarification.

...

As chair...
Agreed.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 4 Jul 2005 22:01:26 +0200

> clear in the i-d, then I wouldn't object to adding a clarification.

The results table uses the InetAddress convention to return the 
results. For DNS names, the InetAddressType would be dns(16). For 
other names, unknown(0) seems applicable.  The unfortunate news 
is that without some effort, there is no way to decide whether 
the name returned by gethostbyaddr() is a DNS name or not.

Another question concerns dual hosts with multiple names for different
addresses which may actually life in different address domains. Can an
application just pick randomly one address, call gethostbyaddr() or 
getnameinfo() and report the result? Or is it required to collect
and consolidate the information for all IP addresses? The current ID
uses language such as "official name" or "primary address" which are
not well defined.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 4 Jul 2005 13:20:49 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "Disman" <[email-masked]>
> Sent: Monday, July 04, 2005 1:01 PM
...
> the name returned by gethostbyaddr() is a DNS name or not.

The value of the InetAddressType qualifies the *syntax* of the InetAddress.
It doesn't indicate where the information "came from".  If something is
syntactically a DNS name, I believe the InetAddressType would be dns(16),
even if the value had been entered by a human or read from a paper tape.

...

I think section 3.3.3 paragraphs 4..6 address this by giving an operational
definition of the required behaviour:

   The gethostbyaddr function is called with a host address as its
   parameter and is used primarily to determine a symbolic name to
   associate with the host address.  Entries in the lookupResultsTable
   MUST be made for each host name returned.  The official host name
   MUST be assigned a lookupResultsIndex of 1.

   The gethostbyname function is called with a symbolic host name and is
   used primarily to retrieve a host address.  Normally, the first
   h_addr_list host address is considered to be the primary address and
   as such is associated with the symbolic name passed on the call.

   Entries MUST be stored in the lookupResultsTable in the order that
   they are retrieved.  Values assigned to lookupResultsIndex MUST start
   at 1 and increase in order.

In otherwords, whatever gethostbyname() / gethostbyaddr() list first
is what will be considered  "primary".  I don't think we can do much
better than that with the tools available to us.

Randy