Re: New I-Ds on ftp.bucknell.edu

["Michael J. Lewis" <[e-mail]>]

Some initial comments/questions on draft-ietf-dhc-dhcp-dns-00.txt    - 
DHCP-DNS interaction (Yakov Rekhter)

1.  What is the rationale for allowing both the client and server to
	initiate updates to the A RR record?  Is it simply for the 
	client to get confirmation of the change?

2.  If DNS updates were restricted to the server realm, then it seems
	that currently existing techniques could be used to initiate
	the DNS change request rather than the suggested option.  The
	flag introducted in the new option would obviously not be 
	needed; the domain name should come from the server anyway since
	the client should not know which domain it is in.  The host 
	name component of the FQDN might then be provided by the 
	existing host name option (12).  

	This effectively makes a host name (from client) and DNS name 
	(from server) combination the trigger to cause a dynamic DNS
	update.  One would lose the ability provided by a separate 
	option of avoiding a DNS update even though both host and domain
	name were set although in our environment, I can't foresee any
	time when we would want to prevent a DNS update.

3.  Even if the suggested option is maintained, I'd still favor 
	having the servers submit all updates as this simplifies the
	protocol specifications immensely by eliminating the need for
	the flag within the option and answering the first discussion
	question as to whether a server can override the client.

4.  I'm unclear as to why one would include lease information within
	DNS.  It that information is present, it seems that the DNS
	entry could be expired without requiring a packet from the 
	server.  However, including this information raises a number
	of questions regarind the handling of renew/rebind requests.
	Would a server (following an ACK) send an update request to DNS?
	Since the DNS entry should already be present, will DNS ignore 
	the request as a duplicate (leaving the current expiration time)
	or will it update the internal TTL time to the new lease?

	It seems a simpler approach would be to require a packet be
	sent to DNS whenever a lease expires or is released by the
	client.  It would be the server's responsibility to send the
	packet.  I guess a server could send notification if a lease
	is deleted at the server but this is such a vague area anyway
	(the client isn't notified so why should DNS be?) I'd just 
 	as soon leave it out of the document so as not to encourage 
	it use.