In your previous mail you wrote: BTW, I am a bit concerned about applications that need to modify their own context. How do you handle the case of an application which have several threads of execution trying to modify a single context in a contradictory way (e.g. TMP vs PUB, etc.) ? => this is an implementation problem: there are a lot of possible solutions: use a lock, use a context per thread, etc.
Thanks [EMAIL PROTECTED] PS: about RFC 3484 tuning : - the policy table (I use it for global tuning on KAME: it works well) - SR2: lower/greater scope (already noticed but not yet in the document) - SR4: home/care-of (already in the document) - SR5: outgoing interface (already noticed, not yet in the document, no proposed wording?) - SR7: temporary/public (already in the document) - SR8: longest matching prefix (IMHO it is covered by the policy table) - DR4: indirect home/care-of - DR7: native/tunnel (something is needed here, perhaps through the interface stuff, aka SR5) - DR8: lower/greater scope (same than SR2) - DR9: longest matching prefix (same than SR8) There is no equivalent in destination rules to SR7, so AI_XXXX_TMP & co are useless (this is in fact obvious :-). I remember there are concerns about the longest matching prefix on more than 64 bits, perhaps we need something here too, even I don't like the idea to fix/extend the RFC 3484 by an API (cf CGAs :-). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
