Re: [Hipsec] RFC5206-bis status

Miika Komu <miika.komu@ericsson.com> Sun, 17 April 2016 20:35 UTC

Return-Path: <miika.komu@ericsson.com>
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 E12F912D140 for <hipsec@ietfa.amsl.com>; Sun, 17 Apr 2016 13:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 qi7XYagBtoDo for <hipsec@ietfa.amsl.com>; Sun, 17 Apr 2016 13:35:20 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D3412D130 for <hipsec@ietf.org>; Sun, 17 Apr 2016 13:35:19 -0700 (PDT)
X-AuditID: c1b4fb3a-f795d6d000004243-c3-5713f38673cb
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 61.EF.16963.683F3175; Sun, 17 Apr 2016 22:35:18 +0200 (CEST)
Received: from [153.88.190.38] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.248.2; Sun, 17 Apr 2016 22:35:17 +0200
To: <hipsec@ietf.org>
References: <alpine.LRH.2.01.1511222305420.23520@hymn03.u.washington.edu>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <5713F385.1000806@ericsson.com>
Date: Sun, 17 Apr 2016 23:35:17 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <alpine.LRH.2.01.1511222305420.23520@hymn03.u.washington.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080508090802020505030308"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7n27bZ+Fwg6Wb5SymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujK6XExkLLttXPLowmbGB8Z9VFyMnh4SAicS05YvZIWwxiQv3 1rOB2EICRxgl1n1S72LkArJXM0r8frkSrEhYQENi4a9eJhBbREBUYsqH08xdjBxARZ4SX2cG gYTZBLQkVt25zgxi8wtISmxo2A1m8wpoS6yZ8J4FxGYRUJX493w6I4gtKhAh8WTuSUaIGkGJ kzOfgNVwCnhJbN0xiRnkBmaBbkaJtf9usEPsUpG4eCx4AqPALCQts5CVgSSYBWwl7szdzQxh a0ssW/gayraWmPHrIBuErSgxpfshVL2pxOujHxkhbGOJZev+si1g5FjFKFqcWlycm25kpJda lJlcXJyfp5eXWrKJERj6B7f8ttrBePC54yFGAQ5GJR5ehXdC4UKsiWXFlbmHGFWA5jzasPoC oxRLXn5eqpII790PwuFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeXMi/4UJCaQnlqRmp6YWpBbB ZJk4OKUaGA1T/89J5DyY3sVuf4QxfVJTfvTWA0dW3Kl7VbSq9cHsODefmPA39VV6qlkt1+Z9 f3WTgeukT7jDifebpn1jfG4dlPyleNKO+b6rXp+80MRq6qkoXHn4oPadFfcYzJvK169ZnNrq 8sD13SqFFWddCq+2xWVJ1L6tD3GR0mJqWzDV2aAic0ryCyWW4oxEQy3mouJEANmypTGFAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/38jYt9Gm4MWwghIN0AwEjR9Y_AA>
Subject: Re: [Hipsec] RFC5206-bis status
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: Sun, 17 Apr 2016 20:35:22 -0000

Hi,

On 11/23/2015 09:05 AM, Tom Henderson wrote:
> Well, the previous message's formatting certainly wasn't what I had
> in mind, so let's try again below.
>
>
> On 11/17/2015 11:52 PM, Gonzalo Camarillo wrote:
>> Authors of the following drafts,
>>> could you please let the WG know their status and what needs to
>>> happen
>> next for each of them in order to be able to WGLC them at some
>> point in the future?
>>> https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/
>> http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/
>
> There are six open issues on RFC5206-bis, listed here:
> https://tools.ietf.org/wg/hip/trac/query?component=rfc5206-bis
>
> One of them (#12) probably should be closed now based on the draft
> version 09 published in July.

Agreed.

> One related to flow bindings (#23) probably can be left for further
> study, with no action at this time, since it hasn't been pursued for
> many years.

Ok by me.

> One (#21) suggests to include HI parameter in the UPDATE, for benefit
> of middleboxes. Any objection to adding specification text that HI
> MAY be included in UPDATE?

MAY is fine.

> One (#15) suggests to name UPDATE packets with different names such
> as UPDATE1, UPDATE2, and UPDATE3, for clarity. I wonder whether this
> can be handled editorially without requiring code point allocation.

I read the mobility draft through and I don't this is necessary.

> One (#9) suggests to make some mandatory features optional, since at
> least one implementation does not implement all mandatory features. I
> think that perhaps this will require a review of both of the open
> source implementations to see whether any should be relaxed.

I think this can be closed since mobility and multihoming drafts are 
separated now.

> One (#8) asks to allow that locator announcement may be decoupled
> from SA creation. This requires the definition of another example use
> case and extending the specification.

There hasn't been more work on this, so I suggest just closing this issue.