[dhcwg] Re: Contents of dhcwg digest...


	-----Original Message-----
	From:	dhcwg-request@ietf.org [SMTP:dhcwg-request@ietf.org]
	Sent:	Friday, August 27, 2004 10:12 PM
	To:	dhcwg@ietf.org
	Subject:	dhcwg Digest, Vol 4, Issue 38

	Send dhcwg mailing list submissions to
		dhcwg@ietf.org

	To subscribe or unsubscribe via the World Wide Web, visit
		https://www1.ietf.org/mailman/listinfo/dhcwg
	or, via email, send a message with subject or body 'help' to
		dhcwg-request@ietf.org

	You can reach the person managing the list at
		dhcwg-owner@ietf.org

	When replying, please edit your Subject line so it is more specific
	than "Re: Contents of dhcwg digest..."


	Today's Topics:

	   1. Re: Attempt at text for draft-ietf-dhc-lifetime-02 (Joe
Quanaim)
	   2. Re: behavior on lifetime expiration (Re: comments
	      ondraft-ietf-dhc-lifetime-01.txt) (Joe Quanaim)
	   3. dhcp6 verndor class option (Keshava)


----------------------------------------------------------------------

	Message: 1
	Date: Fri, 27 Aug 2004 08:54:09 -0400
	From: Joe Quanaim <jdq@lucent.com>
	Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02
	To: Stig Venaas <Stig.Venaas@uninett.no>, dhcwg@ietf.org
	Message-ID: <200408270854.10485.jdq@lucent.com>
	Content-Type: text/plain;  charset="iso-8859-1"


	Stig Venaas wrote:
	> |  A client MUST also use the default refresh time IRT_DEFAULT if
it
	> |  receives the option with value less than 600.
	>
	> Do you agree with a minimum like this? It should make it harder to
	> do bad things, and I don't see a use for <10 minutes. If <600,
	> would you rather use 600 than IRT_DEFAULT?

	I think a minimum is a good idea, but it probably should not be
reset to 24 
	hours.  That's probably not what an admin intended by setting the
value that 
	low.

	Also, are 0 or 0xffffffff a special case like elsewhere in dhcpv6?
I am not 
	sure it's necessary; I am just bringing up the point.

	Thanks,
	Joe Quanaim.


	------------------------------

	Message: 2
	Date: Fri, 27 Aug 2004 09:29:46 -0400
	From: Joe Quanaim <jdq@lucent.com>
	Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments
		ondraft-ietf-dhc-lifetime-01.txt)
	To: Robert Elz <kre@munnari.OZ.AU>, Stig Venaas
		<Stig.Venaas@uninett.no>
	Cc: dhcwg@ietf.org
	Message-ID: <200408270928.58762.jdq@lucent.com>
	Content-Type: text/plain;  charset="iso-8859-1"

	Robert Elz wrote:
	>     Date:        Fri, 27 Aug 2004 08:23:21 +0200
	>     From:        Stig Venaas <Stig.Venaas@uninett.no>
	>     Message-ID:  <20040827062321.GA15052@sverresborg.uninett.no>
	>
	>   | I'm not sure if the answer to these issues need to be
described in
	>   | the draft since it's a more generic issue. OTOH this draft
might be
	>   | the most obvious place we have for now.
	>
	> Yes, it is a much bigger issue than just providing a mechanism for
	> specifying when a new info request should be attempted.
	>
	> But it is when we specify that that the problem becomes obvious,
and
	> we need to have a solution - until now (including in IPv4) we
mostly
	> just pretended that none of this ever happened, and once learned,
all
	> of this information was static forever (hence, DNS "servers" (back
end
	> resolvers really) go in /etc/resolv.conf - that gets updated when
the
	> info changes, but applications know nothing of that, and simply
keep on
	> using the old information forever).
	>
	> All this is something of a quagmire - but is something that needs
to be
	> addressed, and ought to be addressed along with this new option
(if not
	> necessarily in the same document).

	I agree that this is an issue, but I don't think it's something this
document 
	should address.  It's a larger part of the dhcp specification, and
the 
	example you gave could happen in stateful configuration as well.

	For the example involving dns and this option, I read the draft as
such: when 
	the option expires, don't dismiss the configured dns data.  Request
new 
	information.  When new information is received, replace the existing
data 
	with the newly obtained.  This prevents the client from being left
without 
	dns while making an attempt to be current.  Also, if a server
returns an 
	empty set of dns servers, that is what the client should use.  It
doesn't 
	make much sense, but misconfigured dhcp servers aren't something a
client 
	should be programmed to handle.

	Generalizing this issue is not simple.  How does a dhcp client
update the ntp 
	configuration?  And why does it?  The ntp configuration could be
pointing to 
	a server reachable from multiple networks.  This seems like local
policy.

	Joe Quanaim.


	------------------------------

	Message: 3
	Date: Fri, 27 Aug 2004 19:39:52 +0530
	From: Keshava <keshavaak@huawei.com>
	Subject: [dhcwg] dhcp6 verndor class option
	To: dhcwg@ietf.org, ipv6@ietf.org
	Cc: keshavaak@huawei.com, maoshx@huawei.com
	Message-ID: <001f01c48c3f$86a44f80$1604120a@keshavaak>
	Content-Type: text/plain; charset="iso-8859-1"

	Hi,
	    Can you please clarify  in he RFC 3315 (DHCP6) 

	   "Appearance of Options in Message Types" section mentions that
the dhcp6 relay should support 
	     vendor class option.
	  
	    But in the message processing in the "Section 22.16 Vendor Class
Option"  does not mention any 
	    thing about this for relay . It only mentions about how the
client should process this.

	     Can some one please clarify this  what should be done for dhcp6
relay ?


	regards,
	keshava
	-------------- next part --------------
	An HTML attachment was scrubbed...
	URL:
http://www1.ietf.org/pipermail/dhcwg/attachments/20040827/5cb1a8a8/attachmen
t.htm

	------------------------------

	_______________________________________________
	dhcwg mailing list
	dhcwg@ietf.org
	https://www1.ietf.org/mailman/listinfo/dhcwg


	End of dhcwg Digest, Vol 4, Issue 38
	************************************

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg