Re: Re: MIBDoctorreview:publishdraft-ietf-disman-remops-mib-v2-06.txt

"Randy Presuhn" <[email protected]> Mon, 4 Jul 2005 12:10:08 -0700
Newsgroups gmane.ietf.disman
Message-ID <003601c580cc$1406c980$7f1afea9@oemcomputer>
Hi -

> From: "Juergen Quittek" <[email protected]>
> To: "Randy Presuhn" <[email protected]>; "Disman" <[email protected]>
> Sent: Sunday, July 03, 2005 2:02 PM
> Subject: Re: [Disman] Re: MIBDoctorreview:publishdraft-ietf-disman-remops-mib-v2-06.txt
...
> 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?

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.

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

As chair...
Agreed.

Randy