Re: [cicm] Moving Packets and Storing Identifiers (was RE:CICMQuestions)

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: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of
Steven.DiMedio@L-3Com.com
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
cicm@ietf.org
https://www.ietf.org/mailman/listinfo/cicm