Subject: [Gen-art] Gen-ART review of draft-ietf-dhc-dhcpv6-failover-protocol-04

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Feb 2017 20:57:00 +0000

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document:                                      draft-ietf-dhc-dhcpv6-failover-protocol-04.txt

Reviewer:                                        Christer Holmberg

Review Date:                                  01.02.2017

IETF LC End Date:                          19.01.2017

IESG Telechat date: (if known)    02.02.2017

Summary:                                       The document is almost ready for publication, but there are some editorial nits that I'd like the authors to address.

Major issues:                                 None

Minor issues:                                 None

Nits/editorial comments:

INTRODUCTION:

Q1:        In the first sentence of the Introduction, I suggest to say:

"The failover protocol defined in this document provides..."

Otherwise it's a little unclear what failover protocol you are talking about.

Q2:        In the Introduction, before the first sentence, shouldn't there be some background text, including some information about the problem that the document solves. I know there is something in the Abstract, but I think there should also be something in the Introduction, before jumping into the solution.

Q3:        In the Introduction, I suggest adding a reference to the first occurrences of "DHCP service" and "DHCP server".

Q4:        In the Introduction, you switch between "This protocol" and "The failover protocol". Please use consistent terminology. This applies to the document in general.

SECTION 4:

Q5:        In the Abstract and Introduction it is said that DHCPv6 does not provide server redundancy. Then section 4 talks about failover concepts and mechanism.

Are those concepts something used for DHCPv6 today, but for some reason do not fulfil the failover protocol requirements?

OR, are these general concepts that will be supported by implementing the failover protocol?

I think it would be good to have an introduction statement clarifying that.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 1 Feb 2017 22:36:25 +0100

Thanks for your review, Christer!

Authors, can you make a note of the editorials?

Jari

On 01 Feb 2017, at 21:57, Christer Holmberg <[email-masked]> wrote:

> Summary:                                       The document is almost ready for publication, but there are some editorial nits that I’d like the authors to address.
> 
> Major issues:                                 None
> 
> Minor issues:                                 None
> 
> Nits/editorial comments:
> 
> INTRODUCTION:
> 
> “The failover protocol defined in this document provides…”
> 
> Otherwise it’s a little unclear what failover protocol you are talking about.
> 
> Q2:        In the Introduction, before the first sentence, shouldn’t there be some background text, including some information about the problem that the document solves. I know there is something in the Abstract, but I think there should also be something in the Introduction, before jumping into the solution.
> 
> Q3:        In the Introduction, I suggest adding a reference to the first occurrences of “DHCP service” and “DHCP server”.
> 
> Q4:        In the Introduction, you switch between “This protocol” and “The failover protocol”. Please use consistent terminology. This applies to the document in general.
> 
> SECTION 4:
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: kkinnear <[email-masked]>
Date: Wed, 1 Feb 2017 17:41:23 -0500

Christer,

Thanks for your review.

I will make all of the changes that you suggest, and have offered
details (indented) below.  Note that while I'm willing to make the
change you have discussed in Q3, I don't actually understand what you
would like us to do.

More below...

> On Feb 1, 2017, at 3:57 PM, Christer Holmberg <[email-masked]> wrote:
> 

	Sure, good idea.  See Q2, immediately below.
> Q2:        In the Introduction, before the first sentence, shouldn’t there be some background text, including some information about the problem that the document solves. I know there is something…

	I've been chastised for repeating the abstract in the
	introduction, so I was trying to not do that.  How about we
	start the introduction with:

	"The DHCPv6 protocol [RFC3315] does not provide for server
	redundancy.  The failover protocol defined in this document
	provides a means for cooperating DHCP servers to work together
	to provide a DHCP service with availability that is increased
	beyond that which could be provided by a single DHCP server
	operating alone. ..."

	Note that the last sentence of the Introduction already points
	to the DHCPv6 failover requirements RFC, which has a lot more
	to say about this.

> Q3:        In the Introduction, I suggest adding a reference to the first occurrences of “DHCP service” and “DHCP server”.

	While I'm more than happy to do this, I don't actually know
	what you would like me to reference?  We haven't defined
	either "DHCP service" or "DHCP server" in the glossary since
	we felt they were reasonably apparent from the context of this
	document.  Are you thinking that we should reference RFC3315
	on the first occurrence of "DHCP service" and "DHCP server"?

> Q4:        In the Introduction, you switch between “This protocol” and “The failover protocol”. Please use consistent terminology. This applies to the document in general.

	Ok, we'll go with "The failover protocol" since it appears 
	more times so far.  I will make this global change when I
	next update the document.  
