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

kkinnear <kkinnear@cisco.com> Wed, 01 February 2017 22:41 UTC

Return-Path: <kkinnear@cisco.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC7A1295CB for <gen-art@ietfa.amsl.com>; Wed, 1 Feb 2017 14:41:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.72
X-Spam-Level:
X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yml5y1OFHuln for <gen-art@ietfa.amsl.com>; Wed, 1 Feb 2017 14:41:25 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156D912953B for <gen-art@ietf.org>; Wed, 1 Feb 2017 14:41:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4768; q=dns/txt; s=iport; t=1485988884; x=1487198484; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=bbfAN/qYEkkHPK1uOGrZdkq088k174735XqZVxgCTqA=; b=XRZTzoZf/sJqeV2+rUen/I0PIXluPsD8Zv29SYpsVyh3MJYsluDUErLy gdyFjYsk4/OpLUvOXUgLo2t5WaDaWgPF90bAiwkUsJtMC3NNTlv+kGQQi 6NOv51WjexCnTg9Iaw1JkXnJ7Cbo1gf/VBMvfXL5sLGUK2hAtPfS9REZJ 8=;
X-IronPort-AV: E=Sophos;i="5.33,322,1477958400"; d="scan'208";a="201320222"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Feb 2017 22:41:24 +0000
Received: from bxb-kkinnear-8814.cisco.com (bxb-kkinnear-8814.cisco.com [10.98.10.245]) (authenticated bits=0) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v11MfNZJ015833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Feb 2017 22:41:24 GMT
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: kkinnear <kkinnear@cisco.com>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFD8F92@ESESSMB209.ericsson.se>
Date: Wed, 01 Feb 2017 17:41:23 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <F5C2B9B7-F35D-4E92-829E-05100DDFBDA5@cisco.com>
References: <7594FB04B1934943A5C02806D1A2204B4BFD8F92@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.3124)
X-Authenticated-User: kkinnear@cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/aLSrlBN3H4yT-HwWL9uio2CiTMM>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-dhc-dhcpv6-failover-protocol.all@tools.ietf.org" <draft-ietf-dhc-dhcpv6-failover-protocol.all@tools.ietf.org>, Kim Kinnear <kkinnear@cisco.com>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dhcpv6-failover-protocol-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Feb 2017 22:41:26 -0000

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 <christer.holmberg@ericsson.com> wrote:
> 
> 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.

	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 in the Abstract, but I think there should also be something in the Introduction, before jumping into the solution.

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


	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