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

Tom Henderson <tomhend@u.washington.edu> Fri, 16 September 2016 05:32 UTC

Return-Path: <tomhend@u.washington.edu>
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 5A94712B01F; Thu, 15 Sep 2016 22:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 VTptcrZzRBXG; Thu, 15 Sep 2016 22:32:03 -0700 (PDT)
Received: from mxout21.s.uw.edu (mxout21.s.uw.edu [140.142.32.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38EC1200DF; Thu, 15 Sep 2016 22:32:02 -0700 (PDT)
Received: from hymn02.u.washington.edu (hymn02.u.washington.edu [140.142.8.71]) by mxout21.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8G5V0an002717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2016 22:31:00 -0700
Received: from hymn02.u.washington.edu (localhost [127.0.0.1]) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8G5Uu5D029449; Thu, 15 Sep 2016 22:30:56 -0700
Received: from localhost (Unknown UID 5440@localhost) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8G5Ut4E029446; Thu, 15 Sep 2016 22:30:56 -0700
X-Auth-Received: from [73.140.18.44] by hymn02.u.washington.edu via HTTP; Thu, 15 Sep 2016 22:30:55 PDT
Date: Thu, 15 Sep 2016 22:30:55 -0700 (PDT)
From: Tom Henderson <tomhend@u.washington.edu>
To: =?ISO-8859-15?Q?Mirja_K=FChlewind?= <ietf@kuehlewind.net>
In-Reply-To: <eddfae96-c4a9-8d2d-f7c6-97607bee42cd@kuehlewind.net>
Message-ID: <alpine.LRH.2.01.1609152230550.24569@hymn02.u.washington.edu>
User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1903409400-473519141-1474003855=:24569"
X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.16.52116
X-PMX-Server: mxout21.s.uw.edu
X-Uwash-Spam: Gauge=XI, Probability=11%, Report=' TO_IN_SUBJECT 0.5, MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, MIME_TEXT_ONLY_MP_MIXED 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, IN_REP_TO 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_HIGHBIT 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0'
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/R9gYWNNXfWgm46sYmjAJZ7iXKIk>
Cc: hipsec@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org, iesg@ietf.org, hip-chairs@ietf.org
Subject: Re: [Hipsec] =?iso-8859-15?q?Mirja_K=FChlewind=27s_No_Objection_on_dr?= =?iso-8859-15?q?aft-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 05:32:04 -0000

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