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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 16 Sep 2013 15:49:49 +0000

Hello:

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 http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design 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: [email-masked] [mailto:[email-masked]] On Behalf Of Kim Kinnear (kkinnear)
Sent: Friday, September 13, 2013 5:13 PM
To: [email-masked] WG
Cc: Kim Kinnear (kkinnear)
Subject: [dhcwg] draft-ietf-dhc-dhcpv6-failover-design-04.txt

Folks,

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

	draft-ietf-dhc-dhcpv6-failover-design-04.txt

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
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 24 Sep 2013 15:13:34 +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: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Monday, September 16, 2013 11:50 AM
To: [email-masked] WG
Subject: [dhcwg] Mini WG Last Call for draft-ietf-dhc-dhcpv6-failover-design-04 - Respond by September 23

Hello:

- Bernie

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

Folks,

Regards -- Kim

---------------------