> I think it would be good to have an introduction statement clarifying that.

	The concepts and mechanisms discussed in Section 4 relate to
	the failover protocol, they aren't present in the regular
	RFC3315(et. al.) DHCPv6 protocol.  I will add the following to
	Section 4 to clarify that:

	"4.  Failover Concepts and Mechanisms

	The following concepts and mechanisms are necessary to the operation
	of the failover protocol, and they are not currently employed by
	the DHCPv6 protocol [RFC3315].

	4.1. Required Server Configuration

	..."

Again, thanks for the review.

Kim

---

From: kkinnear <[email-masked]>
Date: Wed, 1 Feb 2017 17:43:13 -0500

> On Feb 1, 2017, at 4:36 PM, Jari Arkko <[email-masked]> wrote:
> 

	Yes, I have agreed to make all of the changes
	suggested by Christer. 

	Thanks -- Kim

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 1 Feb 2017 22:45:09 +0000

Thanks for the review Christer. And thanks for taking care of this quickly Kim.

Regards
Suresh

> On Feb 1, 2017, at 11:43 PM, kkinnear <[email-masked]> wrote:
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Feb 2017 22:57:39 +0000

Hi,

>I will make all of the changes that you suggest, and have offered details (indented) below.  Note that while I'm willing to make the change you have discussed in Q3, I don't >actually understand what you would like us to do.
>
>More below...

INTRODUCTION:
  
>> Q2:        In the Introduction, before the first sentence, shouldn’t there be some background text, including some information 
>>about the problem that the document solves. I know there is something in the Abstract, but I think there should also be something 
>>in the Introduction, before jumping into the solution.
>

Looks very good.

I know some people don't want to repeat Abstract text in the Introduction, but I still think the Introduction should provide an introduction to the problem :)

>	on the first occurrence of "DHCP service" and "DHCP server"?

Yes.

>	next update the document.  

Sounds good.

>	the DHCPv6 protocol [RFC3315].

That's better. But, will the failover protocol provide support for those concepts? If so, please indicate it.

Thanks!
 
Regards,

Christer

---

From: kkinnear <[email-masked]>
Date: Wed, 1 Feb 2017 18:06:58 -0500

Christer,

I have deleted the issues not under discussion.

More comments, indented, below...

> On Feb 1, 2017, at 5:57 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
>> 

	Ok, I will do so in the next update.
> That's better. But, will the failover protocol provide support for those concepts? If so, please indicate it.

	How about this:

	The following concepts and mechanisms are necessary to the operation
	of the failover protocol, and they are not currently employed by
	the DHCPv6 protocol [RFC3315].  The failover protocol provides
        support for all of these concepts and mechanisms.

	..."

Thanks -- Kim

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Feb 2017 23:08:54 +0000

Hi,

You suggestions look good, and I am happy with your reply :)

Regards,

Christer

-----Original Message-----
From: kkinnear [mailto:[email-masked]] 
Sent: 02 February 2017 01:07
To: Christer Holmberg <[email-masked]>
Cc: Kim Kinnear <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Gen-ART review of draft-ietf-dhc-dhcpv6-failover-protocol-04

Christer,

	How about this:

	..."

Thanks -- Kim

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 2 Feb 2017 00:13:36 +0100

W dniu 01.02.2017 o 21:57, Christer Holmberg pisze:
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by
> the IESG for the IETF Chair.  Please treat these comments just like
> any other last call comments.
>
Hi Christer!
Thanks a lot for your review. See my responses below.
> Document:                                     
> draft-ietf-dhc-dhcpv6-failover-protocol-04.txt
>
> Summary:                                       The document is almost
> ready for publication, but there are some editorial nits that I’d like
> the authors to address.
>
>  
>
> Major issues:                                 None
>
>  
>
> Minor issues:                                 None
>
>  
>
> Nits/editorial comments:
>
>  
>
> INTRODUCTION:
>
>  
>
Sure, will update as suggested.
> Q2:        In the Introduction, before the first sentence, shouldn’t
> there be some background text, including some information about the
> problem that the document solves. I know there is something in the
> Abstract, but I think there should also be something in the
> Introduction, before jumping into the solution.
>
There's a whole RFC about it: RFC7031. It was intended as a gentle
introduction to the DHCP failover problem: what is in and outside of
scope, when failover is useful and when it may not be the best tool. The
DHC WG decided to split it into separate document, because there are
lots of things to explain and the core document is already obscenely
large. This RFC is clearly linked at the end of Introduction section.
Perhaps it would be more useful to move this reference to the front and
add a sentence or two of explanation? How about this text added as a
first paragraph?

