Skip to main content

DHCPv6 Options for Network Boot
RFC 5970

Revision differences

Document history

Date Rev. By Action
2015-10-14
10 (System) Notify list changed from dhc-chairs@ietf.org, draft-ietf-dhc-dhcpv6-opt-netboot@ietf.org to (None)
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Alexey Melnikov
2010-09-14
10 Cindy Morgan State changed to RFC Published from RFC Ed Queue by Cindy Morgan
2010-09-14
10 Cindy Morgan [Note]: changed to 'RFC 5970' by Cindy Morgan
2010-09-14
10 (System) RFC published
2010-08-16
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-08-16
10 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-08-02
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-07-30
10 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-07-29
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-07-29
10 (System) IANA Action state changed to In Progress
2010-07-29
10 Cindy Morgan IESG state changed to Approved-announcement sent
2010-07-29
10 Cindy Morgan IESG has approved the document
2010-07-29
10 Cindy Morgan Closed "Approve" ballot
2010-07-26
10 (System) New version available: draft-ietf-dhc-dhcpv6-opt-netboot-10.txt
2010-07-22
10 Dan Romascanu
[Ballot comment]
1. The title of the document should refer to 'options' rather then 'option'

2. In Section 5:

The Boot File URL option does …
[Ballot comment]
1. The title of the document should refer to 'options' rather then 'option'

2. In Section 5:

The Boot File URL option does not place any constraints on the
  protocol used for downloading the boot file, other than that it must
  be possible to specify it in a URL.

