Re: [Hipsec] Mirja Kühlewind's No Objection on draft-ietf-hip-rfc5206-bis-13: (with COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Fri, 16 September 2016 10:38 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCF912B11B for <hipsec@ietfa.amsl.com>; Fri, 16 Sep 2016 03:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.41
X-Spam-Level:
X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 25dWgrSFYGHt for <hipsec@ietfa.amsl.com>; Fri, 16 Sep 2016 03:38:02 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7A612B009 for <hipsec@ietf.org>; Fri, 16 Sep 2016 03:38:01 -0700 (PDT)
Received: (qmail 7920 invoked from network); 16 Sep 2016 12:31:19 +0200
Received: from p5dec28a4.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.40.164) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Sep 2016 12:31:19 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <alpine.LRH.2.01.1609152230550.24569@hymn02.u.washington.edu>
Date: Fri, 16 Sep 2016 12:31:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5EAC8C66-94CF-419F-8D65-B4D0335801F8@kuehlewind.net>
References: <alpine.LRH.2.01.1609152230550.24569@hymn02.u.washington.edu>
To: Tom Henderson <tomhend@u.washington.edu>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/R88oyEwFvrhGzmDOdYq5Q5Gctec>
Cc: hipsec@ietf.org, hip-chairs@ietf.org, iesg@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org
Subject: Re: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-hip-rfc5206-bis-13=3A_=28with_COMMENT=29?=
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Sep 2016 10:38:03 -0000

Okay.

> Am 16.09.2016 um 07:30 schrieb Tom Henderson <tomhend@u.washington.edu>:
> 
> Mirja,
> Inline below (the points still being discussed)....
> 
> On Thu, 15 Sep 2016, Mirja Kühlewind wrote:
> 
>>>> 3) section 4: Can you give any hints how large the lifetime typically
>>>> should be? Can only the original address have an unbounded lifetime (see
>>>> section 5) or can I also set the lifetime value in a certain way to
>>>> declare the lifetime of this address of unbounded?
>>> Effectively unbounded lifetimes can be set by setting the 32-bit field to the maximum value.
>> 
>> Okay that's not spelled out in the doc.
>> 
>>> In practice, I don't know of any guidance to offer, other than perhaps aligning it with lifetimes of the addresses such as DHCP leased addresses.
>> 
>> That means like useful guidance.
>>> I guess that we could add a statement that an 'effectively unbounded' lifetime can be set by setting the field to the maximum (unsigned) value.
>> 
>> Would you then also need to talk about risks when doing so...?
> 
> I can make the above changes about lifetimes, but for the last one, I am not sure that there are any risks to it-- I won't mention risks unless someone in the list has ideas about any.
> 
> 
>>>> 3) I believe reading would be easier for me if section 4 would have been
>>>> first but not sure...
>>> I'm not sure about reordering sections without more specific change proposals.
>> 
>> Or you could add a paragraph in the intro explaining where to find what.
> 
> OK
> 
>> 
>>>> 4) This docuemnt states several times that mutlihoming is out of scope
>>>> and only the handover case is described. I think it would be better to
>>>> state this clearly at the very beginning and remove the other cases (I
>>>> believe these are anyway kind of left-overs from the previous document.)
>>> Can you point to what you would like to have removed or changed?  Early on, we moved most of this material to the other draft, and in scanning it again just now, I am not sure what more to take out or rephrase.  It is hard to completely avoid the topic of having multiple addresses in this draft, particularly since we are defining the LOCATOR_SET parameter that is used in the multihoming specification.
>> Maybe just grab from the word multihoming and double-check if you really need it there. For me it somtimes showed up at place there I thought it's actually not needed to mentioned that again.
>> But that's nothing big...
> 
> I searched for the word just now and wasn't inclined to remove any of those remaining references, so I think I'll leave it for now unless someone proposes a specific change.
> 
> - Tom