On Thu, Aug 21, 2008 at 11:02:31PM +0200, Bud Millwood wrote:
> "Providing multiple different formats of the same configuration information,
> such as an IP address, name, or URL, which are all intended to provide the
> same location information, is undesirable."
>
> -- The wording is a little confusing. Maybe something like: It is undesirable
> to provide multiple formats, such as IP address, name or URL for the same
> configuration information.
That's an excellent point, I went a slightly different way with it;
<t>Options are said to be aliases of each other if they provide input to
the same configuration parameter. A commonly proposed example is to
configure the location of some new service ("my foo server") using a
binary IP address, a domain name field, and a URL. This kind of
aliasing is undesirable, and is best avoided.</t>
I'm mostly trying to keep the conclusion at the end of the paragraph,
as it reinforces the ordering of the arguments and conclusion in the
following section.
> "So it is still best advice to design options to a ~500 byte payload
> limitation."
>
> -- Where did the 500 come from?
That's a good question. For other readers, in context this is in
regards to DHCPv6, which ostensibly happily handles 64KB packets and
fragmentation thanks to link-local addresses.
I think I planned to write down a vague number and fill in a real one
later after some discussion. At the same time, I don't want this
phrase to become the new thing people will quote to prove DHCPv6
options are "limited to 500 bytes". I'm just trying to say 'don't
waste space gratuitously', which actually sounds pointlessly obvious
now that I say it.
Maybe I should just remove this last sentence on that paragraph?
> "In both DHCP protocols, there exists as part of the protocol definition an
> option whose purpose is twofold - to inform the server..."
>
> -- param-req-list option is introduced in the next paragraph without having
> been defined, so maybe you could define it in this paragraph like "In both
> DHCP protocols, there exists as part of the protocol definition an option,
> the parameter request list option, whose purpose is twofold:"
I think like in your first example, this starts getting too clause-y.
So I went a different way with this again;
<t>The <xref target="RFC2132">DHCPv4 Parameter Request List</xref>, and
the <xref target="RFC3315">DHCPv6 Option Request Option
(OPTION_ORO)</xref>, are both optoins that serve two purposes - to
inform the server what option(s) the client supports and is willing to
digest, and in what order of priority the client places those option
contents (in the event that they will not fit in the packet, later
options are to be dropped).</t>
I'm also thinking of adding a paragraph to the end of this section
that says;
<t>Under only the most dire of circumstances should a new option
definition require special ordering of options either in the relevant
request option, or in the order of packets returned on the server's
reply. Although the request option does display a preferred priority,
which implies an order, a server may shuffle options around in a DHCPv4
packet in order to make them fit, and server software may sort DHCPv6
options into strange orders. There is not one universal approach.</t>
--
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/
--
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
Attachment:
pgpRgOPGV9yxH.pgp
Description: PGP signature
_______________________________________________ dhcwg mailing list dhcwg at ietf.org https://www.ietf.org/mailman/listinfo/dhcwg