Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-option-guidelines-00.txt

From: [email-masked]
Date: Wed, 12 Sep 2007 12:15:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: Guidelines for Creating New DHCP Options
	Author(s)	: D. Hankins
	Filename	: draft-ietf-dhc-option-guidelines-00.txt
	Pages		: 16
	Date		: 2007-9-12
	
   This document seeks to provide guidance to prospective DHCP Option
   authors, to help them in producing option formats that are easily
   adoptable.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-dhc-option-guidelines-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-option-guidelines-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 12 Sep 2007 10:05:36 -0700

> 	Filename	: draft-ietf-dhc-option-guidelines-00.txt

While working on draft-ietf-dhc-pxelinux, I had a random thought.

One of the areas in which the guidelines draft already discusses the
problem (a bit) is DHCP packet sizes.  That's more for guiding what to
do with large payloads (use TFTP or HTTP or etc) so far.

Several drafts have an almost 'boilerplate' description of RFC3396
behaviour, including the RFC3396 behaviour in their examples.  We've
gone back and forth on this with authors a few times, where the
re-description of RFC3396 is incomplete or misleading.

It ocurrs to me that anything beneath the new option's payload is
"DHCP Protocol".  So the thought I've recently had is our common
practice of including the Code and Length bytes (or words in
DHCPv6's case) is maybe the real source of the problem.  It seems
simpler, on the surface, to document only what code has been
assigned (external to any ASCII art), specify any fixed lengths of the
payload, and then the specific payload contents.

This creates a rather sudden and jarring inconsistency in existing
option specifications, however.

Or alternatively we could strive to make a single boilerplate.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
-- 
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: "David W. Hankins" <[email-masked]>
Date: Thu, 27 Sep 2007 11:16:03 -0700

> payload, and then the specific payload contents.

Since there has been no comment, I gather this is probably universally
considered a 'bad idea' and so won't bother (re)writing up some text
on it in the guidelines draft.

Here's the current index on this draft;

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  When to Use DHCP . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  General Principles . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Reusing Other Options  . . . . . . . . . . . . . . . . . . . .  4
   5.  Conditional Formatting is Hard . . . . . . . . . . . . . . . .  7
   6.  Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  New Formats  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   8.  Option Size  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  Clients Request their Options  . . . . . . . . . . . . . . . .  9
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 10

Can anyone think of any other major headings we should cover in this
docuemnt?

If not, we might want to think about last calling this to see if there
are any detail problems...it's highly probable that my writing style
has leaked through to too great an extent and placed considerable
bias on the text, so I hope in particular that the WG will help me
identify and neutralize any such 'loaded text.'

Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/

---

From: Stig Venaas <[email-masked]>
Date: Fri, 28 Sep 2007 09:57:40 +0200

> on it in the guidelines draft.

Sorry David, this actually sounds like a good idea to me. Having other
documents trying to explain such things themselves just increases the
likelihood of them getting it wrong. The individual option designers
should have to specify as little as possible, IMO.
> are any detail problems...it's highly probable that my writing style

I'll try to think of other items, and I urge others to think about it as
well. I suppose it could help to look at past discussions and see what
people got wrong or what you've had to explain about DHCP behaviour.

By getting things right in this document we can hopefully save us lots
of work in the future by simply pointing option designers to this
document...

Stig

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