Re: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!

Krzysztof Gierłowski <krzysztof.gierlowski@pg.gda.pl> Wed, 04 September 2013 10:56 UTC

Return-Path: <krzysztof.gierlowski@pg.gda.pl>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D5121E80B0 for <dhcwg@ietfa.amsl.com>; Wed, 4 Sep 2013 03:56:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.645
X-Spam-Level: **
X-Spam-Status: No, score=2.645 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYjepNlK8-GF for <dhcwg@ietfa.amsl.com>; Wed, 4 Sep 2013 03:56:00 -0700 (PDT)
Received: from sunrise.pg.gda.pl (sunrise.pg.gda.pl [153.19.40.231]) by ietfa.amsl.com (Postfix) with ESMTP id E841D11E819B for <dhcwg@ietf.org>; Wed, 4 Sep 2013 03:55:59 -0700 (PDT)
Received: from hydra (knot3201.eti.pg.gda.pl [153.19.53.201]) (authenticated bits=0) by sunrise.pg.gda.pl (8.14.3/8.14.3) with ESMTP id r84AttUG018114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <dhcwg@ietf.org>; Wed, 4 Sep 2013 12:55:57 +0200 (CEST)
From: =?iso-8859-2?Q?Krzysztof_Gier=B3owski?= <krzysztof.gierlowski@pg.gda.pl>
To: <dhcwg@ietf.org>
References:
In-Reply-To:
Date: Wed, 4 Sep 2013 12:53:08 +0200
Message-ID: <000001cea95c$f6759730$e360c590$@pg.gda.pl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: Ac6pW6iwwQuqOx0SRRibolSpor12AAAAQ/pg
Content-Language: pl
X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on 153.19.62.99
X-Virus-Status: Clean
Subject: Re: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2013 10:56:06 -0000

Hello,
I am a researcher from Gdansk University of Technology where we are highly
interested in current IPv6-related developments.
Reading draft-ietf-dhc-dhcpv6-failover-design-03 and following associated
comments, a procedure for initiating communication between primary and
secondary server (5.1) caught my attention.
It would seem to me, that approach in which secondary server connects to
primary would provide easier management, by allowing administrator to
activate/deactivate/change (for example within a predefined group) secondary
server without the need to specifically reconfigure and reinitialize the
primary one. I am aware that the proposed approach is based on failover
draft for DHCPv4, but what is the rationale for such choice?

Also some minor editorial comments:
4.1 - the statement "In each state a server may be either responsive (.) or
unresponsive (.)." seem to suggest that these two possibilities are valid
for each given state server can be in. "Depending on its current state a
server may be either responsive (.) or unresponsive (.)"?
6 - "This allocation algorithm assumes that available resources are split
between primary and secondary servers as well." -> "This allocation
algorithm also assumes that available resources are split between primary
and secondary servers."

Best regards,
Krzysztof Gierlowski