s/must/MUST/
2010-07-22
10 Dan Romascanu [Ballot discuss]
2010-07-22
10 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2010-06-08
10 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov
2010-06-08
10 Alexey Melnikov [Ballot comment]
2010-06-08
10 Alexey Melnikov
[Ballot discuss]
[Updated: added item # 3]

I have only a couple of minor comments I would like to discuss before recommending approval of this …
[Ballot discuss]
[Updated: added item # 3]

I have only a couple of minor comments I would like to discuss before recommending approval of this document:

3)
  Information that is required for booting over the network can include
  information about the server on which the boot files can be found,
  the protocol to be used for the download (for example HTTP [RFC2616]
  or TFTP [RFC1350]), the name of the boot file and additional
  parameters which should be passed to the OS kernel or boot loader
  program respectively.

DISCUSS DISCUSS: Is any protocol a mandatory-to-implement? Is mandatory-to-implement needed in this case?
2010-06-07
10 David Harrington [Ballot discuss]
2010-06-07
10 David Harrington [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss by David Harrington
2010-06-06
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-06-06
09 (System) New version available: draft-ietf-dhc-dhcpv6-opt-netboot-09.txt
2010-05-06
10 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2010-05-06
10 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo
2010-05-05
10 Jari Arkko [Ballot comment]
I support David Harrington's Discuss though.
2010-05-05
10 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko
2010-05-05
10 Alexey Melnikov
[Ballot comment]
3.1.  Boot File Uniform Resource Locator (URL) Option

  Clients that have DNS
  implementations should support the use of domain names in …
[Ballot comment]
3.1.  Boot File Uniform Resource Locator (URL) Option

  Clients that have DNS
  implementations should support the use of domain names in the URL.

s/should/SHOULD ?
2010-05-05
10 Alexey Melnikov
[Ballot discuss]
[Updated: added item # 3]

I have only a couple of minor comments I would like to discuss before recommending approval of this …
[Ballot discuss]
[Updated: added item # 3]

I have only a couple of minor comments I would like to discuss before recommending approval of this document:

1) 3.2.  Boot File Parameters Option

  This option is sent by the server to the client.  It consists of
  multiple UTF-8 strings.

This needs a Normative reference to the UTF-8 document (RFC 3629).

2)
7.  Security considerations

  Note also that DHCPv6 messages are sent unencrypted by default.  So
  the boot file URL options are sent unencrypted over the network, too.
  This can become a security risk since the URLs can contain sensitive
  information like user names and passwords (for example a URL like
  "ftp://username:password@servername/path/file").

Use of passwords in URIs is deprecated (not allowed by the syntax specified in the most recent URI spec).

3)
  Information that is required for booting over the network can include
  information about the server on which the boot files can be found,
  the protocol to be used for the download (for example HTTP [RFC2616]
  or TFTP [RFC1350]), the name of the boot file and additional
  parameters which should be passed to the OS kernel or boot loader
  program respectively.

DISCUSS DISCUSS: Is any option a mandatory-to-implement? Is mandatory-to-implement needed in this case?
2010-05-05
10 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2010-05-05
10 Dan Romascanu
[Ballot comment]
1. The title of the document should refer to 'options' rather then 'option'

2. In the Introduction - I am not sure that …
[Ballot comment]
1. The title of the document should refer to 'options' rather then 'option'

2. In the Introduction - I am not sure that BIOS is a perfect synonim for the basic firmware, it looks to me to be more like an example. In any case the acronym should be expanded.

3. Section 3.1: Boot File Uniform Resource Locator (URL) Option

Here is identified a bootfile "URL" whereas RFC3986 refers now more globally to "URI"

As per RFC9386:

  An individual scheme does not have to be classified as being just one
  of "name" or "locator".  Instances of URIs from any given scheme may
  have the characteristics of names or locators or both, often
  depending on the persistence and care in the assignment of
  identifiers by the naming authority, rather than on any quality of
  the scheme.  Future specifications and related documentation should
  use the general term "URI" rather than the more restrictive terms
  "URL" and "URN" [RFC3305].

Any specific reason to use "URL" instead of URI?

4. In section 3.1:

"  option-len        Length of the boot-file-url in octets."

There is no limit to the option length. if the URI provided to the client is a domain name, RFC1035 limits the length to
255 octets. Does this limit apply here?

5. In section 3.1:

"  If the URL is expressed using an IPv6 address rather than a domain
  name, the address in the URL then MUST be enclosed in "[" and "]"
  characters, conforming to [RFC3986].  Clients that have DNS
  implementations should support the use of domain names in the URL."

RFC3986 allows other type of representations e.g. tel: or mailto:

Clarify that the considered URI is a host identified either by a registered name or an IP address as defined in section 3.2 of RFC 3986.
2010-05-05
10 Dan Romascanu
[Ballot discuss]
The DISCUSS and COMMENTs are based in part on the OPS-DIR review performed by Lionel Morand.

1. In section 3.3 'The client can …
[Ballot discuss]
The DISCUSS and COMMENTs are based in part on the OPS-DIR review performed by Lionel Morand.

1. In section 3.3 'The client can use this option ...' and 'The server can use this option ...' - we need normative language here probably s/can/SHOULD/

2. In Section 5:

The Boot File URL option does not place any constraints on the
  protocol used for downloading the boot file, other than that it must
  be possible to specify it in a URL.

s/must/MUST/

3. In section 7:

  To prevent this kind of
  attack, clients can use authentication of DHCPv6 messages (see
  chapter 21. in [RFC3315]).

s/can/SHOULD/

'... so it is strongly recommended not to use sensitive
  information in the URLs in untrusted networks.'

s/recommended/RECOMMENDED/
2010-05-05
10 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2010-05-05
10 Stewart Bryant
[Ballot comment]
The following IANA action gets pulled out of a hat without any mention in the Abstract, Introduction or Text.

"This document also introduces …
[Ballot comment]
The following IANA action gets pulled out of a hat without any mention in the Abstract, Introduction or Text.

"This document also introduces a new IANA registry for processora rchitecture types.  The name of this registry shall be "Processor Architecture Type".  Registry entries consist of a 16-bit integer recorded in decimal format, and a descriptive name.  The initial values of this registry can be found in [RFC4578] section 2.1."

I have no objection to DHCP WG creating this registry, but it should not be tucked down in the bottom of this document with out prior indication to reviewers.
2010-05-05
10 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2010-05-05
10 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant
2010-05-05
10 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2010-05-04
10 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2010-05-04
10 Sean Turner
[Ballot comment]
Have the authors considered some additional words in the security considerations about the fact that downloading the wrong operating system could lead to …
[Ballot comment]
Have the authors considered some additional words in the security considerations about the fact that downloading the wrong operating system could lead to compromise of data on local storage.
2010-05-04
10 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded by Sean Turner
2010-05-04
10 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2010-05-03
10 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre
2010-05-03
10 Peter Saint-Andre
[Ballot comment]
Section 3.1 (Boot File Uniform Resource Locator (URL) Option) states that "The server sends this option to inform the client about an URL …
[Ballot comment]
Section 3.1 (Boot File Uniform Resource Locator (URL) Option) states that "The server sends this option to inform the client about an URL to a boot file." and states of "boot-file-url" that "This string is the URL for the boot file." Does this specification really mean "URL"? Confer Section 1.1.3 of RFC 3986.
2010-04-29
10 Ralph Droms State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ralph Droms
2010-04-28
10 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2010-04-24
10 Alexey Melnikov
[Ballot comment]
3.1.  Boot File Uniform Resource Locator (URL) Option

  Clients that have DNS
  implementations should support the use of domain names in …
[Ballot comment]
3.1.  Boot File Uniform Resource Locator (URL) Option

  Clients that have DNS
  implementations should support the use of domain names in the URL.

s/should/SHOULD ?
2010-04-24
10 Alexey Melnikov
[Ballot discuss]
I have only a couple of minor comments I would like to discuss before recommending approval of this document:

1) 3.2.  Boot File …
[Ballot discuss]
I have only a couple of minor comments I would like to discuss before recommending approval of this document:

