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
- [dhcwg] draft-dhankins-dhcp-option-guidelines-00 David W. Hankins
- Re: [dhcwg] draft-dhankins-dhcp-option-guidelines… Stig Venaas
- Re: [dhcwg] draft-dhankins-dhcp-option-guidelines… David W. Hankins