Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)
draft-ietf-dhc-duid-uuid-03

[Ballot comment]
"That embeds a [UUID]."  - embeds a UUID in what? I guess
client or server identifier - might be no harm to clarify if
you want.

IANA understands that, upon approval of this document, there is a single
IANA Action which must be completed.

In the DUIDs subregistry of the Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) located at:

http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#dhcpv6-parameters-6

IANA has made an early registration for value 4 on behalf of the
corresponding Internet-Draft. Upon publication the TEMPORARY indicators
for this assignment will be removed and the reference will be updated to
[ RFC-to-be ].

IANA understands that this is the only action required to be completed
upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID)) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID)'
  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-06-01. 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.

Abstract


This document defines a new DHCPv6 Unique Identifier (DUID) type,
called DUID-UUID.  DUID-UUIDs are derived from the already
standardized UUID format.  DUID-UUID makes it possible for devices to
use UUIDs to identify themselves to DHC servers and vice versa.
UUIDs are globally unique and readily available on many systems,
making them convenient identifiers to leverage within DHCP.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-duid-uuid/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-duid-uuid/


No IPR declarations have been submitted directly on this I-D.

  (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 ) 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?

This document is DHCP-specific, and doesn't really make use of
non-DHCP terminology.  I think that the usual review that the IESG
gives 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.

I am not aware of any IPR concerns, and none have been registered with
the IETF.

  (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? 

There was significant commentary from active members of the working
group.  Not every participant is even interested in this spec, but
among those who have an interest, it was agreed that the work was
useful and desirable.

  (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 commentary from several participants during the initial last
call, and their concerns were addressed.  I am not aware of any
dissent over the advancement of this specification.

  (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?

The only nit on the document is that it's 96 days in the past, which
is my fault for taking so long to write this shepherd document.  The
document contains no MIBs, media types or URI types.

  (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].

There are normative and informative references; all references are to
published RFCs.

  (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?

Yes, each of these steps has been followed in the IANA considerations
section.

  (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 defines a new DHCP Unique Identifier (DUID) type
    to be used for identifying clients using Universally Unique
    Identifiers (UUIDs).  The document defines what is meant by
    "universal," excluding several things called UUIDs that do
    not qualify.  The purpose of the document is to allow devices
    that have genuine UUIDs to use those as DUIDs, rather than
    forming new identifiers and requiring the maintenance of tables
    mapping between UUIDs and DUIDs.

    Working Group Summary
    This document appeared in the working group in October of 2010.
    2008.  There has been substantial review of this document.

    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 .'

The document shepherd is Ted Lemon .  I believe
the responsible A-D is Ralph Droms.