1) 3.2.  Boot File Parameters Option

  This option is sent by the server to the client.  It consists of
  multiple UTF-8 strings.

This needs a Normative reference to the UTF-8 document (RFC 3629).

2)
7.  Security considerations

  Note also that DHCPv6 messages are sent unencrypted by default.  So
  the boot file URL options are sent unencrypted over the network, too.
  This can become a security risk since the URLs can contain sensitive
  information like user names and passwords (for example a URL like
  "ftp://username:password@servername/path/file").

Use of passwords in URIs is deprecated (not allowed by syntax).
2010-04-24
10 Alexey Melnikov
[Ballot comment]
3.1.  Boot File Uniform Resource Locator (URL) Option

  Clients that have DNS
  implementations should support the use of domain names in …
[Ballot comment]
3.1.  Boot File Uniform Resource Locator (URL) Option

  Clients that have DNS
  implementations should support the use of domain names in the URL.

s/should/SHOULD ?
2010-04-24
10 Alexey Melnikov
[Ballot discuss]
I have only a couple of minor comments I would like to discuss before recommending approval of this document:

1) 3.2.  Boot File …
[Ballot discuss]
I have only a couple of minor comments I would like to discuss before recommending approval of this document:

1) 3.2.  Boot File Parameters Option

  This option is sent by the server to the client.  It consists of
  multiple UTF-8 strings.

This needs a Normative reference to the UTF-8 document (RFC 3629).

2)
7.  Security considerations

  Note also that DHCPv6 messages are sent unencrypted by default.  So
  the boot file URL options are sent unencrypted over the network, too.
  This can become a security risk since the URLs can contain sensitive
  information like user names and passwords (for example a URL like
  "ftp://username:password@servername/path/file").

Use of passwords in URIs is deprecated (not allowed by syntax).
2010-04-17
10 David Harrington
[Ballot discuss]
1) The abstract says "required for booting" - is this rfc2119 required?
section 1 says "can be used" - should this be MAY? …
[Ballot discuss]
1) The abstract says "required for booting" - is this rfc2119 required?
section 1 says "can be used" - should this be MAY?
"Information that is required for booting can include" ... "that should be sent" - if it is required, then I assume it MUST include and MUST be sent, otherwise it isn't required. The language here is all over the place. This MUST be tightened up.

2) this defines parameters for ipv6; is there a companion document for ipv4? section 1 doesn't mention it.

3) This is standards-track. What is MUST implement here, to be compliant? if boot file parameters option is implemented, it appears to supplement the URL option. Is the URL option MUST implement? is the DNS support MUST-implement? SHOULD implement? is the parameters option MUST implement?

4) section 3.2 mentions UTF-8, but gives no reference. Is this 2044, 2279, or 3629? I assume 3629, but some ptotocols require the earlier versions for backwards compatibility. Please add a reference to the correct RFC for this usage.

5) section 3.2:
s/it MUST pass these parameters in the order/it MUST pass these parameters, if present, in the order/

6) section 3.3: The client can use this option ...
The server can use this option ...
are these MAYs? or SHOULDs?
are these MUST implements (if not, the client cannot and the server cannot ...)

7) section 3.3. last paragraph.
Why MUST the list only contain architectural types that have been initially queried by the client?

