Subject: Re: (ngtrans) DNS text in draft-ietf-ngtrans-mech-v2-00.txt (Fwd)

From: Erik Nordmark <[email-masked]>
Date: Mon, 5 Aug 2002 10:25:50 +0200 (CEST)

Robert intended this to be copied to the list.

>----------------Begin Forwarded Message----------------<

Date: Thu, 01 Aug 2002 17:44:14 +0700
From: "Robert Elz" <[email-masked]>
Subject: Re: (ngtrans) DNS text in draft-ietf-ngtrans-mech-v2-00.txt 
To: "Erik Nordmark" <[email-masked]>

    Date:        Wed, 31 Jul 2002 19:41:00 +0200 (CEST)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <[email-masked]>

  | Is the above information still useful?

Yes.

  | In conflict with the address selection dociment?

No.

  | Should the document just refer
  | to the address-select document for all of this?

No, let that one just deal with how to handle selection among different
ipv6 addresses (which is complex enough) without having to also attempt to
deal with the selection between v4 & v6 (which is more properly an ngtrans
matter).

[email-masked] said:
  | it is fundamentally unacceptable for resolver libraries to interfere
  | with the results of a DNS query.    the resolver is NOT smarter than
  | the applications. 

Read it all again Keith.   Especially the second last sentence...

   An implementation MUST allow the application to control whether or
   not such filtering takes place.

All that the whole section is doing is describing what getaddrinfo()
does already (that is, has flags passed from the application to say
which addresses are wanted) - but without actually describing any
particular API.

What is there is just fine.

kre

>----------------End Forwarded Message----------------<

---

From: Keith Moore <[email-masked]>
Date: Mon, 05 Aug 2002 07:24:26 -0400

> which addresses are wanted) - but without actually describing any

the problem is that the statement in the document, taken by itself,
is too open-ended.   perhaps the getaddrinfo API is fine, but the 
same statement could be used to justify an API which made it obscure 
or difficult to disable the filtering.

that, and the host isn't in a good position to know what kind of 
filtering is appropriate - so it's bad to encourge such practices
even if we insist that it must be possible to disable them.

Keith