[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: sra+dnsop@hactrn.net (Rob Austein)
Cc: dnsop@cafax.se
From: Bill Manning <bmanning@ISI.EDU>
Date: Sat, 2 Aug 2003 17:13:12 -0700 (PDT)
In-Reply-To: <20030802221126.25E3C18E3@thrintun.hactrn.net> from Rob Austein at "Aug 2, 3 06:11:26 pm"
Sender: owner-dnsop@cafax.se
Subject: Re: Policy of IPv6 DNS Discovery

% > Separately, use of in-band dynamic discovery via multicast also allows
% > SRV-based discovery mechanisms to bootstrap further. Those systems also
% > operate outside of or run in parallel with DHCP.
% 
% No, sorry, I forgot about yours, and you're correct that it doesn't
% quite fit into any of the pigeon holes in my previous message.
% 
% If I understand it correctly, the simple version of what you propose
% (just using multicast to find recursive name servers, nothing else)
% substitutes one multicast-based discovery protocol for another
% multicast-based discovery protocol.  Since it's quite possible to
% co-locate a DHCP-lite "server" inside the same "process" (or whatever
% fate sharing unit a server host uses) as the recursive name server,
% the fate sharing comparision comes out as a wash when one looks at it
% closely.  So one's left arguing about relatively trivial engineering
% details like packet formats and port numbers.
% 
% The SRV based stuff is a different ball of wax: in that one, you're
% reinventing SLP instead of reinventing DHCP :).  While one could
% certainly have a fun discussion along those lines, the ZEROCONF and
% DNSEXT WGs have already spent a lot of time down the LLMNR rabbit
% hole, and I'm reluctant to follow them down there.

	See the TBDS work that predates LLMNR (and is referenced by it)
	There are some interesting tweeks that should be done to the 
	protocol (a replacement for QUERY comes to mind...)

	when the early work was done, DHCP did not have all the hooks
	and SLP was too "heavy".   

% In any case, either version of what you're talking about still looks
% to me like a proposal for new protocol work.  We're still trying to
% determine whether -any- new protocol work is needed, so this, like the
% RA-based and ND-based proposals, isn't really in scope at the moment.

	Sorry about bringing up packing plant rejects... :)

% #----------------------------------------------------------------------
% # To unsubscribe, send a message to <dnsop-request@cafax.se>.
% 


-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.

Home | Date list | Subject list