The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option
RFC 6440
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2018-12-20
|
10 | (System) | Received changes through RFC Editor sync (changed abstract to 'In order to derive a Domain-Specific Root Key (DSRK) from the Extended Master Session Key (EMSK) … Received changes through RFC Editor sync (changed abstract to 'In order to derive a Domain-Specific Root Key (DSRK) from the Extended Master Session Key (EMSK) generated as a side effect of an Extensible Authentication Protocol (EAP) method, the EAP peer must discover the name of the domain to which it is attached. This document specifies a Dynamic Host Configuration Protocol Version 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients using the EAP Re-authentication Protocol (ERP) EAP method of the name of the local domain for ERP. [STANDARDS-TRACK]') |
|
2015-10-14
|
10 | (System) | Notify list changed from hokey-chairs@ietf.org, draft-ietf-hokey-ldn-discovery@ietf.org to (None) |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Sean Turner |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Ralph Droms |
|
2011-12-16
|
10 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
|
2011-12-16
|
10 | (System) | RFC published |
|
2011-11-01
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2011-10-31
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
|
2011-10-11
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2011-10-11
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2011-10-05
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2011-10-05
|
10 | (System) | IANA Action state changed to In Progress from On Hold |
|
2011-06-09
|
10 | (System) | IANA Action state changed to On Hold from Waiting on Authors |
|
2011-06-07
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2011-06-06
|
10 | (System) | IANA Action state changed to In Progress from RFC-Ed-Ack |
|
2011-06-04
|
10 | Stephen Farrell | Ballot writeup text changed |
|
2011-05-10
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2011-05-10
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
|
2011-05-10
|
10 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
|
2011-05-09
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2011-05-09
|
10 | (System) | IANA Action state changed to In Progress |
|
2011-05-09
|
10 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2011-05-09
|
10 | Amy Vezza | IESG has approved the document |
|
2011-05-09
|
10 | Amy Vezza | Closed "Approve" ballot |
|
2011-05-09
|
10 | Amy Vezza | Approval announcement text changed |
|
2011-05-09
|
10 | Amy Vezza | Ballot writeup text changed |
|
2011-05-06
|
10 | Stephen Farrell | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup. |
|
2011-05-06
|
10 | Stephen Farrell | Approval announcement text changed |
|
2011-05-06
|
10 | Stephen Farrell | Ballot writeup text changed |
|
2011-05-06
|
10 | Stephen Farrell | Approval announcement text changed |
|
2011-05-06
|
10 | Stephen Farrell | Approval announcement text regenerated |
|
2011-05-06
|
10 | Stephen Farrell | Ballot writeup text changed |
|
2011-05-06
|
10 | Ralph Droms | [Ballot comment] Based on the edited text in -10, I've cleared my Discuss. |
|
2011-05-06
|
10 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss |
|
2011-04-22
|
10 | (System) | New version available: draft-ietf-hokey-ldn-discovery-10.txt |
|
2011-04-22
|
09 | (System) | New version available: draft-ietf-hokey-ldn-discovery-09.txt |
|
2011-04-21
|
10 | Ralph Droms | [Ballot discuss] Rev -08 partially addresses my concerns about the use of the ERP Local Domain Name option with ERP. I've included suggested OLD/NEW text … [Ballot discuss] Rev -08 partially addresses my concerns about the use of the ERP Local Domain Name option with ERP. I've included suggested OLD/NEW text below to further clarify the intent of the ERP Local Domain Name option. While these suggestions may seem all editorial, in total they represent enough of a change to warrant a Discuss. Abstract: OLD: This document specifies a Dynamic Host Configuration Protocol Version 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients using the EAP Re-authentication Protocol (ERP) EAP method of the name of the local domain. NEW: This document specifies a Dynamic Host Configuration Protocol Version 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients using the EAP Re-authentication Protocol (ERP) EAP method of the name to be used as the local domain for ERP. Introduction: OLD: The EAP Re-authentication Protocol (ERP) [RFC5296] is designed to allow faster re-authentication of a mobile device which was previously authenticated by means of the Extensible Authentication Protocol [RFC3748]. Given that the local root key (e.g., DSRK RFC 5295 [RFC5295]) is generated using the local domain name (LDN), LDN discovery is an important part of re-authentication. As described in RFC 5296 [RFC5296], the local domain name can be learned by the mobile device through the ERP exchange or via a lower-layer mechanism. However, no lower-layer mechanisms for LDN discovery have yet been defined. This document specifies an extension to DHCPv6 for local domain name discovery by ERP peers. NEW: The EAP Re-authentication Protocol (ERP) [RFC5296] is designed to allow faster re-authentication of a mobile device which was previously authenticated by means of the Extensible Authentication Protocol [RFC3748]. Given that the local root key (e.g., DSRK RFC 5295 [RFC5295]) is generated using the local domain name (LDN), LDN discovery is an important part of re-authentication. As described in RFC 5296 [RFC5296], the LDN to be used in ERP can be learned by the mobile device through the ERP exchange or via a lower-layer mechanism. However, no lower-layer mechanisms for LDN discovery have yet been defined. This document specifies an extension to DHCPv6 for LDN to be used in ERP. Section 3: OLD: In DHCPv6-based local domain name discovery, the LDN option is used by the DHCPv6 client to obtain the local domain name from the DHCPv6 Server after full EAP authentication has taken place. NEW: In DHCPv6-based ERP LDN discovery, the ERP Local Domain Name option is used by the DHCPv6 client to obtain the ERP LDN from the DHCPv6 Server after full EAP authentication has taken place. The contents of the ERP Local Domain Name option are intended only for use with ERP and do not represent the name of a local domain for any other purposes. Section 3.1: OLD: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_LOCAL_DOMAIN_NAME | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | local-domain-name... +-+-+-+-+-+-+-+-+-+-+-+ option code OPTION_ERP_LOCAL_DOMAIN_NAME (TBD) option-length Length of the local-domain-name field, in octets NEW: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ERP_LOCAL_DOMAIN_NAME| option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | erp-local-domain-name... +-+-+-+-+-+-+-+-+-+-+-+ option code OPTION_ERP_LOCAL_DOMAIN_NAME (TBD) option-length Length of the erp-local-domain-name field, in octets Section 4: OLD: If a DHCPv6 client doesn't know the local domain name and requires the DHCPv6 Server to provide the DHCPv6 LDN option, it MUST include an Option Request option requesting the DHCPv6 LDN option, as described in Section 22.7 of RFC 3315 [RFC3315]. When the DHCPv6 client recieves a LDN option with the local domain name present in it, it MUST verify that the option length is no more than 256 octets (the maximum length of a single fully-qualified domain name (FQDN) allowed by the DNS), and that the local domain name is a properly encoded single FQDN, as specified in Section 8, "Representation and Use of Domain Names" of RFC3315 [RFC3315]. NEW: If a DHCPv6 client doesn't know the ERP LDN and requires the DHCPv6 Server to provide the DHCPv6 ERP Local Domain Name option, it MUST include an Option Request option requesting the DHCPv6 ERP Local Domain Name option, as described in Section 22.7 of RFC 3315 [RFC3315]. When the DHCPv6 client recieves an ERP Local Domain Name option with the ERP LDN present in it, it MUST verify that the option length is no more than 256 octets (the maximum length of a single fully-qualified domain name (FQDN) allowed by the DNS), and that the ERP LDN is a properly encoded single FQDN, as specified in Section 8, "Representation and Use of Domain Names" of RFC3315 [RFC3315]. Section 5: OLD: If a DHCPv6 relay agent has pre-existing knowledge of the local domain name (for example, from a previous AAA exchange), it SHOULD include it in an instance of the DHCPv6 LDN option and forward to the DHCPv6 server as a suboption of the Relay-Supplied Options option [I-D.ietf-dhc-dhcpv6-relay-supplied-options]. NEW: If a DHCPv6 relay agent has pre-existing knowledge of the ERP local domain name for a client (for example, from a previous AAA exchange), it SHOULD include it in an instance of the DHCPv6 ERP Local Domain Name option and forward to the DHCPv6 server as a suboption of the Relay-Supplied Options option [I-D.ietf-dhc-dhcpv6-relay-supplied-options]. |
|
2011-04-19
|
10 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
|
2011-04-19
|
08 | (System) | New version available: draft-ietf-hokey-ldn-discovery-08.txt |
|
2011-04-12
|
10 | Peter Saint-Andre | [Ballot Position Update] Position for Peter Saint-Andre has been changed to No Objection from Discuss |
|
2011-04-12
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2011-04-12
|
07 | (System) | New version available: draft-ietf-hokey-ldn-discovery-07.txt |
|
2011-03-31
|
10 | Stephen Farrell | [Ballot comment] Taking this over from Tim |
|
2011-03-31
|
10 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded |
|
2011-03-31
|
10 | Cindy Morgan | Responsible AD has been changed to Stephen Farrell from Tim Polk |
|
2011-03-22
|
10 | Ralph Droms | [Ballot comment] |
|
2011-03-22
|
10 | Ralph Droms | [Ballot discuss] I apologize for adding a late DISCUSS. My position is based on e-mail discussion with the authors, et al., regarding Jari's COMMENT and … [Ballot discuss] I apologize for adding a late DISCUSS. My position is based on e-mail discussion with the authors, et al., regarding Jari's COMMENT and my previous COMMENT about the scope of the "domain name" carried in the DHCPv6 Local Domain Name Option. The document needs to be clear that the DHCPv6 Local Domain Name Option carries a "domain name" to be used only by ERP, and not by other applications. |
|
2011-03-22
|
10 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to Discuss from No Objection |
|
2011-03-04
|
10 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Sam Weiler. |
|
2011-03-03
|
10 | Cindy Morgan | Removed from agenda for telechat |
|
2011-03-03
|
10 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
|
2011-03-03
|
10 | Jari Arkko | [Ballot comment] I agree with others that the document must be changed so that its title, abstract, and the option name match the use for … [Ballot comment] I agree with others that the document must be changed so that its title, abstract, and the option name match the use for ERP. This is not about general domains (e.g., DNS). |
|
2011-03-03
|
10 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-03-03
|
10 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-03-02
|
10 | Tim Polk | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
|
2011-03-02
|
10 | Peter Saint-Andre | [Ballot comment] 1. Please spell out FQDN and other relevant acronyms (e.g., perhaps AAA) on first use. 2. Section 5 has "DHPv6" instead of "DHCPv6". … [Ballot comment] 1. Please spell out FQDN and other relevant acronyms (e.g., perhaps AAA) on first use. 2. Section 5 has "DHPv6" instead of "DHCPv6". 3. The apps-review team review raised the following issue: This document also specifies a length limitation of 256 octets that does not take into account issues raised by RFC 4282. My recommendation would be to either match or reference the text in RFC 4282. |
|
2011-03-02
|
10 | Peter Saint-Andre | [Ballot discuss] [Updated 2011-03-02 to reference the apps-review team review by Eliot Lear.] 1. The reference to RFC 3315, along with the lack of … [Ballot discuss] [Updated 2011-03-02 to reference the apps-review team review by Eliot Lear.] 1. The reference to RFC 3315, along with the lack of a reference to RFC 5891, seems to imply that internationalized domain names are not supported. If so, please make that clear in the specification. 2. The apps-review team review raised the following major issues: The option specified in this draft is to be used for the specific purpose of ERP, and may not be appropriate for other uses, such as use in a search list. See Section 2 of RFC 5296. Both the option name and the text should make this clear. While this is an Applications Area review, the Security Considerations section should still conform to the requirements of RFC 3552. |
|
2011-03-02
|
10 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-03-02
|
10 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-03-01
|
10 | Ralph Droms | [Ballot comment] Small suggestion for clarity: s/EAP domain/domain/ in the Abstract., for those of us who leap to associating "domain" with "DNS"... |
|
2011-03-01
|
10 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-03-01
|
10 | Adrian Farrel | [Ballot comment] Acronyms need to be expaneded on first use in the body of the document. For example, EAP, DSRK, etc. |
|
2011-03-01
|
10 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-03-01
|
10 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-03-01
|
10 | Peter Saint-Andre | [Ballot comment] Please spell out FQDN and other relevant acronyms (e.g., perhaps AAA) on first use. |
|
2011-03-01
|
10 | Peter Saint-Andre | |
|
2011-03-01
|
10 | Peter Saint-Andre | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-03-01
|
10 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-03-01
|
10 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-03-01
|
10 | Sean Turner | [Ballot comment] #1) In the security considerations can you say something more about what happens if mutual authentication is not performed. #2) Section 5 should … [Ballot comment] #1) In the security considerations can you say something more about what happens if mutual authentication is not performed. #2) Section 5 should indicate why the DHCPv6 relay should include the LDN. #3) Sec 3: Can this option be used other than "after full EAP authentication"? Either way, just say so. |
|
2011-03-01
|
10 | Sean Turner | [Ballot discuss] #1) Is there no way that a relay agent might be acting on behalf of many domains without knowing? If so, then section … [Ballot discuss] #1) Is there no way that a relay agent might be acting on behalf of many domains without knowing? If so, then section 5 may need a few more words. #2) Section 6 says authentication is needed. I assume it's mutual authentication, but this should be explicitly stated. #3) Section 6, for how long must replays be detected? (And by whom?) How can that be done? (E.g. for a mobile device) |
|
2011-03-01
|
10 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-03-01
|
10 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-03-01
|
10 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-02-23
|
10 | Tim Polk | Placed on agenda for telechat - 2011-03-03 |
|
2011-02-16
|
10 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2011-02-10
|
10 | Tim Polk | [Ballot Position Update] New position, Yes, has been recorded for Tim Polk |
|
2011-02-10
|
10 | Tim Polk | Ballot has been issued |
|
2011-02-10
|
10 | Tim Polk | Created "Approve" ballot |
|
2011-02-10
|
10 | Tim Polk | Ballot writeup text changed |
|
2011-02-07
|
10 | Amanda Baber | IANA understands that, upon approval of this document, there is a single IANA Action that needs to be completed. In the DHCP Option Codes subregistry … IANA understands that, upon approval of this document, there is a single IANA Action that needs to be completed. In the DHCP Option Codes subregistry of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry located at: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml a new Option Code is to be registered as follows: Value: tbd Description: OPTION_LOCAL_DOMAIN_NAME Reference: [RFC-to-be] IANA understands that this is the only IANA Action required upon approval of this document. |
|
2011-02-02
|
10 | Cindy Morgan | Last call sent |
|
2011-02-02
|
10 | Cindy Morgan | State changed to In Last Call from In Last Call. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from In Last Call. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <hokey@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-hokey-ldn-discovery-06.txt> (The Local Domain Name DHCPv6 Option) to Proposed Standard The IESG has received a request from the Handover Keying WG (hokey) to consider the following document: - 'The Local Domain Name DHCPv6 Option' <draft-ietf-hokey-ldn-discovery-06.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-hokey-ldn-discovery/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-hokey-ldn-discovery/ |
|
2011-02-01
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Sam Weiler |
|
2011-02-01
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Sam Weiler |
|
2011-01-31
|
10 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <hokey@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-hokey-ldn-discovery-06.txt> (The Local Domain Name DHCPv6 Option) to Proposed Standard The IESG has received a request from the Handover Keying WG (hokey) to consider the following document: - 'The Local Domain Name DHCPv6 Option' <draft-ietf-hokey-ldn-discovery-06.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-hokey-ldn-discovery/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-hokey-ldn-discovery/ |
|
2011-01-31
|
10 | Tim Polk | Last Call was requested |
|
2011-01-31
|
10 | Tim Polk | State changed to Last Call Requested from Publication Requested. |
|
2011-01-31
|
10 | Tim Polk | Last Call text changed |
|
2011-01-31
|
10 | (System) | Ballot writeup text was added |
|
2011-01-31
|
10 | (System) | Last call text was added |
|
2011-01-31
|
10 | (System) | Ballot approval text was added |
|
2010-11-06
|
10 | Tim Polk | [Note]: 'The document shepherd is Tina Tsou <tena@huawei.com>' added by Tim Polk |
|
2010-11-06
|
10 | Tim Polk | (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? The document shepherd is Tina Tsou. I have reviewed the document, and believe it is ready 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 went through a WGLC and solicited comments from DHC WG. The comments were minor and were addressed. The delay in publication was to in order to wait to draft-ietf-dhc-dhcpv6-relay-supplied-options to go to publication. The document shepherd has no concerns about the review process. (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? No concerns, I think that the IESG review to documents of this type should be sufficient to capture any unclear use of terminology that wasn't immediately obvious in the DHC working group. (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. IPR disclosure to this document has been brought to the attention of the working group. There are no other concerns. (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.) There was no dissent in the last call. (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? None. (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]. References have been split. There is a normative reference to draft-ietf-dhc-dhcpv6-relay-supplied-options which has been ready for WGLC in DHC Working Group. (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 section exists; the registry is identified and there are no other new registries (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 specifies a Dynamic Host Configuration Protocol Version 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients of the name of the local domain. Working Group Summary This document appeared in the working group in the middle of 2009. There has been substantial interest in this document. Document Quality The document is a product of the Hokey working group. The document has working group consensus. 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 Tina Tsou <tena@huawei.com>. The responsible A-D is Tim Polk. |
|
2010-11-06
|
10 | Tim Polk | Draft Added by Tim Polk in state Publication Requested |
|
2010-10-01
|
06 | (System) | New version available: draft-ietf-hokey-ldn-discovery-06.txt |
|
2010-09-16
|
05 | (System) | New version available: draft-ietf-hokey-ldn-discovery-05.txt |
|
2010-09-16
|
04 | (System) | New version available: draft-ietf-hokey-ldn-discovery-04.txt |
|
2010-08-27
|
(System) | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-hokey-ldn-discovery-03 | |
|
2010-08-04
|
03 | (System) | New version available: draft-ietf-hokey-ldn-discovery-03.txt |
|
2010-08-04
|
02 | (System) | New version available: draft-ietf-hokey-ldn-discovery-02.txt |
|
2010-07-10
|
01 | (System) | New version available: draft-ietf-hokey-ldn-discovery-01.txt |
|
2010-04-09
|
00 | (System) | New version available: draft-ietf-hokey-ldn-discovery-00.txt |