Hi, Ralph,
This background helps with my concerns (I just wanted IANA to get clued in
from SOME specification!).
Thanks,
Spencer
Spencer - It turns out this draft has a *very* long history. It is
intended
to document the use of some optinos that date back to a time when IANA
handed out options codes for DHCP options *before* the defining RFC was
published. The current process for assigning option codes is defined in
RFC
2939.
The intention, then, for this draft (to be an Informational RFC) is to
document the use of several DHCP options that have been in common use
without a defining RFC for many years.
We could address one of your issues by explicitly telling IANA not to
reassign these codes elsewhere, but I think that issue might have been
addressed in RFC 3679,
And, the option codes that are listed by IANA as "tentatively assigned"
are
in that state as part of the process for extending the DHCPoption code
space
in RFC 3924.
I hope that information answers your high-level questions.
I agree with your editorial commentthat the sentence you cite could be
more
clearly worded and I'll be happy to revise it.
- Ralph
On 1/14/06 1:40 AM, "Spencer Dawkins" <[EMAIL PROTECTED]> wrote:
I was selected as General Area Review Team reviewer for this
specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Summary: Huh?
If I understand the draft and underlying working group mailing list
traffic
correctly, this is being published as an Informational RFC to say that
PXE
(and, for good measure, Etherboot?) are using DHCP options that aren't
allocated by IANA. Some of the mailing list postings showed previous
versions of the draft with IANA considerations, but the current version
of
the draft says there are no IANA considerations.
So, the plan is to publish an Informational document that describes this
practice, but does not tell IANA not to allocate the hijacked option
codes
for some other use? Oh-kay... although
http://www.iana.org/assignments/bootp-dhcp-parameters shows the option
codes
as already tentatively allocated (one presumes this was based on version
01
of this draft).
If this is the plan, the document is close to OK for publication,
although I
expect the RFC Editor would expand acronyms, etc. I thought
As options 128-135 are not officially assigned for PXE use (previous
to November 2004 they were considered site-specific options, [6]),
use of these options may conflict with other uses of these options.
was oddly phrased - perhaps the last line should have been something like
use of these option values for PXE may conflict with other uses of the
same options on the same networks.
Thanks,
Spencer Dawkins
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
