With regards to this, I should also mention that it would be best to store the identifier in the CICM::Stream class. The reason is that both create_en/decrypt_conduit and en/decrypt both need access to the identifier. The create function needs to store the conduit identifier that it obtains from the module in the CICM::Conduit parameter that it is given and the encryption/decryption functions (part of the CICM::Encrypt/Decrypt::Stream) need to use the identifier to tell the module to perform the requested encryption/decryption. Since encrypt/decrypt() cannot access the CICM::Conduit variables (CICM::Conduit is one inheritance level up from CICM::Encrypt/Decrypt::Stream), it would make sense to define the identifier in a class that both CICM::Encrypt/Decrypt::Stream can access. Both classes inherit from CICM::Stream as a base class, so that would seem to be the best choice from my point of view.
Is this still something that people are alright with? Thanks, -Girish -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, May 31, 2011 8:43 AM To: CICM Discussion List Subject: Re: [cicm] Moving Packets and Storing Identifiers (was RE:CICMQuestions) 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 _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm
