Re: [Isms] (D)TLS question (#1): selecting a client certificate to use
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Isms] (D)TLS question (#1): selecting a client certificate to use



Hi Wes,

I saw the opinions welcome clause at the end and decided to jump in.  :)

It seems to me that an entry can exist in the snmpTargetParamsTable that doesn't have a corresponding tlstmParamsEntry, but not vice verse.  So, basically, option 2 below is the best choice.  Additionally, a deletion of the snmpTargetParamsTable entry should cause a deletion of the 1..N entries in tlstmParamsEntry that these rows are tied to.

This brings up my next question.  I haven't seen the new table structure since you decided not to augment the params table.  I would assume that with your current thoughts on the tlstmTargetParamsTable, you would include a column that references the snmpTargetParamsName?  This in turn would change your rowStatus verbiage to not allow the row to become active until the certificate info is in place and the snmpTargetParamsName exists and is filled in.

My 2 cents.

Thanks.

Ray

-----Original Message-----
From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On Behalf Of Wes Hardaker
Sent: Friday, July 03, 2009 12:07 PM
To: Donati Andrew-MGIA0477
Cc: isms at ietf.org
Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate to use

>>>>> On Thu, 2 Jul 2009 15:12:50 -0400, "Donati Andrew-MGIA0477" <adonati at motorola.com> said:

DA> If the corresponding row in the tlstmParamsTable is deleted and the
DA> row is automatically removed, I am assuming that setting
DA> tlstmParamsRowStatus to createAndGo(4) or createAndWait(5) returns
DA> an error if the corresponding row in the tlstmParamsTable is not
DA> present.

Good point.  The options are:

1) let the row be created in anticipation of another being created later
   in the snmpTargetPararms table.
2) prohibit it with inconsistentValue, which I agree is the right
   choice.

When deleting, I think it makes sense to auto-remove the column from the
tlstmParamsTable table since it's unlikely you'd want it there in the
future.  But, I don't necessarily think that's true for creation and I
don't see us getting a huge amount of benefit from disallowing the
creation of a row in the tlstmParamsTable table when the row in the
snmpTargetParams doesn't exist.  But you're right, that doesn't feel
consistent either.

Opinions welcome :-)
--
Wes Hardaker
Cobham Analytic Solutions
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.