Hi Pekka, > Well, I do not exactly /want/ to change the APIs or tranport > protocols. I only *anticipate* that due to mobility, > multi-address multi-homing, and intermittend connectivity, we > end up making changes to the transport protocols, anyway. I > also anticipate that if we take the id/loc separation to its > logical end, we will create a new set of APIs that will > slowly replace the current socket APIs in new applications.
I don't believe we need new base APIs, but just extensions to the new 3493 APIs for getaddrinfo, getaddrinfo, and more importantly asynchronous event notification. Getaddrinfo and getnameinfo can have flags to parse the future if we do figure out EID an Locator separation and I will look at that as engineer/architect/implementer once I personally believe a real proposal within the IETF and implementer community for consensus exists, which is not the case today. What we will need for much of the paradigm and architecture discussions I am hearing is a need to notify applications in an asynchronous manner of changes (e.g. state of network, new addresses, new security parameters) in the IP stack. What will be required that is new, is an application asynchronous listener mechanism added to applications (similar to how POSIX Pthreads can be integrated into an application module) for the asynchronous network kernel events for multiple paradigms and architecture changes under discussion, in the case where the IP stack selects variations for communications like new addresses or security parameters. I also am thinking this would be better done as an IEEE exercise for these APIs rather than IETF too. But, first order of business is get consensus on the perceived paradigm and architecture changes for any new features for IPv6 to be implemented. API debates at this point I think are premature, other than making sure new paradigms or architecture does not break existing implementations in the market, the latter being a better use of WG time is my 2 cents. As a note I am reviewing Dave Crocker's MAST proposal and analysis in technical depth, and will respond in the near future on MULTI6 list (could be three weeks given my work load), and this statement is not a support of MAST solution, but that I will do technical investigation as one member in our IETF community. Lastly, I believe we need to view the identifier and locator as unary operation. What I mean by that, is identification and location must be in an IPv6 address (I don't care about IPv4 anymore for this discussion). This does not preclude rendezvous points or processes to determine that address at all in solutions, as a note. /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
