Lev (and group), I'm implementing the CICM driver here at L3. I'd support the concept of extending the API to allow vendors to store a conduit identifier as a numeric value, such as channel ID. This allows vendors to link the conduits created through the API to their own internal hardware-specific attributes for the conduits.
Regards, Steve DiMedio L-3 Communications 856-338-4204 >> 2. When create_en/decrypt_conduit is finished executing, it needs to store >> an identifier (just a number really) to identify the conduit it has created >> with the Crypto. Since both of these functions only return a status and a >> CICM::En/Decrypt::Conduit pointer, the only way to store the identifier for >> the conduit to use is to add it as a member variable to the Conduit class. >> If the variable is to be private, we would also need a simple public member >> function to access it. Is there a way to update the CICM API so that we can >> store the conduit's identifier in one of the ways I listed? > >This is an interesting suggestion. We define KeyId for key identifiers, but >we do not define a ChannelId for channel identifiers. This is because there >isn't currently a way to lookup a channel by its identifier (like there is >for keys, modules, and tokens). > >This is going to require some discussion. Normally, vendor-specific attributes >are defined by extending the CICM base object and adding those properties. >However, it seems like a common operation to store a vendor-specific >identifier in a CICM object to make it easy to reference the underlying object >later on. > >** What do people think about extending the API to allow vendors to store a > single numeric value to uniquely identify the objects to the underlying > system? > >Lev _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm
