Shepherd writeup
draft-ietf-dhc-dhcpv6-load-balancing-02

Document Writeup, template from IESG area on ietf.org, dated 24 February
2012.

draft-ietf-dhc-dhcpv6-load-balancing-02

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

  Standards track, as clearly indicated on the title page header. This
  draft defines a standard that DHCPv6 server implementors may choose
  to support. Despite no new messages or options are defined, this
  document defines procedures that DHCPv6 servers must follow to
  properly deploy load balancing. Therefore standards track is the
  right type.

(2) 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 method of algorithmic load balancing for
  IPv6 Dynamic Host Configuration Protocol (DHCPv6) traffic.  It
  enables multiple, cooperating servers to decide which one should
  service a client, without necessarily exchanging any information
  between the servers.  The server selection is based on the servers
  hashing client DHCP Unique Identifiers (DUIDs) when multiple DHCPv6
  servers are available to service DHCPv6 clients.  The proposed
  technique provides for efficient server selection when multiple
  DHCPv6 servers offer services on a network without requiring any
  changes to existing DHCPv6 clients.  This algorithm is an extension
  of an already defined and proven algorithm used for DHCPv4, as
  described in RFC 3074.

Working Group Summary:

  This document has been first presented around Aug. 2012. As it is
  DHCPv6 equivalent of its standardized and well proven DHCPv4 counter
  part, there was never any opposition to that approach. After 4
  individual revisions it was quickly adopted in Dec. 2012. It went
  through WGLC in Feb. 2013, when the I-D received support and several
  smaller issues were raised. Its sole author became busy at that time and
  the document expired. The work has been resumed after around a year,
  updated -01 was published and a second WGLC was issued and passed.
  Couple minor new issues were raised, but they were addressed in -02.

Document Quality:

  This document received sufficient reviews and is of sufficiently
  high quality. As this is essentially a modification of the RFC3074 to
  DHCPv6, the text essentially requires familiarity with 3074. In
  authors and chairs' opinion this is ok, as the alternative would be to
  duplicate large parts of the text from RFC 3074.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Tomek Mrugalski is the document shepherd. Ted Lemon is the
  responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  I thoroughly reviewed this document twice:
  http://www.ietf.org/mail-archive/web/dhcwg/current/msg14316.html (-00)
  http://www.ietf.org/mail-archive/web/dhcwg/current/msg15450.html (-01)

  I also did intermediate reviews, but did not post anything to the
  list. I had couple discussions about this I-D with Bernie Volz (DHC
  co-chair) and Andrew (the author). All my comments were addressed.
  It is ready in my opinion.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. I counted a total of 87 posts (search for "load-balancing",
  "Load Balancing" or "loadbv6") to the ML regarding this work. This
  was a healthy discussion and I believe all raised issues have be
  addressed. There was additional discussion off the list. The draft
  is ready in my opinion.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  No. This is strictly DHCP work, so no external reviews outside of
  DHCP are needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

  I have no concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

  The author has confirmed in writing that there are on IPRs
  outstanding.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(9) 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 never any objection to this work. It is an old concept
  applied to DHCPv6, so it is perhaps considered less exciting than
  other work. I believe that's why we received smaller number of
  responses to WGLC. Nevertheless, chairs decided that it has sufficient
  support to pass both WGLCs. (The first WGLC technically passed, but
  since it was a year ago, chairs decided to repeat WGLC to reconfirm
  that there still is consensus for this work).

(10) 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 publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  There is one comment and one warning, but they are benign. The first
  one is about the document publication date being in the past. The
  other one is about referencing dhcpv4-over-dhcpv6 draft that has
  been recently published as RFC7431. That's ok, as it was published
  after load-balancing draft was published. It can be fixed by the RFC
  Editor (or by the author if updated revision is required).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No such review is needed.

(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) 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 plan for their completion?

  There is one normative reference to ietf-dhc-dhcpv4-over-dhcpv6,
  which has been published couple days ago as RFC7341.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  There are none.

(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

  No. This document applied RFC 3074 to DHCPv6, but does not change
  anything in it, hence no update is needed. It also extends base DHCPv6
  spec (RFC3315), but does not change it (it is still possible to
  implement 3315 without looking at this work), hence no update needed.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This draft has no IANA actions. That is clearly states in IANA
  Considerations section.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  There are none.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No such reviews were performed.
Back