[dhcwg] draft-dhankins-atomic-dhcp-00.txt

Background...

A long time ago, IETF 63 I think it was, Paris, we had somethign like
four drafts in front of the WG that day that had a "selective
encoding"...where the first byte of the option indicated wether the
rest was a domain name, a url, or a binary ip address, etc.

They all managed to do this selective encoding in subtly different
ways (and later revised to more simple encodings).  At the time, I
suggested that if this was really necessary, that they all get
together and make one consistent encoding so we implementors don't
have to do things over and over again from scratch, and I suggested
one such encoding (option encapsulation/"sub options").

Basically, my complaint was that these drafts presented themselves
substantial barrier to adoption, and I couldn't see a good reason
for that.

Ralph suggested I should write such a draft.

Well, the authors moved on without that work and reformatted their
options to be more easily adoptable.  A much more palatteable
solution.

So it seems there's no good reason for that anymore.

So instead, I wrote a bunch of text that describes how options are
processed in ISC DHCP.  There's some forward looking stuff in here
(and the XML has some even more forward looking stuff commented out
now), describing versions of the software that haven't been released
yet, and I omitted a bunch of the "atoms" that are used for internal
purposes (server-config options rather than protocol options).

One of the things that probably isn't represented sufficiently is
that we use the same option processing engine for both v4 and v6.
When I started writing the document, we didn't have a v6 work in
progress to speak of.

I put in a security section because I want to say some things about
that.  It's joking filler until a future revision.

It's a pretty rough draft at this point and I doubt I'll have time
to complete it until March or so, but I think it's ready for high
level feedback...overall direction, layout.

Basically by describing how things work I'm hoping folks can think
about "what implementors will have to do" to support an option they've
documented once it's assigned an RFC number.

Stig has asked the WG a couple of times if we need a BCP on designing
DHCP options.  I don't think I'm the right guy to write that, but if
we think there's enough overlap here, I can write down what you folks
tell me.  The "adoption considerations" I was trying to capture are
at least related to that work I think.

If other implementors want to shove me a pile of XML describing their
own implementations, or describing in vague terms how their other
implementations differ, I'd love to include that too (or reference
other documents for comparisons).

----- Forwarded message from Internet-Drafts@ietf.org -----

To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Date: Thu, 05 Oct 2006 10:50:01 -0400
Subject: I-D ACTION:draft-dhankins-atomic-dhcp-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: DHCP Option Processing, Explained
	Author(s)	: D. Hankins
	Filename	: draft-dhankins-atomic-dhcp-00.txt
	Pages		: 19
	Date		: 2006-10-5

   Most protocol developers ask themselves if a protocol will work, or
   work efficiently.  These are important questions, but another less
   frequently considered is wether the proposed protocol changes present
   themselves barriers to adoption by deployed software (more
   importantly, needlessly so).

   This document seeks to provide information on the challenges to DHCP
   Option software implementers, and in doing so to provide guidance to
   prospective DHCP Option authors to help them produce options that are
   easily adoptable.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-dhankins-atomic-dhcp-00.txt

----- End forwarded message -----

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email training@isc.org.
-- 
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