Skip to main content

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
[Ballot discuss]
The reference to RFC 3315, along with the lack of a reference to RFC 5891, seems to imply that internationalized domain …
[Ballot discuss]
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.
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