Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre

From: Miika Komu <[email-masked]>
Date: Mon, 07 Sep 2009 17:24:22 +0300

Miika Komu wrote:

Hi,

> Miika Komu wrote:
> 
> Hi,
> 
> a new preversion is here:
> 
> http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-09-pre2.txt
> 
> it includes the future proofing changes in the sockaddr_hip structure in 
> section 4.1. I also wrote the ship_len explicitly to the structure since 
> we were discussing on size issues.

sorry for the delay, we have been discussing this offline with Jeff, 
Stefan, Andrew and Thomas. IMHO, I think the extension fields to the 
existing sockaddr_hip structure do not bring much easier upgrade 
benefits when you think about how they would be used in practice. So, I 
think sockaddr_hip2 structure and a new flag for getaddrinfo() seems 
like a better future proofing approach. Below is my attempt to recap the 
discussion.

I am going to remove the extra fields unless anyone finds a convincing 
story why having some extra fields in the structure is beneficial for 
future proofing of HITs. I'd like to post a new final version by the end 
of this week.

<snip>
Miika: seems to me that sockaddr_hip with some extra fields gives the 
following advantages:

* always fixed memory size due to maximum size (struct sockaddr_hip
my_hip; works)
* somewhat easier upgrade of the software to use longer HITs
* < more here? >

At the same time it is somewhat disappointing in the following things:

* transparent migration from shorter to longer HITs
* interoperability (memcmp etc) between shorter and longer HITs
* logging and storing in ACLs

There's also some uncertainty factors that need to be considered:

* do we really need longer HITs in the future (elliptic curves)
* getaddrinfo() is already becoming antique

So, is extending the existing sockaddr_hip structure worth the extra
complexity? Or should we just suggest sockaddr_hip2 structure and an
extra flag for the resolver as the future proofing approach?

</snip>

---

From: Miika Komu <[email-masked]>
Date: Tue, 08 Sep 2009 12:20:47 +0300

Miika Komu wrote:

Hi,

a new preversion:

http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-09-pre3.txt

Changes:

* changed future proofing approach 4.1 and 7 as discussed below
* hip_is_hit() operates now on hip_hit_t rather than sockaddr_hip based 
on the changes on future proofing approach

Question:

Should the wildcards be allocated by IANA?

Comments are welcome, thanks!

>> it includes the future proofing changes in the sockaddr_hip structure 
>> in section 4.1. I also wrote the ship_len explicitly to the structure 
>> since we were discussing on size issues.
>

---

From: Miika Komu <[email-masked]>
Date: Thu, 10 Sep 2009 16:50:29 +0300

Miika Komu wrote:

Hi,

I posted the final 09 version:

http://tools.ietf.org/html/draft-ietf-hip-native-api-09

I'd hope we could put it to the last call.

Thanks for Stefan, Jeff, Thomas and Andrew for their comments on this 
version!

>> benefits when you think about how they would be used in practice. So, 
>> I think sockaddr_hip2 structure and a new flag for getaddrinfo() seems 
>> like a better future proofing approach. Below is my attempt to recap 
>> the discussion.
>>
>> future proofing of HITs. I'd like to post a new final version by the 
>> end of this week.
>>
>> <snip>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec