Re: [dhcwg] Incorporation of WG last call comments in draft-aboba-dhc-domsearch-06.txt

Ted Lemon <mellon@nominum.com> Wed, 26 September 2001 21:31 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29257; Wed, 26 Sep 2001 17:31:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16629; Wed, 26 Sep 2001 17:28:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16602 for <dhcwg@ns.ietf.org>; Wed, 26 Sep 2001 17:28:15 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29193 for <dhcwg@ietf.org>; Wed, 26 Sep 2001 17:27:58 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (205-140-116-229.ip.theriver.com [205.140.116.229]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f8QJaWv24730; Wed, 26 Sep 2001 12:36:36 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f8QJchZ07668; Wed, 26 Sep 2001 12:38:43 -0700 (MST)
Message-Id: <200109261938.f8QJchZ07668@grosse.bisbee.fugue.com>
To: Thomas Narten <narten@raleigh.ibm.com>
cc: Bernard Aboba <aboba@internaut.com>, dhcwg@ietf.org
Subject: Re: [dhcwg] Incorporation of WG last call comments in draft-aboba-dhc-domsearch-06.txt
In-Reply-To: Message from Thomas Narten <narten@raleigh.ibm.com> of "Wed, 26 Sep 2001 07:02:07 -0400." <200109261102.f8QB27P04976@hygro.adsl.duke.edu>
Date: Wed, 26 Sep 2001 12:38:43 -0700
From: Ted Lemon <mellon@nominum.com>
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

> > [7]  Lemon, T., "Encoding Long DHCP Options", Internet draft (work in
> >      progress), draft-ietf-dhc-concat-01.txt, July 2001.

We're in last call on the concat option as well, and I have a new
version with some changes suggested by Stuart Cheshire.   I think it's
ready to go.   So I'll publish it now.

> Is the option allowed to be included in client messages? I would
> assume so. Indeed, isn't it the case that clients can include any
> option if to signal a desire to the server to get such an option
> returned? If so, I guess this isn't really an issue.

It doesn't make sense to include this in a client message, but the
draft isn't saying a server should drop a message that contains this
option, so I think this is a non-issue.

> s/is replaced/can be replaced/

The wording only applies if you are doing compression, so the definite
form of the verb is correct, and the indefinite form would be less
correct, IMHO.

			       _MelloN_

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