[dhcwg] Re: Contents of dhcwg digest...
"Dhaka . Razzak" <firstname.lastname@example.org> Sat, 28 August 2004 03:41 UTC
Received: from megatron.ietf.org (megatron.ietf.org [220.127.116.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03228; Fri, 27 Aug 2004 23:41:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0twy-0006Vx-Ky; Fri, 27 Aug 2004 23:32:20 -0400
Received: from odin.ietf.org ([18.104.22.168] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0tuE-0005zh-VJ for email@example.com; Fri, 27 Aug 2004 23:29:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [22.214.171.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02630 for <firstname.lastname@example.org>; Fri, 27 Aug 2004 23:29:26 -0400 (EDT)
Received: from smtp1.agni.com ([126.96.36.199] helo=mx.agni.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0tvP-0003U6-7F for email@example.com; Fri, 27 Aug 2004 23:30:48 -0400
Received: from inspbg.com ([188.8.131.52] helo=server.inspbg) by mx.agni.com with esmtp (Exim 4.12) id 1C0tt4-0005SY-00 for firstname.lastname@example.org; Sat, 28 Aug 2004 09:28:24 +0600
Received: by SERVER with Internet Mail Service (5.5.2448.0) id <RDFA3ZFD>; Sat, 28 Aug 2004 09:28:26 +0600
From: "Dhaka . Razzak" <email@example.com>
To: "'firstname.lastname@example.org'" <email@example.com>
Date: Sat, 28 Aug 2004 09:28:24 +0600
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
X-MailScanner-Information: Scanned by agni's email virus scanner at smtp1
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 6, BAYES_00 -4.90)
X-Spam-Score: 0.0 (/)
Subject: [dhcwg] Re: Contents of dhcwg digest...
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:email@example.com?subject=subscribe>
-----Original Message----- From: firstname.lastname@example.org [SMTP:email@example.com] Sent: Friday, August 27, 2004 10:12 PM To: firstname.lastname@example.org Subject: dhcwg Digest, Vol 4, Issue 38 Send dhcwg mailing list submissions to email@example.com 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 firstname.lastname@example.org You can reach the person managing the list at email@example.com 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 <firstname.lastname@example.org> Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 To: Stig Venaas <Stig.Venaas@uninett.no>, email@example.com Message-ID: <firstname.lastname@example.org> 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 <email@example.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: firstname.lastname@example.org Message-ID: <email@example.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 <firstname.lastname@example.org> Subject: [dhcwg] dhcp6 verndor class option To: email@example.com, firstname.lastname@example.org Cc: email@example.com, firstname.lastname@example.org 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 email@example.com https://www1.ietf.org/mailman/listinfo/dhcwg End of dhcwg Digest, Vol 4, Issue 38 ************************************ _______________________________________________ dhcwg mailing list firstname.lastname@example.org https://www1.ietf.org/mailman/listinfo/dhcwg