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

["Ahrenholz, Jeffrey M" <[e-mail]>]

> we got an extra review to the native API from Stefan Götz. The new 
> preversion is here:
> 
> http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-09-pre1.txt
> 
> The changes are editorial readability changes throughout the 
> document. Especially section 4.1 contains now more clarifications on 
> the fields of sockaddr_hip structure and wildcards

I read the new preversion and it looks pretty good. Only this minor editorial nits below:
Sect 3.1 Interaction with the Resolver
s/should be noticed/should be noted/

> 
> We'd like to move on with the document, but we have two questions for 
> the working group:
> 
> #1 How to future proof HITs in case we need 256 bit HITs? This is 
> important also from the view point of comparison of HITs (currently 
> draft suggests memcmp() in section 4.1. Unless, there's other 
> suggestions, I'd go for alternative (i):
> 
>      * Alternative (i): separate sockaddr_hip structure for 
> larger HITs
>      * Alternative (ii): make larger HIT structure in 
> sockaddr_hip with 
> zero padding for 128 bit HITs

yes I like alternative (i) better than (ii); maybe you could make use of ship_flags to indicate new ship_hit bit sizes in the future

note that in section 4.1.1 you also describe storing IPv6 and IPv4-mapped addresses in the ship_hit field; (should the ship_flags indicate these locator types?) in the future you would need to come up with new mappings, such as IPv4/IPv6-mapped to a 256 bit HIT.

why is HIP_HIT_ANY_TMP used for anonymous identifiers? maybe it should be named HIP_HIT_ANY_ANON or HIP_HIT_ANY_NOPUB?
 
> #2 How should the socket calls react to only-hip wildcard. Currently 
> section 4.1.1 describes:
> 
>     With the HIP_HIT_ANY address,
>     the underlying system allows only HIP-based data flows with the
>     corresponding socket.  For incoming packets, the system 
> transparently
>     discards all other traffic arriving at the socket than 
> HIP related.
>     For outgoing packets, the system returns -1 in the socket call and
>     sets errno to ECOMM when the system failed to deliver the 
> packet over
>     a HIP-based data channel.

maybe you are asking if the text is enough?
it seems fairly clear to me:
- bind() to HIP_HIT_ANY and the socket provides you only with HIP data
- connect() to HIP_HIT_ANY and you are required to specify a locator (sect 4.6) (and I assume it would establish an association w/anonymous I1)
- error under other circumstances

-Jeff