70 likes | 181 Views
Miika Komu < miika@iki.fi > Andrei Gurtov gurtov@cs.helsinki.fi. Native HIP API. Current Status. No major changes Some minor corrections pending Future work planned We need some feedback before continuing. Feedback Summary. Consider supporting also other addresses than IP in the API
E N D
Miika Komu <miika@iki.fi> Andrei Gurtov gurtov@cs.helsinki.fi Native HIP API
Current Status • No major changes • Some minor corrections pending • Future work planned • We need some feedback before continuing
Feedback Summary • Consider supporting also other addresses than IP in the API • The API architecture and Application Specified Host Identities seem to be interesting • Is the ED actually useful? Just use HITs? • This should not be in the RG (move to WG?)
How to Proceed from Here? • Do you think that this work is useful? • Plain engineering: move to WG? • Some research ideas on the next slide… • Which of the ideas on the following slide do you find useful to proceed on? Feedback, please
How to Proceed: New Ideas • Opportunistic HIP may be difficult to implement using a standard sockets API • The EDs of the Native HIP API can make it easier • Alternatively, use Berkeley OCALA architecture (caveat: dependency to i3?) • Consider integration to Session or Service Layer identifiers? • Crazy idea: communicate EDs on-the-wire to support semantics similar to sctp_peeloff()?
References • draft-mkomu-hip-native-api-00.txt • Applying a Cryptographic Namespace to Applications [Komu et al] • Application Programming Interfaces for Host Identity Protocol [Komu] • draft-henderson-hip-applications-01
Questions / Feedback Miika Komu <miika@iki.fi> or <infrahip@hiit.fi>