Erik Nordmark wrote:
>One high-level comment I have about the document relates to its
>requirement that the mechanism be the last resort.
>
>How is this intended to work with LLMNR (draft-ietf-dnsext-mdns-12.txt)?
>One way of using LLMNR is to make *it* be the last resort, but since
>we can't have two last resorts this is quite problematic.
>
Those are two different things. dns-resolver discovery is to be used
to locate a DNS resolver/server in last resort when no other information
for finding this server is available.
LLMNR (at least to my understanding) is to be used
in last resort when the information had not been found in the DNS maps
(meaning you already have found a DNS server/resolver).
>Also, looking at the dns-discovery draft in isolation, it is far
>from clear to be how one can operationally control this behavior.
>The document has an implementation note about recommending that there
>be other mechanisms which take precedence over the well-known addresses,
>but the document does not require this nor does it specify that a particular
>mandatory override hence an operator would not be able to control this
>behavior.
>
I thought that the IETF was in the business of specifying protocols,
not how people should implement them nor how people should
use them.
The best we can do here is to providing guidelines like
"use it only under those circumstances if you don't want to get hurt"
- Alain.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
