Re: [dhcwg] Mini WG Last Call for draft-ietf-dhc-dhcpv6-failover-design-04 - Respond by September 23

"Bernie Volz (volz)" <> Tue, 24 September 2013 15:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7598A11E8146 for <>; Tue, 24 Sep 2013 08:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kT8hrAz9Pl1w for <>; Tue, 24 Sep 2013 08:13:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D7FE711E8138 for <>; Tue, 24 Sep 2013 08:13:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5260; q=dns/txt; s=iport; t=1380035616; x=1381245216; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wIen/RxirpdrguYDUgfHgWcldZZM1hbhS15xbZ1Nd3c=; b=L6X3os3OiGG39ETkvdFcqWDxg4VJJKUmMlWmDA0uPpkbXYoHA5QseJMD 3aqT2O5NY3DXWfm2LmT/rcah9KHepEhEb45NXtmLIisNLqt7x/LW7XNzO aeAiu33OiVHEe9BfMRC+kKSYHx7ktpv5OYyl1X4SXWt0I/tRfNXIaal+L A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.90,971,1371081600"; d="scan'208";a="263919519"
Received: from ([]) by with ESMTP; 24 Sep 2013 15:13:35 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r8OFDZQT019847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Sep 2013 15:13:35 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 10:13:35 -0500
From: "Bernie Volz (volz)" <>
To: " WG" <>
Thread-Topic: [dhcwg] Mini WG Last Call for draft-ietf-dhc-dhcpv6-failover-design-04 - Respond by September 23
Thread-Index: Ac6y823SWcYvbZegQjOqmH4JLXuqhQGRN1XA
Date: Tue, 24 Sep 2013 15:13:34 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Ted Lemon \(\)" <>
Subject: Re: [dhcwg] Mini WG Last Call for draft-ietf-dhc-dhcpv6-failover-design-04 - Respond by September 23
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Sep 2013 15:13:43 -0000

I have submitted this document to the IESG for publication. The datatracker has details (such as the shepherding write-up).

There were no comments during mini-WG last call. Thus not change in the status (i.e., WG consensus was reached during the 03 last call).

- Bernie

-----Original Message-----
From: [] On Behalf Of Bernie Volz (volz)
Sent: Monday, September 16, 2013 11:50 AM
To: WG
Subject: [dhcwg] Mini WG Last Call for draft-ietf-dhc-dhcpv6-failover-design-04 - Respond by September 23


As mentioned in my " [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!" email to the WG on August 26th, we will have a short 1-week "last call" to confirm that no one has any objections to this updated draft from the previous last call. While many of the changes were minor, there are a few that were more significant (see Kim's email below).

While confirming your support of the changes and the current (04) draft would be greatly appreciated, this last call is a bit different than the norm as we're just looking to assure that no one has any issues with the changes and therefore the default assumption is that they are OK. Thus, if you have concerns or issues with the changes, please indicate so!

The difference tools at are very useful to review the changes.

As few, if any documents, are ever perfect, if you do find minor issues with this draft, please let us know. 

Please respond by September 23, 2013 as we hope to send this document to the IESG later that week.

- Bernie

-----Original Message-----
From: [] On Behalf Of Kim Kinnear (kkinnear)
Sent: Friday, September 13, 2013 5:13 PM
To: WG
Cc: Kim Kinnear (kkinnear)
Subject: [dhcwg] draft-ietf-dhc-dhcpv6-failover-design-04.txt


I have just posted a new version of the DHCPv6 Failover design


There were a large number of spelling and wording errors pointed out to us by Bernie Volz in his review, which I have fixed.  Tomek added some contributors to the acknowledgments section as well.

In addition, Bernie found several more or less substantive issues that we needed to address -- in some cases clarifying the original intent of the draft, in other cases making slight changes to the draft.  I have listed these more substantive changes below.

Regards -- Kim


1. Section 2: Added "DDNS" and "Lease" to the Glossary.

2. Section 2: Included temporary (IA_TA) addresses in the resources that are handled by failover.

3. Section 5.1: Made attempting to connect to failover partner a MUST instead of a SHOULD, for both primary and secondary servers.

4. Section 6.1: Removed ordering requirement for POOLRESP message to be sent prior to BNDUPD triggered by POOLREQ.  Also removed implicit requirement (largely in figures) that POOLRESP contain number of resources allocated to partner.

5. Section 6.3: Removed MUST requirement for proportional algorithm support, and deferred algorithm assignment to resource allocation domain to subsequent documents.

6. Section 8.2: Removed entire section on Time Expression.  This will be addressed in any subsequent protocol document(s) produced. 

7. Old Section 8.7 (new 8.6): Removed requirement for every server to be able to support multiple binding update transactions in a single message.  Instead such use is now negotiated during connection establishment with the CONNECT and CONNECTACK message exchange.

8. Old Section 8.7 (new 8.6): Removed requirement to send the valid life time requested by DHCPv6 client in every BNDUPD.

9. Old Section 8.7 (new 8.6): Removed requirement to reject BNDUPD messages that contain (or do not contain) specific values.  Kept MUST directives for what must go into the BNDUPD, but allowed receiving code to do the best it can and not be required to reject any particular packet.

10. Old Section 8.7 (new 8.6): Removed explicit requirement for the following data items:
 o Remote-ID, defined in [RFC4649];
 o Relay-ID, defined in [RFC5460], section 5.4.1;  o Link-layer address [RFC6939]; and replaced it with a reference to the Relay Data option defined in RFC 5007 (the DHCPv6 Leasequery draft).  Along with this, moved RFC 5007 from the Informative to the Normative Bibliography section.

11. Section 9.7.1: Restricted ability of server to process messages in RECOVER-DONE state to RENEW message with no new resource allocations allowed even for RENEW message.

12. Section 9.11: Clarified reasoning for RESOLUTION-INTERRUPTED state, to avoid confusion.

[end of changes to -04.txt draft]

dhcwg mailing list
dhcwg mailing list