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

["Ahrenholz, Jeffrey M" <jeffrey.m.ahrenholz at boeing.com>]

> > Based on this discussion, it appears that the best way for future  
> > proofing is to include a flag for getaddrinfo() in the hints  
> > arguments that will result in sockaddr_hip_long structures instead  
> > of sockaddr_hip. This way, applications get exactly what they want  
> > and can store the HITs easily in their ACLs. I'd also remove the  
> > extra space reserved space because it seems that it's not very  
> > usable for future proofing as it is now.
> >
> > Jeff, how do you feel about this or do you have a better suggestion?
> 
> I think you'd be better to define more than a flag... an 
> explicit size  
> (or enum) would be better.  That way if some other odd size 
> becomes a  
> requirement later, it's not such an annoyance to fit in to the API

yes, a size or flag makes sense; looks like struct addrinfo already has
"size_t ai_addrlen;" but that field must be zero when used as hints
(looking at getaddrinfo(3) man)

other calls such as connect(), bind(), and sendto() already take a
"socklen_t addrlen" argument

-Jeff