IETF Logo Mail Archive

Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02

Bud Millwood <budmillwood@gmail.com> Mon, 16 April 2012 08:53 UTC

Return-Path: <budmillwood@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B3021F8714 for <dhcwg@ietfa.amsl.com>; Mon, 16 Apr 2012 01:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgVObVSJ-Iah for <dhcwg@ietfa.amsl.com>; Mon, 16 Apr 2012 01:53:19 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1819521F8690 for <dhcwg@ietf.org>; Mon, 16 Apr 2012 01:53:18 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so3793338vbb.31 for <dhcwg@ietf.org>; Mon, 16 Apr 2012 01:53:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=H7SN17AKwoqhQo6p26bcThHHXe9s41HqxDJmEc1JCLY=; b=J/GTY6ROkgjCYMxSw8ZZKRxrMuo5ErA7BoZ8sr77P7+SSbF9fjQHGL1e0PX8kiIp4/ 2MStwnk7uogiKkS4bYhBKNDv4MeHzW24Aw6p8OkoN0l3QLyXVTyHDRWt9BustTbUvg3v uF9s7NCQwrlF6nCWF2CBNBs5xum8zQqxAO1xcI3RgrUOXQHPgA9r16WCjnRKJvn9uK8+ qnWWRtt/ByYuoyaOsgzwBPOqX4VDSqXUtivG1a0uCasJPP3N8uLkOD8A6gPj+kqcNAl4 LES1u5kwRMXF1Z+PqJHuMkCyBFKqe9ZoHN3dADoywKlvxIYDBIo3m/fORMDsuOKGV1XQ 3gZg==
MIME-Version: 1.0
Received: by 10.220.140.18 with SMTP id g18mr5615474vcu.37.1334566398491; Mon, 16 Apr 2012 01:53:18 -0700 (PDT)
Received: by 10.52.110.35 with HTTP; Mon, 16 Apr 2012 01:53:18 -0700 (PDT)
In-Reply-To: <64B00097-8ACB-4170-9303-8F863A47C2B5@nominum.com>
References: <64B00097-8ACB-4170-9303-8F863A47C2B5@nominum.com>
Date: Mon, 16 Apr 2012 10:53:18 +0200
Message-ID: <CAOpJ=k22-62DvQukZq=Qxx47Sf4EUOtEd+FdwHuj9KnMw4gR-w@mail.gmail.com>
From: Bud Millwood <budmillwood@gmail.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: DHC WG <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Apr 2012 08:53:20 -0000

Hi Ted:

We'll support this. My approach is going to be to make it optional,
but I'm leaning towards having it disabled by default in our software.

Is there any real-world analysis of how various devices will handle
this change? After all, it is explicitly breaking the existing DHCP
protocol.

- Bud

On Sat, Apr 14, 2012 at 2:54 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
> This document corrects a bug in RFC2131 that forbids the DHCP server from returning a DHCP client identifier.   The lack of a DHCP client identifier creates a problem in two cases: where the underlying transport has no link-layer address, and where two clients are running on the same host, supplying different client identifiers so as to present different network identities.   In both of these cases, insufficient information is returned from the DHCP server to clearly identify the client that is the intended recipient of the message.   The only way to fix this is to _require_ the DHCP server to return the client identifier if it receives it.   This is what the proposed document does.
>
> We checked for consensus in the meeting, and four people were in favor of advancing the draft; nobody was against.
>
> I think this is actually pretty important work—it's a lingering bug in the spec which I think will come back to bite us more and more as we start getting deeper into the dual-stack transition.   So if you haven't read the document, please do.
>
> If you support advancing it, please signify by replying to this message and saying that you support it. If you think it's a bad idea, please signify by replying to this message and explaining why.   If you have comments or changes to propose, please send them along, and also signify whether you are in favor of advancement with the change, without the change, or oppose advancement.
>
> We will determine consensus on April 27, based solely on responses on the mailing list, so please do respond.
>
> Thanks!
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

v2.23.0 | Report a Bug | By Email