Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dhcpv6-failover-protocol-04
Tomek Mrugalski <tomasz.mrugalski@gmail.com> Wed, 01 February 2017 23:13 UTC
Return-Path: <tomasz.mrugalski@gmail.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 AA3EB12956C for <gen-art@ietfa.amsl.com>; Wed, 1 Feb 2017 15:13:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vTFXe69LpX2h for <gen-art@ietfa.amsl.com>; Wed, 1 Feb 2017 15:13:41 -0800 (PST)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9C7129577 for <gen-art@ietf.org>; Wed, 1 Feb 2017 15:13:41 -0800 (PST)
Received: by mail-lf0-x232.google.com with SMTP id v186so236821837lfa.1 for <gen-art@ietf.org>; Wed, 01 Feb 2017 15:13:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=XcArzFBOwhsHRqf3j+9nDShzm+u4h1TD+3serpsau/o=; b=HpPY/FIE663gh9WTbOAOLzy9cyxuC7OJHOKPHEG/ulccse224eBgUsFeSjD8lHOV6L W/TV3ZkMFlgzA+k4M0XWcKSGIpOoQKWYD/esbFDPue/Gu4EPkavBU2jyW2PWNlg/gQFw noDTCD5wN+i45ZfWP/agEgg0ZHJ8Mm+DfjCSd3o3/9OoEXxf0dXHHESYRUTzGUXdRN45 qOkU60UWwX7VkUosyHniEk0aCIgOXyGszudcuQxtgZoti4iwjG+8kdrqmakTOFiKO7dK o9tFKwi2t++SJdM4DK/nGqpXez0iH7swctg2UpX6rFNPpWsa5+p9iB0JWg5ktOeo7K0k tS7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=XcArzFBOwhsHRqf3j+9nDShzm+u4h1TD+3serpsau/o=; b=Mae2bbZe+MvaBWrS5tsCt8AHV8Au1LpSGm92Qlh/LH1ET5qkPb2naZpCqiKhg87UTN ynRsPMRyQXkD3l6YvoWFnL6QNBXqlgOB899JK+3kQHOKYAZOOMm6ZRWIIWFG7+pt5LgQ Z3hFVs8Pqaf2TsK8wnwnS2krCXzO2/nNwdZtvCyrasYrgZt+E34eoyYTAMTWQoEkEb6f FObuJMkVj0iqLUBxGRuwV3IUjDO+mheqUHHsaM6V4m6D9lpagJI9Rqj8o86sn1Ahm7ic 6E3iyuV506Vk0EZb//OzpAyx7V+hO4SfqzchNOvvZKFQG2ksqqFXChm9WuWLpNwqXsg+ E8Yg==
X-Gm-Message-State: AIkVDXKC6h4ONKLu+ua+/wbC68FdYEjXUa8b6fkQ2CIlUmVkD1FupiPloiqcthpVJhlDmQ==
X-Received: by 10.25.18.102 with SMTP id h99mr1607144lfi.63.1485990819449; Wed, 01 Feb 2017 15:13:39 -0800 (PST)
Received: from [192.168.0.9] (109241207033.gdansk.vectranet.pl. [109.241.207.33]) by smtp.googlemail.com with ESMTPSA id h13sm6178397ljh.5.2017.02.01.15.13.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 15:13:38 -0800 (PST)
From: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "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>
References: <7594FB04B1934943A5C02806D1A2204B4BFD8F92@ESESSMB209.ericsson.se>
Message-ID: <8f859c36-0cf6-e2d8-7609-41c47ff1e226@gmail.com>
Date: Thu, 02 Feb 2017 00:13:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFD8F92@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/clczLrB52zFpysGdFHEjhT2FLh4>
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 23:13:44 -0000
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. > > > > 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…” > Sure, will update as suggested. > > > > 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. > 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? > > > > 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. > 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
- [Gen-art] Gen-ART review of draft-ietf-dhc-dhcpv6… Christer Holmberg
- Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dh… Jari Arkko
- Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dh… kkinnear
- Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dh… kkinnear
- Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dh… Suresh Krishnan
- Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dh… Christer Holmberg
- Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dh… kkinnear
- Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dh… Christer Holmberg
- Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dh… Tomek Mrugalski
- Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dh… Christer Holmberg