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