8) section 6 - what registry should be modified? I looked at chapter 22 of RFC3315, and it was not obvious to me which registry you want modified. Please do not make IANA guess which one you want modified.
2010-04-17
10 David Harrington [Ballot Position Update] New position, Discuss, has been recorded by David Harrington
2010-04-14
10 Amy Vezza Last call sent
2010-04-14
10 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2010-04-13
10 Ralph Droms Telechat date was changed to 2010-05-06 from 2010-04-22 by Ralph Droms
2010-04-13
10 Ralph Droms State Changes to Last Call Requested from Waiting for AD Go-Ahead by Ralph Droms
2010-04-13
10 Ralph Droms Last Call was requested by Ralph Droms
2010-04-13
10 Alexey Melnikov
[Ballot comment]
3.1.  Boot File Uniform Resource Locator (URL) Option

  Clients that have DNS
  implementations should support the use of domain names in …
[Ballot comment]
3.1.  Boot File Uniform Resource Locator (URL) Option

  Clients that have DNS
  implementations should support the use of domain names in the URL.

s/should/SHOULD ?
2010-04-13
10 Alexey Melnikov
[Ballot discuss]
I have only a minor comments I would like to discuss before recommending approval of this document:

1) 3.2.  Boot File Parameters Option …
[Ballot discuss]
I have only a minor comments I would like to discuss before recommending approval of this document:

1) 3.2.  Boot File Parameters Option

  This option is sent by the server to the client.  It consists of
  multiple UTF-8 strings.

This needs a Normative reference to the UTF-8 document (RFC 3629).
2010-04-13
10 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov
2010-04-12
10 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2010-04-09
10 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Julien Laganier.
2010-04-07
10 Amanda Baber
IANA comments:

Note that we have a question about Action 2.

Upon approval of this document, IANA will perform the following actions
at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

ACTION …
IANA comments:

Note that we have a question about Action 2.

Upon approval of this document, IANA will perform the following actions
at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

ACTION 1:

make the following assignments in the sub-registry "DHCP Option Codes"

Value Description Reference
----- ----------------------- ----------
TBD1 OPT_BOOTFILE_URL [RFC-dhc-dhcpv6-opt-netboot-08]
TBD2 OPT_BOOTFILE_PARAM [RFC-dhc-dhcpv6-opt-netboot-08]
TBD3 OPTION_CLIENT_ARCH_TYPE [RFC-dhc-dhcpv6-opt-netboot-08]
TBD4 OPTION_NII [RFC-dhc-dhcpv6-opt-netboot-08]


ACTION 2:

create the following registry:

Registry Title: Processor Architecture Types
Registration Procedures: Expert Review
Value Range: 16bit unsigned integer

Value Description Reference
----- ----------------- ---------
0 Intel x86PC [RFC-dhc-dhcpv6-opt-netboot-08]
1 NEC/PC98 [RFC-dhc-dhcpv6-opt-netboot-08]
2 EFI Itanium [RFC-dhc-dhcpv6-opt-netboot-08]
3 DEC Alpha [RFC-dhc-dhcpv6-opt-netboot-08]
4 Arc x86 [RFC-dhc-dhcpv6-opt-netboot-08]
5 Intel Lean Client [RFC-dhc-dhcpv6-opt-netboot-08]
6 EFI IA32 [RFC-dhc-dhcpv6-opt-netboot-08]
7 EFI BC [RFC-dhc-dhcpv6-opt-netboot-08]
8 EFI Xscale [RFC-dhc-dhcpv6-opt-netboot-08]
9 EFI x86-64 [RFC-dhc-dhcpv6-opt-netboot-08]
10-65535 Unassigned

