Re: [dhcwg] WGLC: draft-droms-dhc-dhcpv6-solmaxrt-update-00

Tomek Mrugalski <tomasz.mrugalski@gmail.com> Mon, 30 January 2012 22:19 UTC

Return-Path: <tomasz.mrugalski@gmail.com>
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 AA94511E80B0 for <dhcwg@ietfa.amsl.com>; Mon, 30 Jan 2012 14:19:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.932
X-Spam-Level:
X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Q4xOo71uOw2c for <dhcwg@ietfa.amsl.com>; Mon, 30 Jan 2012 14:19:08 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id CFE8B11E80AE for <dhcwg@ietf.org>; Mon, 30 Jan 2012 14:19:07 -0800 (PST)
Received: by eekc1 with SMTP id c1so1550266eek.31 for <dhcwg@ietf.org>; Mon, 30 Jan 2012 14:19:06 -0800 (PST)
Received-SPF: pass (google.com: domain of tomasz.mrugalski@gmail.com designates 10.14.51.198 as permitted sender) client-ip=10.14.51.198;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of tomasz.mrugalski@gmail.com designates 10.14.51.198 as permitted sender) smtp.mail=tomasz.mrugalski@gmail.com; dkim=pass header.i=tomasz.mrugalski@gmail.com
Received: from mr.google.com ([10.14.51.198]) by 10.14.51.198 with SMTP id b46mr281001eec.111.1327961946877 (num_hops = 1); Mon, 30 Jan 2012 14:19:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=V9i8pESzB2xvSJVIUN+yiF4PzFYEcD5Pv1hDA4DgZDg=; b=sWzpGuwZC7pwpu49KAogcF5sDkAEbvS0xhn3F7MzwOlwdzhBjKUGzXpN02ZS3P9f/W NzrXaOU/3yE5L9OzpTfaKWHmBv4iF3i+XL+x9VixF9fPN65DisYfVE5biIvRcJFP0nEk iWz+Id3/kP/5Bh8Y4g//UWsIcvwxvebTmxkGs=
Received: by 10.14.51.198 with SMTP id b46mr199290eec.111.1327961946807; Mon, 30 Jan 2012 14:19:06 -0800 (PST)
Received: from tomek.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id b49sm77971164eec.9.2012.01.30.14.19.05 (version=SSLv3 cipher=OTHER); Mon, 30 Jan 2012 14:19:06 -0800 (PST)
Message-ID: <4F271757.5040906@gmail.com>
Date: Mon, 30 Jan 2012 23:19:03 +0100
From: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: dhcwg@ietf.org
References: <EBA5E737-027B-40F2-AE1D-A48A2051F441@nominum.com><D9B5773329187548A0189ED6503667890A199E5D@XMB-RCD-101.cisco.com> <64188822-4E63-449C-B048-A4D6340252BD@gmail.com> <D9B5773329187548A0189ED6503667890A2DA469@XMB-RCD-101.cisco.com> <8E526A49-8354-4375-AA56-D2D9398848D4@gmail.com> <A015EAA5-0EAC-4B85-856B-1843E8023039@gmail.com>
In-Reply-To: <A015EAA5-0EAC-4B85-856B-1843E8023039@gmail.com>
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [dhcwg] WGLC: draft-droms-dhc-dhcpv6-solmaxrt-update-00
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: Mon, 30 Jan 2012 22:19:08 -0000

On 12-01-17 12:23, Ralph Droms wrote:
> I've posted a revised version of
> draft-droms-dhc-dhcpv6-solmaxrt-update that addresses most of
> Bernie's discussion points.  Left unaddressed are:
> 
> * putting an upper limit on the value of SOL_MAX_RT that a client
> will accept
You may also want to put lower limit as well. See below.

> * details about retaining SOL_MAX_RT across soft reboots and not
> resetting the Solicit retry timer when a SOL_MAX_RT option is
> received
> 
> Discussion encouraged...
I read -02 version and support this draft.

Couple of comments:

1. Header should explicitely metion that RFC3315 will be updated:
updates: 3315 (if approved).

2. I would put paragraphs from section 3 into separate "Client behavior"
and "Server behavior" sections. It's easier for implementors. On the
other hand, the whole combined text is less than a page, so it is not
that important.

3. What happens if server provides very low value, like SOLMAXRT = 1?
The only defense against that is currently "client MUST NOT send any
Solicit messages more frequently than allowed by the retransmission
mechanism defined in sections 17.1.2 and 14 of RFC 3315" at the end of
Section 3. Is that enough? Perhaps this could be mentioned in the
security considerations section? Maybe it would be useful to add a
statement that values below 120 seconds (old default value) MUST be
ignored by clients? If that is not desired for some reason, then at
least value of 0 should be forbidden.

5. What happens when client gets 2 advertises (one with solmaxrt and one
without) and chooses the one without solmaxrt (e.g. because it contains
addresses or have higher preference value). Clients usually discard the
second advertise completely. Is this the intended behavior here? There
is a valid case that could potentially lead to problems. When 2 servers
are running and only one provides solmaxrt option, its value	 may be
ignored.

6. What happens when there are 2 advertise responses with NoAddrsAvail,
e.g. first with maxsolrt=10000 and second maxsolrt=20000. Should client
use the just one of them? Pick the latest? Pick random? This should be
clarified. I agree that providing different values is mostly a
configuration error.

7. Can solmaxrt option appear in reconfigure message?

Tomek