[anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt

[mcr at sandelman.ca (Michael Richardson)]

Caitlin Bestler wrote:
> This draft makes many assumptions about the execution environment.
> Far too many, in my opinion, for anything beyond an informational RFC.
> 
> In particular the requirements that the objects be "opaque" and
> non-copyable are problematic in embedded and/or virtualized
> environments.

   You are mis-understanding the requirements.
   The requirements are there in order to free the API developer to be able 
to  do what make sense in a multitude of environments.  An object is said to 
be opaque to make sure that the *APPLICATION* does not depend upon the 
ability to look into the object in order to function.
   An object is said to be non-copyable, in order that you do not assume that
you can copy it trivially by doing a structure copy.

   In both cases, if your choose to implement the accessor functions as 
#define macros, and the copy function as *foostruct=*barstruct, that's just fine.

   However, in a Posix environment, I can not assume that

> Not allowing the client to copy the object to another location in the
> same process, or to an entirely different process is quite reasonable.

   I don't think it says that.
   What it says is that if you have a handle in one process, that it will not 
be transparently valid in another process.   If you want to move the object 
to another process, then you have to have cooperation of the object. It's 
just like a file handle or a socket.

> But can the process itself be migrated? Are these objects expected
> to work after a Unix style fork? What if the entire IP host is
> migrated to another physical machine?

   Do sockets work after you do these things?

> What needs to be stated is what expectations there are about
> this memory. Are normal operations on the entire memory space,
> such as swap-out/swap-in and virtualization migration, compatible
> with these objects or not?

   We were also very specific in the requirements document (I think you 
didn't read it), that we never let the application processes see keying 
material. They have no business knowing about that.