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 |