[dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-option-02.txt>

Stuart Cheshire <cheshire@apple.com> Mon, 27 August 2001 21:10 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 RAA00601; Mon, 27 Aug 2001 17:10:07 -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 RAA05004; Mon, 27 Aug 2001 17:07:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04981 for <dhcwg@ns.ietf.org>; Mon, 27 Aug 2001 17:07:23 -0400 (EDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00440 for <dhcwg@ietf.org>; Mon, 27 Aug 2001 17:06:02 -0400 (EDT)
Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id OAA18859 for <dhcwg@ietf.org>; Mon, 27 Aug 2001 14:07:21 -0700 (PDT)
Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <T55a0c1450c118164e14ec@apple.com>; Mon, 27 Aug 2001 14:07:20 -0700
Received: from [206.111.147.149] (vpn-gh-1056.apple.com [17.254.140.31]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id f7RL7Kw03215; Mon, 27 Aug 2001 14:07:20 -0700 (PDT)
Message-Id: <200108272107.f7RL7Kw03215@scv2.apple.com>
Date: Mon, 27 Aug 2001 14:07:19 -0700
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire <cheshire@apple.com>
To: "Mark Stapp" <mjs@cisco.com>, "DHCP discussion list" <dhcwg@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-option-02.txt>
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

>the [FQDN] option has already been widely deployed

This I think is the real issue.

The purpose of WG discussion is to discuss protocol design, not to 
rubber-stamp an existing implementation, warts and all.

An Informational RFC is the right place to document an existing 
implementation, warts and all.

Mark, don't misunderstand this. I don't have any objection to you 
shipping products. I do object to a Standards-Track RFC published 
after-the-fact to give the impression that the design of the previously 
mentioned shipping products was the result of IETF Working Group 
Consensus.

If you want this to be a Working Group publication, you have to be able 
to update your deployed products to comply with the eventual Working 
Group Consensus. If you can't update your deployed products to comply, 
then this whole process is a waste of time. Just publish it as 
Informational.

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org



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