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

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

> From: "Wes Hardaker" <wjhns1 at hardakers.net>
> To: "Donati Andrew-MGIA0477" <adonati at motorola.com>
> Cc: <isms at ietf.org>
> Sent: Friday, July 03, 2009 10:06 AM
> Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate touse
...
> 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 :-)
...

I'm a bit confused.  Re-reading the thread, it looks like the text under
discussion is this:

-------------
tlstmParamsRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The status of this conceptual row.  This object may be used
        to create or remove rows from this table.

        To create a row in this table, a manager must
        set this object to either createAndGo(4) or
        createAndWait(5).

        Until instances of all corresponding columns are
        appropriately configured, the value of the
        corresponding instance of the tlstmParamsRowStatus
        column is 'notReady'.

        In particular, a newly created row cannot be made
        active until the corresponding
        tlstmParamsClientHashType,
        and tlstmParamsClientHashValue have both been set.

        The row may not be made active(1) if the
        tlstmParamsClientHashValue object is not of a length suitable
        for use with the corresponding tlstmParamsClientHashType.

        The following objects may not be modified while the
        value of this object is active(1):
            - tlstmParamsClientHashType
            - tlstmParamsClientHashValue
        An attempt to set these objects while the value of
        tlstmParamsRowStatus is active(1) will result in
        an inconsistentValue error.

        The value of this object has no effect on whether
        other objects in this conceptual row can be modified.

        If this row is deleted it has no effect on the corresponding
        row in the tlstmParamsTable.

 If the corresponding row in the tlstmParamsTable is deleted
 then this row must be automatically removed."
--------

If so, I think the proposed text has a problem.
Most importantly, since tlstmParamsRowStatus is part of
the tlstmParamsTable, the last two sentences of the DESCRIPTION
make no sense.

The real question is whether there should be any "fate sharing"
between it and the snmpTargetParamsTable.  I'd strongly recommend
that there be *no* coupling whatsoever.  This would simplify
implementation, testing, provisioning, and operational use.  I
see no benefits from "fate sharing", and lots of disadvantages.

Randy