Re: [dhcwg] draft-dhankins-dhcp-option-guidelines-00

"David W. Hankins" <David_Hankins@isc.org> Wed, 25 April 2007 19:16 UTC

Return-path: <dhcwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgmyu-0004fv-Jx; Wed, 25 Apr 2007 15:16:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgmyt-0004fo-SV for dhcwg@ietf.org; Wed, 25 Apr 2007 15:16:47 -0400
Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgmyt-0004mR-GE for dhcwg@ietf.org; Wed, 25 Apr 2007 15:16:47 -0400
Received: by goliath.isc.org (Postfix, from userid 10200) id 80F227D2D; Wed, 25 Apr 2007 12:16:32 -0700 (PDT)
Date: Wed, 25 Apr 2007 12:16:32 -0700
From: "David W. Hankins" <David_Hankins@isc.org>
To: dhcwg@ietf.org
Subject: Re: [dhcwg] draft-dhankins-dhcp-option-guidelines-00
Message-ID: <20070425191632.GC30775@isc.org>
References: <20070424234806.GM8898@isc.org> <462F1F75.7040104@uninett.no>
Mime-Version: 1.0
In-Reply-To: <462F1F75.7040104@uninett.no>
User-Agent: Mutt/1.5.9i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
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>
Content-Type: multipart/mixed; boundary="===============1970787504=="
Errors-To: dhcwg-bounces@ietf.org

On Wed, Apr 25, 2007 at 11:29:25AM +0200, Stig Venaas wrote:
> Thanks for writing this, I think it is a very useful document. Some
> further guidelines should perhaps be added. One might be to discuss
> why option size is a big issue and suggest that people make options
> consume a minimal amount of space (e.g. not put XML into dhc, but
> rather a URL to a document...). Perhaps also suggest that new options
> should in general be requested by the client and only returned by
> server upon request?

Excellent points, I'll write something up on these two.

> I think we should put all the general considerations for designing
> new options into this document so that people specifying new options
> do it right. The syntax is not the only consideration.

I agree (syntax is just what my universe revolves around).  I'd
love more ideas to increase the laundry list.


There has also recently been lively exchange on ietf@, and one
thing that came up was about guidelines for when using DHCP at
all was a good or bad idea.

I suspect some abstract language to those ends should be included
as well, so I've added that to my list.


And thanks for the (prompt!) feedback, Stig.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg