Subject: RE: [dhcwg] Proposal for experimental DHCP option

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 1 Nov 2006 13:39:59 -0500

I do think that counted fields are a better way to go than null
terminated. This matches what we do with the user-class/vendor class.

Option-code | Length | Length-1 | data | Length-2 | data ...

- Bernie 

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Wednesday, November 01, 2006 10:06 AM
To: Giuseppe Patern? (Gippa)
Cc: [email-masked]
Subject: Re: [dhcwg] Proposal for experimental DHCP option

On Sun, Oct 29, 2006 at 12:03:27PM +0100, Giuseppe Patern? (Gippa)
wrote:
> I am totally wrong on my draft: it was option 96 ... I proposed to
> reuse the same of the LDAP draft, but that's a IANA final decision.
> They wouldn't allow me a DHCP option code unless this working group
> approves the draft as experimental. My apologies for the miswriting.
> Also it is interesting the fact of using null to separate different
> URLs, I didn't thought about that. What do the ML think?

We currently don't have any 'dhcp formats' which are represented by
null terminated values that could then be formed into an array.

I am also, by all accounts, a lazy bastard, so I would prefer not to
have to write any code to implement any such devices without very good
reasons.

So it would be my preference to separate multiple URLs with spaces,
and to therefore require the use of URL presentation formatting's
%-escapes if spaces were required within the URLs.

This may not be the most aesthetic, but I think it is the most
reverse compatible.

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

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 01 Nov 2006 11:51:13 -0700

> Option-code | Length | Length-1 | data | Length-2 | data ...

Er, yes, I agree also.   I noticed just as my previous message went out 
that what I had said was slightly clueless in a number of ways; in 
particular, the user class option is a much better example.   :'}

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 1 Nov 2006 21:22:01 +0000

> particular, the user class option is a much better example.   :'}

In my opinion, based upon what I think I know about the user-class
option's (lack of) adoption in production software, adopting a
format similar to the user class option will present the author's
option with a boundary to adoption.

So, I don't recommend that, but I also wouldn't stop the author
if that's his choice.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 01 Nov 2006 14:38:08 -0700

> So, I don't recommend that, but I also wouldn't stop the author
I don't know of any software that *doesn't* implement it.   Do you?   I 
thought you'd got it working in the ISC server.   Certainly Nominum's 
server implements it.

Using spaces (i.e. in-band delimiters) is a kludge, which requires 
additional software work as well; might as well do it the right way.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 1 Nov 2006 23:46:18 +0000

On Wed, Nov 01, 2006 at 02:38:08PM -0700, Ted Lemon wrote:
> I don't know of any software that *doesn't* implement it.

I believe I used the term 'adopt', which is only slightly different
from 'implement' although loosely coupled sometimes.  It would
certainly be true that a lack of implementation presents a significant
barrier to adoption, but not vice verse.

However, it is also my opinion that this format represents
some significant implementation barriers, that aren't quite
so bad as the adoption barriers.  This is why I placed emphasis
upon 'production software'.

> Do you? 

I have been made aware of precisely one dhcp client that both
implements user-class, and has adopted it for use in a production
setting.

I have encountered no others, client or server (but I would have
no reason to, due to the lack of adoption I perceive...it would be
very unusual indeed to hear something from nobody).

> I 

ISC (mis)implements the user-class option as an NVT-ASCII text
string.  This is how you left it, I have made no changes.

If the author values easy adoption, I advise against this path you
suggest.  This is because it is my opinion that choosing a path
that has what I believe to be significant and nontrivial adoption
barriers is not "the right way."  This is a matter of opinion and
both you and the author are welcome to your own.

That is all.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 01 Nov 2006 19:08:36 -0700

If you will forgive me for paraphrasing, it sounds like you're saying 
that only one DHCP client has adopted the user-class option, and that 
there are significant barriers to adoption imposed by this option.   And 
so despite the fact that it's been the general consensus of the working 
group for a long time that options with multiple text strings be 
represented as a series of length/buffer hunks, you believe that this 
general consensus is incorrect, and that in this particular case it 
would be better to separate the hunks of text with spaces.

I can only assume that your reason for thinking that separating hunks of 
text with spaces is that then you can just pass the option up to the 
application layer as a single hunk of text, rather than as an array of 
hunks of text.   Maybe I'm mistaken here, but I don't see any other 
reason for you to take this position.

But if that is in fact your position, then you should consider that in 
fact the example of the domain suffix search list option contradicts 
your position.   This is widely implemented,  because Microsoft 
implements it, and Microsoft has a huge installed base.   And they don't 
seem to mind that this option requires them to pass arrays of hunks of 
text up to the application layer.   And of course there's the 
vendor-specific vendor-encapsulated suboption option, which does 
something similar, and which presumably is widely implemented by Cisco, 
or is going to be.

The only DHCP client that I know of for which a space-separated string 
of text hunks is equivalent to an array of text hunks is the ISC client, 
because it uses shell scripts to manage options.   I felt that this was 
a good design decision at the time that I did it, but we shouldn't allow 
this design decision to dictate how we handle the low-level 
representation of new options.   I don't think it will be a substantial 
problem for you to represent arrays of text hunks in the shell script - 
I can think of several simple ways to do it.

So I think that this idea that there would be an obstacle to adoption of 
an option encoded as length+text hunks is incorrect.   I think that if 
there is any demand for the option, implementation won't be a big 
problem.   And if there is no demand, then it's a moot point.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 2 Nov 2006 03:04:46 +0000

I've expressed my opinion, and I don't see any value in repeating
it to you.

If you need clarifications of it, the only thing I can offer is
the DHCWG mailing list archive, which I trust you can find.

---

From: Bud Millwood <[email-masked]>
Date: Thu, 2 Nov 2006 12:53:54 +0100

I have no problems implementing a dhcp option of any fixed type that has 
length-prefixed elements. Furthermore, I strongly prefer that multi-value 
string types as well as multi-value opaque octet sequences use this format.

- Bud