DHCPv6 Redundancy Deployment Considerations
draft-ietf-dhc-dhcpv6-redundancy-consider-03

[Ballot comment]
I have no objection to the publication of this document that I found
readable.

The document title speaks of "redundancy" but the document is scoped to
"semi-redundant services" and makes a point of stressing how DHCPv6 does
not offer a redundancy protocol. It might be helpful to tune the title
to match the document.

[Ballot comment]
I have a few comments/questions on this draft, all of which are non-blocking.

1. I lied.  I won't be sending along a list of editorial issues... There are a ton of linguistic/editorial issues that I don't have time to itemize.  I strongly suggest an editorial pass through this document by another WG participant to clean this up.

2. In bullet #3 of section 2, the second part talks about getting configuration information or options.  Is this information obtained via Stateful DHCPv6, Stateless DHCPv6, or a combination of the two?

3. I cannot cleanly parse the first sentence of bullet #4 in section 2.

4. Does the last paragraph of section 2 really refer to a DHCPv6 *redundancy* protocol being published?

5. Section 2.2 says that end-hosts will not use DHCP prefix delegation.  Do you have considerations to offer for when they do make such requests?

6. This question may be due to a hole in my knowledge of DHCPv6, but iss there really any difference in the two scenarios described in sections 4.1 and 4.2, other than a possible difference in the prefix length?

7. In section 5, bullet #1 discusses the need for each DHCPv6 server to use the same allocation algorithm to ensure that each IPv6 address is only allocated to a single client.  Does this require every DHCPv6 server to see all requests?  If so, would that be feasible in the two target deployment scenarios?

[Ballot comment]
I am balloting "abstain" on this, because I don't want to block the document, but I echo the complaints of other ADs about how badly written it is.  Look at what Stephen said, and add that for me as well.  It's very hard to tell whether I really have "no objection" to this or whether I do.

The Security Considerations section is particularly bad.  It starts off with a long sentence, which I can't figure out what it says.  Then it has three more sentences that appear to identify one issue, which I paraphrase thus:

<< Dynamic updating of DNS using the models defined in this document creates opportunities to overwrite valid DNS resource records.  Overwriting valid DNS resource records maliciously could result in undesirable behavior. >>

Is that what's meant?  If not, then I completely don't understand the Security Considerations section.  If it *is* what's meant, then this seems awfully fluffy: we're opening things up to abuse... don't do it, because it's bad.  I hope the reality is that I misunderstand.

[Ballot comment]
I don't object to publishing this document as BCP (so this is not a DISCUSS), but I would like to hear why this intended status was chosen over Informational. The document says it does not address a standards based solution (so it's not the kind of document described in the first paragraph of section 5.1 of RFC2026). It's not setting policy or defining the operation of an IETF function. It seems instead to say "here's a way you can do this thing, and here are some things to consider if you choose to do it". That really seems like an Informational document. What's in here that makes Informational the wrong choice? (Please consider paragraph four of section 5.1 in RFC2026 when answering that.)

Thinking forward, publishing this as BCP may make work harder for the IETF if/when it does produce a standard mechanism to address this problem.

[Ballot comment]

  Please consider the editorial comments from the Gen-ART Review by
  Pete McCann on 24-Apr-2012.  The review can be found at:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07389.html

[Ballot comment]
- There are too many places where the spelling isn't correct, i.e., some native reader should proof read it!
- I'm not sure how useful this document is for network operators, but if the WG is fine with the draft, I won't object.
The draft did not add much for me on how to configure DHCPv6 servers to have some level of redundancy.

[Ballot comment]

This is quite badly written text, making it a much harder read than
ought be the case.  I was left wondering what was actually new here. I
suspect this will be a mostly harmless RFC as a result. Sorry to be
blunt, but it needs work if you want it to actually be useful to the
reader.

I started out noting corrections but gave up quickly. Here's as far as
my patience lasted:

- abstract: s/who wishing/wishing/
- s1: s/of IPv6/of IPv6,/
- s2: s/in wide range/in a wide range/
- s2: /networks, two notable/networks. Two notable/
- s2: analogies can be drawn irrespective of the presence or
  absence of a standard, and analogies aren't for reference,
  they are explanatory - the sentence doesn't make sense as-is.
- s2: s/Reader interested/The reader interested/

That was too many already in just a couple of paragraphs so I
stopped, but I really wish folks (authors, WG chairs, shepherds) would
try fix this kind of thing and not force the RFC editor to fix it, in
the process making all reviewers beforehand wade through hard-to-read
text like this. We don't need high class literature, but this kind of
thing makes reviewing a good bit harder.

[Ballot comment]
I have a few comments/questions on this draft, all of which are non-blocking.

1. There are a bunch of linguistic/editorial issues that I will send along later.

2. In bullet #3 of section 2, the second part talks about getting configuration information or options.  Is this information obtained via Stateful DHCPv6, Stateless DHCPv6, or a combination of the two?

3. I cannot cleanly parse the first sentence of bullet #4 in section 2.

4. Does the last paragraph of section 2 really refer to a DHCPv6 *redundancy* protocol being published?

5. Section 2.2 says that end-hosts will not use DHCP prefix delegation.  Do you have considerations to offer for when they do make such requests?

6. This question may be due to a hole in my knowledge of DHCPv6, but iss there really any difference in the two scenarios described in sections 4.1 and 4.2, other than a possible difference in the prefix length?

7. In section 5, bullet #1 discusses the need for each DHCPv6 server to use the same allocation algorithm to ensure that each IPv6 address is only allocated to a single client.  Does this require every DHCPv6 server to see all requests?  If so, would that be feasible in the two target deployment scenarios?

IANA Last Call Comment:

IANA has reviewed draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt, which is currently in Last Call, and has the following comments:

We understand this document does not require any IANA actions.

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:  (DHCPv6 Redundancy Deployment Considerations) to Best Current Practice





The IESG has received a request from the Dynamic Host Configuration WG

(dhc) to consider the following document:

- 'DHCPv6 Redundancy Deployment Considerations'

  as a Best Current

Practice



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 2012-03-30. 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 documents some deployment considerations for those who

  wishing to use DHCPv6 to support their deployment of IPv6.

  Specifically, providing semi-redundant DHCPv6 services is discussed

  in this document.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-redundancy-consider/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-redundancy-consider/ballot/





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 document shepherd. 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

       
The document has been reviewed by quite a few members of the working group, and is reasonably mature. The document has not been reviewed by other working groups--it is very specific to DHCP.

  (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 is an informational document about DHCP operations, so I don't think there's much need for additional review.

  (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 don't have any concerns about the document.  No IPR disclosures have been made.

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

The document had strong support at the last meeting, and passed WGLC with strong support.  More than just the usual suspects supported it, so I think it's got good support.

  (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 haven't heard any objections raised.

  (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 draft passes idnits without any issues.

  (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 doc has been split. There is an informative reference to a document that is still in progress and has not yet been adopted by the working group, but no normative references to unpublished documents.

  (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?
There are no IANA requirements imposed by this document.

  (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?
       
No such language exists in the text.

  (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 documents deployment scenarios for installing redundant
stateful DHCPv6 servers so as to provide fault tolerance.


    Working Group Summary

This document received a thorough review by the WG, and had broad support.

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

This isn't a protocol specification, although as far as I know it is
based on operational experience.