This document defines a DHCPv6 failover protocol, which is a mechanism
for running two DHCPv6 servers with the capability for either server to
take over clients' leases in case of server failure or network
partition. For a general overview of the DHCPv6 failover problems, use
cases, benefits and shortcomings, see RFC7031."
>
>  
>
> Q3:        In the Introduction, I suggest adding a reference to the
> first occurrences of “DHCP service” and “DHCP server”.
>
DHCP service is not a formal term. It was intended as a general
description of the DHCP server availability. How about we replace "or
provide a DHCP service" with "to provide service to DHCP clients"?
>
>  
>
> Q4:        In the Introduction, you switch between “This protocol” and
> “The failover protocol”. Please use consistent terminology. This
> applies to the document in general.
>
There are 8 instances of "this protocol" and 20 of "the failover
protocol". We will go with the latter, ok?
>
>  
>
> SECTION 4:
>
>  
>
> Q5:        In the Abstract and Introduction it is said that DHCPv6
> does not provide server redundancy. Then section 4 talks about
> failover concepts and mechanism.
>
>  
>
> Are those concepts something used for DHCPv6 today, but for some
> reason do not fulfil the failover protocol requirements?
>
>  
>
These are not being used by any non-failover DHCPv6 today. There is one
implementation of this draft that uses them. Most of those mechanisms
are required by any sane failover design (e.g. any kind of failover-like
solution has to use lazy updates or it would be undeployable due to
performance), but some are specific to this particular failover design
(e.g. the allocation algorithms). Would the following text added at the
beginning of Section 4 be sufficient?

"The following section describes core concepts that are a foundation of
this failover protocol. Allocation strategies described in Section 4.2
are specific to this particular failover design, while the concept of
Lazy updates (Section 4.3) and MCLT (Section 4.4) seem to be necessary
for any failover design."

Also, if you think it's useful, we can repeat a 7031 reference there,
possibly to Section 5.2 that discusses lazy updates
(update-after-response) and its alternative (update-before-response).

Thanks again for your review,
Tomek

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Feb 2017 23:30:17 +0000

Hi,

INTRODUCTION:

>> Q2:        In the Introduction, before the first sentence, shouldn't
>There's a whole RFC about it: RFC7031. It was intended as a gentle introduction to the DHCP failover problem: what is in and outside of scope, when failover is useful and >when it may not be the best tool. The DHC WG decided to split it into separate document, because there are lots of things to explain and the core document is already >obscenely large. This RFC is clearly linked at the end of Introduction section.
>Perhaps it would be more useful to move this reference to the front and add a sentence or two of explanation? How about this text added as a first paragraph?
>
>This document defines a DHCPv6 failover protocol, which is a mechanism for running two DHCPv6 servers with the capability for either server to take over clients' leases in >case of server failure or network partition. For a general overview of the DHCPv6 failover problems, use cases, benefits and shortcomings, see RFC7031."

Works for me.

>> first occurrences of "DHCP service" and "DHCP server".
>>
>DHCP service is not a formal term. It was intended as a general description of the DHCP server availability. How about we replace "or provide a DHCP service" with "to >provide service to DHCP clients"?

Works for me.

>> Q4:        In the Introduction, you switch between "This protocol" and
>> "The failover protocol". Please use consistent terminology. This 
> There are 8 instances of "this protocol" and 20 of "the failover protocol". We will go with the latter, ok?

I can live with both, but the latter would be my preference too.

SECTION 4:

> These are not being used by any non-failover DHCPv6 today. There is one implementation of this draft that uses them. Most of those mechanisms are required by any sane >failover design (e.g. any kind of failover-like solution has to use lazy updates or it would be undeployable due to performance), but some are specific to this particular >failover design (e.g. the allocation algorithms). Would the following text added at the beginning of Section 4 be sufficient?
>
>"The following section describes core concepts that are a foundation of this failover protocol. Allocation strategies described in Section 4.2 are specific to this particular >failover design, while the concept of Lazy updates (Section 4.3) and MCLT (Section 4.4) seem to be necessary for any failover design."

Works for me.

>Also, if you think it's useful, we can repeat a 7031 reference there, possibly to Section 5.2 that discusses lazy updates

I think that would be useful.

Note that Kim had slightly different suggestions on how to address the issues. I am fine those, so I'll leave it up to you to decide which ones to adopt :)

Thanks!

Regards,

Christer