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

From: "David W. Hankins" <[email-masked]>
Date: Tue, 24 Apr 2007 16:48:06 -0700

http://www.ietf.org/internet-drafts/draft-dhankins-dhcp-option-guidelines-00.txt

At IETF 67 (San Diego), I gave a presentation on an informative
document I called 'Atomic DHCP'.  This was, more or less, an
examination, and definition of terms of a DHCP software
implementation written by Ted Lemon ("ISC DHCP").  I mostly
intended to ultimately provide input for a document written by
someone far more clever than I that might explore the conclusions
of "how to write an adoptable option" more fully.

What I heard at that IETF was that the reasons we have for certain
advice to DHCP option draft writers is less important than the things
we might wish to tell them, and at least a couple of people thought
it might be a good idea for me to take a stab at such a document.

So as discussed, I've pared down (possibly by not enough, I see now
at least two paragraphs that should have gone) and moved the 'Atomic
DHCP' explanation to an appendix, and brought the "lessons learned"
from the old document into the forefront and completed them.

I'd still like to see other appendices for other implementations,
or if other implementations are willing to say that they understand
the definition to be sufficiently similar to their own, we could
generalize the language and make it non-ISC specific ("At least two
implementations solved this by...").

At this point, the document is essentially complete so far as I
know, which means that any good advice to draft writers you can
think of for any section of the document would be great feedback.

-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Stig Venaas <[email-masked]>
Date: Wed, 25 Apr 2007 11:29:25 +0200

David W. Hankins wrote:
[...]
> think of for any section of the document would be great feedback.

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?

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.

Stig

> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 25 Apr 2007 12:16:32 -0700

> should in general be requested by the client and only returned by

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

> 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.