Subject: Re: [Hipsec] RFC5206-bis status

From: Miika Komu <[email-masked]>
Date: Sun, 17 Apr 2016 23:35:17 +0300

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.