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