QUESTION: The registry contains no reserved codepoints for future
extensions, as discussed in RFC5226. Should a codepoint be reserved for
that purpose?
2010-04-01
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Julien Laganier
2010-04-01
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Julien Laganier
2010-03-29
10 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2010-03-29
10 Ralph Droms State Changes to Last Call Requested from Publication Requested by Ralph Droms
2010-03-29
10 Ralph Droms Last Call was requested by Ralph Droms
2010-03-29
10 Ralph Droms Placed on agenda for telechat - 2010-04-22 by Ralph Droms
2010-03-29
10 Ralph Droms [Note]: 'Ted Lemon (mellon@nominum.com) is the document shepherd.' added by Ralph Droms
2010-03-29
10 Ralph Droms [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms
2010-03-29
10 Ralph Droms Ballot has been issued by Ralph Droms
2010-03-29
10 Ralph Droms Created "Approve" ballot
2010-03-29
10 (System) Ballot writeup text was added
2010-03-29
10 (System) Last call text was added
2010-03-29
10 (System) Ballot approval text was added
2010-03-25
10 Cindy Morgan
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
  …
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

I (Ted Lemon <mellon@nominum.com>) am the shepherd for this document.
I have personally reviewed the document, and I think it is ready to
forward to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document has been carefully reviewed by several experienced DHCP
implementors.  I have no concerns that the document has not had
adequate review.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

Various experts were consulted on questions related to terminology, such
as whether to use URI or URL.  The draft itself is fairly simple, and
I am not aware of any issues which require review by other working
groups, but of course we are open to suggestions.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

I am not aware of any IPR concerns.  This document is simply porting
DHCPv4 technology to DHCPv6.

  (1.e) 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? 

Consensus is strong.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

I am not aware of any entrenched anti-netboot activists in the working
group.  Discussion has been civil.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes.  The document was last submitted prior to the latest update to
the IETF Trust Provisions as of 28 Dec 2009, so it contains
boilerplate from a previous version.  My intention is to ask the
author to correct this after IESG review, on the assumption that other
document changes will also be required.  Idnits also suggests that this
document include a disclaimer for pre-RFC5378 work.  As far as I know
this document is original work, but I will check with the authors to
see if they copied any text out of an old RFC.

The document also makes a normative reference to an informational
draft.  The reason for this is that the original PXE spec was done
without IETF approval, and deployed without there ever being a
document describing it.  In the process of trying to clean up old
options, we were able to encourage some PXE vendors to write a
docuemnt describing what they'd done.  That document was released as
an informational document, RFC4578, and that is the source of the
normative reference to an informational document.  I don't know what
the right process is for handling this, and would appreciate any
suggestions.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The document makes reference to the Preboot Execution Environment
Specification, which is not an IETF document, and to the Unified
Extensible Firmware Interface Specification, Version 2.3, which
is also not an IETF document.  As far as I understand it, these
documents are stable, but in the sense that they are not maintained
by the IETF, you could say that their state is unclear.  I do not
know how to handle this, and would appreciate any advice you can
offer.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA considerations seem correct to me.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The document doesn't contain any such sections.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
This document provides a standard mechanism for providing
DHCPv6 clients with information required to bootstrap
using the network.

    Working Group Summary
This document appeared in the working group several
years ago.  There was substantial review and revision, which
simplified the document and changed some recommendations
the document made, for example replacing a recommendation
to use tftp for downloads with a recommendation to use
http.  The review in the working group has been thorough,
and there is substantial demand for this extension.

    Document Quality
The document has undergone careful review, and the working
group is satisfied with its quality.

    Personnel
Who is the Document Shepherd for this document?  Who is the
Responsible Area Director?  If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are <TO BE ADDED BY THE AD>.'

The document shepherd is Ted Lemon <mellon@nominum.com>.  I believe
the responsible A-D is Ralph Droms.
2010-03-25
10 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2010-03-25
10 Cindy Morgan [Note]: 'Ted Lemon (mellon@nominum.com) is the document shepherd.' added by Cindy Morgan
2010-01-04
08 (System) New version available: draft-ietf-dhc-dhcpv6-opt-netboot-08.txt
2009-12-19
07 (System) New version available: draft-ietf-dhc-dhcpv6-opt-netboot-07.txt
2009-10-26
06 (System) New version available: draft-ietf-dhc-dhcpv6-opt-netboot-06.txt
2009-08-10
05 (System) New version available: draft-ietf-dhc-dhcpv6-opt-netboot-05.txt
2009-04-14
04 (System) New version available: draft-ietf-dhc-dhcpv6-opt-netboot-04.txt
2009-02-04
03 (System) New version available: draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
2008-11-18
02 (System) New version available: draft-ietf-dhc-dhcpv6-opt-netboot-02.txt
2008-10-14
01 (System) New version available: draft-ietf-dhc-dhcpv6-opt-netboot-01.txt
2008-08-19
00 (System) New version available: draft-ietf-dhc-dhcpv6-opt-netboot-00.txt