Dynamic Host Configuration Protocol Options Used by PXELINUX
draft-ietf-dhc-pxelinux-03

[Ballot discuss]
The security considerations section includes the curious statement "The use of these options
present no additional security risk", but the following paragraph describes a use of the reboot
option to implment denial of service.

I believe this sentence should be moved to the end of the security considerations section, and
needs to be further clarified.  I interpreted this as no additional security risks "beyond those
identified above and those previously identified in RFCs 2131, 2132, and 3942", but that was
a guess...

[Ballot discuss]
The security considerations section includes the curious statement "The use of these options
present no additional security risk", but the following paragraph describes a use of the reboot
option to implmement denial of service.

I believe this sentence should be moved to the end of the security considerations section, and
needs to be further clarified.  I interpreted this as no additional security risks "beyond those
identified in RFCs 2131, 2132, and 3942", but that was a guess...

[Ballot comment]
I assume that implementations claiming conformance to this spec must implement all four
options.  Perhaps we could add a statement somewhere to that effect?

[Ballot comment]
Section 4.2 and 5.2: Do I understand correctly that there are no string length limitations other than the 255 that is implied by the 1 byte size field?

IANA Evaluation comments:

Upon approval of this document, the IANA will make the following
changes in "DHCP and BOOTP PARAMETERS" registry located at
http://www.iana.org/assignments/bootp-dhcp-parameters
sub-registry "BOOTP Vendor Extensions and DHCP Options"

OLD:
208 pxelinux.magic (string) = F1:00:74:7E (241.0.116.126) (Tentatively
Assigned - 23 Jun 2005)
209 pxelinux.configfile (text) (Tentatively Assigned - 23 Jun 2005)
210 pxelinux.pathprefix (text) (Tentatively Assigned - 23 Jun 2005)
211 pxelinux.reboottime (unsigned integer 32 bits) (Tentatively Assigned
- 23 Jun 2005)

New:
Data
Tag Name Length Meaning
Reference
--- + ---- +------ +------- +-
--------
208 + pxe MAGIC + 4 +PXE magic string = F1:00:74:7E
+[RFC-dhc-pxelinux-02] Deprecated
209 + Configuration File + N +Configuration file
+[RFC-dhc-pxelinux-02]
210 + Path Prefix + N +Path Prefix Option
+[RFC-dhc-pxelinux-02]
211 + Reboot Time + 4 +Reboot Time
+[RFC-dhc-pxelinux-02]

We understand the above to be the only IANA Action for this document.

[Ballot comment]
I believe that the title and Abstract should expand PXELINUX so that there is an indication to people doing a search in the RFC repository what the defied options are about. I also think that the second phrase in the Abstract 'These codes were historically designated 'Site Local', but are presently being made available for allocation as standard DHCP Options.' should be striken out as after the publication of RFC 3942 it does not matter any longer where in the option space the numbers come from.

I have made my AD review on this document.
The document is basically in good shape, but
I noticed a few places where clearer text was
needed. First, I believe it would be useful if
the abstract also stated that the code
values will be assigned for this purpose, and
not only describe what the situation is
before the approval of this document.

Second, Section 3.4 text should be improved
to avoid an apparent inconsistency (... recommend
use ... undesirable to suffer collisions ...)

There were a few other small things.

Given that the changes are small, I have simply
inserted RFC Editor notes to the tracker and
intend to take the draft to the IESG review without
asking for a new revision.

Comments on the suggested edits appreciated,
see below.

PROTO Write-up

1) Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to the IESG
for publication?

Yes and yes.

2) Has the document had adequate review from both key WG members and
key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?

The draft has only been reviewed by a few key WG members. The chairs
believe this is sufficient since this is an informational document
describing current common usage of some of the previously site-specific
DHCP option codes. The process of recording such usage of the
previously site-specific option codes are in line with RFC 3942.
Some minor changes were suggested during wglc of revision 01, which
are incorporated in revision 02. The designer and implementer of these
options were also involved in producing and reviewing the document.

3) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No

4) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document,
or whether there really is a need for it, etc., but at the same
time these issues have been discussed in the WG and the WG has
indicated it wishes to advance the document anyway.

No

5) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with
it?

Only a few individuals have actively supported it, the remainder of
the group have been silent. We believe the WG as a whole understands
that the usage described in the draft needs to be documented per
RFC 3942, even if they have not reviewed or actively supported the
document.

6) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

No

7) Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).

We believe the document is OK. The tool complains about the RFC 2119
boiler plate, but we believe it is OK as is.

8) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:

This document is only informational.

- Technical Summary

- Working Group Summary

- Protocol Quality