Re: [dhcwg] Question about 3315id-for-v4

Ted Lemon <mellon@fugue.com> Wed, 21 April 2004 01:19 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13286 for <dhcwg-archive@odin.ietf.org>; Tue, 20 Apr 2004 21:19:55 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6EP-0004N0-0Y for dhcwg-archive@odin.ietf.org; Tue, 20 Apr 2004 21:08:53 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L18qEk016796 for dhcwg-archive@odin.ietf.org; Tue, 20 Apr 2004 21:08:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6A7-0002Wm-J1 for dhcwg-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 21:04:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12639 for <dhcwg-web-archive@ietf.org>; Tue, 20 Apr 2004 21:04:25 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG6A5-00051W-4w for dhcwg-web-archive@ietf.org; Tue, 20 Apr 2004 21:04:25 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG69A-0004ws-00 for dhcwg-web-archive@ietf.org; Tue, 20 Apr 2004 21:03:28 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG68a-0004sQ-00 for dhcwg-web-archive@ietf.org; Tue, 20 Apr 2004 21:02:52 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5xB-0004Fy-AO; Tue, 20 Apr 2004 20:51:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5ju-0006lL-QV for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 20:37:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11227 for <dhcwg@ietf.org>; Tue, 20 Apr 2004 20:37:20 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG5js-0002Yr-Ih for dhcwg@ietf.org; Tue, 20 Apr 2004 20:37:20 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG5iw-0002Uc-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 20:36:22 -0400
Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BG5i6-0002QU-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 20:35:30 -0400
Received: from [69.136.112.90] (pcp08419874pcs.orovly01.az.comcast.net [69.136.112.90]) by toccata.fugue.com (Postfix) with ESMTP id DDF6F1B238D; Tue, 20 Apr 2004 19:26:51 -0500 (CDT)
In-Reply-To: <4.3.2.7.2.20040420115100.01f91588@flask.cisco.com>
References: <4.3.2.7.2.20040420115100.01f91588@flask.cisco.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <C9E790A8-932B-11D8-AE44-000A95D9C74C@fugue.com>
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org
From: Ted Lemon <mellon@fugue.com>
Subject: Re: [dhcwg] Question about 3315id-for-v4
Date: Tue, 20 Apr 2004 17:35:28 -0700
To: Ralph Droms <rdroms@cisco.com>
X-Mailer: Apple Mail (2.613)
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

On Apr 20, 2004, at 8:58 AM, Ralph Droms wrote:
> Is there some other way in which the use of the DHCID RR can be
> defined to avoid requiring the parsing of any client identification 
> (either
> DHCpv4 or DHCPv6)?

No.   During the last call both Bernie and Barr expressed a wish that 
we could do this, and we discussed and rejected a method for doing 
this.   The problem is that the only way to make it so the server 
doesn't have to parse the identifier is to add an additional identifier 
option, and if we do that, clients supporting the new identifier style 
will not interoperate with servers that do not in some cases.

The only objection I can think of to the server parsing the client 
identifier option is that we have historically said the client 
identifier is opaque.   However, there is a good reason to break with 
this tradition, and I don't see how doing so would create an 
interoperability problem.   So if we try to keep this tradition, we 
break interoperability with old servers.   If we break this tradition, 
we do not.   So I think we have to use the IAID+DUID form of the client 
identifier option, and not add a separate IAID option.


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