Re: [dhcwg] Pre-determining DUID

Ted Lemon <Ted.Lemon@nominum.com> Sat, 31 October 2009 05:17 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08B223A6978 for <dhcwg@core3.amsl.com>; Fri, 30 Oct 2009 22:17:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CsflYgUBFHB for <dhcwg@core3.amsl.com>; Fri, 30 Oct 2009 22:17:04 -0700 (PDT)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 48AB23A6405 for <dhcwg@ietf.org>; Fri, 30 Oct 2009 22:17:03 -0700 (PDT)
Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSuvIX5wvDpriznm5qeu6z+CR4RWCEFTo@postini.com; Fri, 30 Oct 2009 22:17:21 PDT
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 342121B8405; Fri, 30 Oct 2009 22:17:19 -0700 (PDT)
Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 30 Oct 2009 22:17:19 -0700
MIME-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <fab4e42a0910301926h2ab62d9ct963971d81fd7734d@mail.gmail.com>
Date: Fri, 30 Oct 2009 22:17:16 -0700
Content-Transfer-Encoding: quoted-printable
Message-ID: <77F7BDD3-3BF5-4DAC-9472-E6458B7578D2@nominum.com>
References: <fab4e42a0910091810j71fcabd8h12d992be6d28d320@mail.gmail.com> <FFE5030C-7341-471F-9731-EC069F857A01@nominum.com> <20091011002522.GA26560@angus.ind.WPI.EDU> <02B85D20-CA25-4AFB-BC8B-72095A4485B1@nominum.com> <fab4e42a0910301926h2ab62d9ct963971d81fd7734d@mail.gmail.com>
To: Jarrod Johnson <jarrod.b.johnson@gmail.com>
X-Mailer: Apple Mail (2.1077)
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Pre-determining DUID
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 31 Oct 2009 05:17:08 -0000

On Oct 30, 2009, at 7:26 PM, Jarrod Johnson wrote:
> I've outlined the only ways I could see that
> happening (either changing existing DHCP clients or allowing static
> declarations to key off of chaddr), but if you can think of other ways
> to be able to make this guarantee, I'm receptive.

Sure, go ahead and write Jarrod's Host Configuration Protocol.   That's what it would be.   The change you propose breaks interoperability, plain and simple.   So it's not going to appear in a standard from the IETF unless you can convince a whole lot of people that it's time to chuck out the baby and the bathwater.

The irony here is that you're complaining to *us* that vendors don't do the right thing.  I'm guessing you never complained to them, and you never asked them to do anything differently, and they never lost a sale because they aren't doing what you need them to do, and they never will.   And by the way, they're not going to implement JHCPv6 either, for exactly the same reason.

You're paying their salaries.   You aren't paying mine.   So I'd really encourage you to stop complaining here, and start complaining there.   You'd be surprised what a vendor will do when you ask them nicely to fix something and point to the line in the protocol spec that shows that their code is broken.