Re: [Hipsec] RFC5206-bis status

Miika Komu <> Sun, 17 April 2016 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E12F912D140 for <>; Sun, 17 Apr 2016 13:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qi7XYagBtoDo for <>; Sun, 17 Apr 2016 13:35:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 10D3412D130 for <>; Sun, 17 Apr 2016 13:35:19 -0700 (PDT)
X-AuditID: c1b4fb3a-f795d6d000004243-c3-5713f38673cb
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 61.EF.16963.683F3175; Sun, 17 Apr 2016 22:35:18 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Sun, 17 Apr 2016 22:35:17 +0200
References: <>
From: Miika Komu <>
Organization: Ericsson AB
Message-ID: <>
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: <>
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: <>
Subject: Re: [Hipsec] RFC5206-bis status
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 17 Apr 2016 20:35:22 -0000


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?
> There are six open issues on RFC5206-bis, listed here:
> One of them (#12) probably should be closed now based on the draft
> version 09 published in July.


> 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.