RE: [dhcwg] Re: Last Call: DHCP Domain Search Option to Proposed Standard

"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Thu, 25 October 2001 05:17 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 BAA25416 for <dhcwg-archive@odin.ietf.org>; Thu, 25 Oct 2001 01:17:13 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA19877 for dhcwg-archive@odin.ietf.org; Thu, 25 Oct 2001 01:17:15 -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 BAA17378; Thu, 25 Oct 2001 01:08:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17321 for <dhcwg@optimus.ietf.org>; Thu, 25 Oct 2001 01:08:57 -0400 (EDT)
Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24791 for <dhcwg@ietf.org>; Thu, 25 Oct 2001 01:08:55 -0400 (EDT)
Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9P58T010960 for <dhcwg@ietf.org>; Thu, 25 Oct 2001 00:08:29 -0500 (CDT)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9P58Tr27692 for <dhcwg@ietf.org>; Thu, 25 Oct 2001 00:08:29 -0500 (CDT)
Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu Oct 25 00:08:29 2001 -0500
Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CQ1JCP9>; Thu, 25 Oct 2001 00:08:29 -0500
Message-ID: <66F66129A77AD411B76200508B65AC697B37E6@eambunt705.ena-east.ericsson.se>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: "'Thomas Narten'" <narten@us.ibm.com>, Bernard Aboba <aboba@internaut.com>
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] Re: Last Call: DHCP Domain Search Option to Proposed Standard
Date: Thu, 25 Oct 2001 00:08:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15D13.14D01EB0"
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

Thomas ... I believe the conclusion was that these references to the concat draft are necessary. They are necessary for any options that could possibly ever need to make use of the concat technique. The domain search option is one of the options that could be long enough to require concat techniques.

We must require that both the client and server supporting this option MUST also support the concat option. If this isn't the case, then if the server implements concat but the client doesn't, the client may easily improperly process the returned option and this would cause significant problems since the client would not know how to handle multiple occurrences of the option and might use any one of the occurrences (rather than concatenating) or drop the packet as being malformed (since the original DHCP specification said an option may occur only once if I recall correctly).

If a new option is defined that has a fixed length (such as carrying a single IP address), there is no need to require that the client and server also implement concat to support that option.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, October 24, 2001 7:43 PM
To: Bernard Aboba
Cc: dhcwg@ietf.org
Subject: [dhcwg] Re: Last Call: DHCP Domain Search Option to Proposed
Standard


IETF Last Call has ended on this document, and I recall that Keith
Moore had some comments. Not sure if any other issues were raised.

Note that as the document is currently written, I believe it has a
normative dependency on the draft-ietf-dhc-concat-01.txt ID. There was
some discussion about whether that was necessary or not, but I'm not
sure what the final resolution was. In any case, I think wording
changes would be need to make the reference non-normative. If the
intention is that the reference be normative, we need the other ID to
move forward as well.

Are there any other issues that need to be resolved?

Once the remaining issues are resolved and a new ID is out, I can
bring the document before the IESG for consideration.

Thomas

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