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

["Donati Andrew-MGIA0477" <adonati at motorola.com>]

Wes, 

Thanks for the update.

WH> -- However, it shouldn't be an AUGMENT in the first place.  
WH> -- I've changed the next to be an identical copy of the
snmpTargetParamsTable
WH> -- index since it's not a 1:1 mapping, which rules out AUGMENT usage
in the first place. 

Agreed. ... and if the table is not an AUGMENT, it needs to have it's
own separate
RowStatus and StorageType columns.  

>AD> -- The tlstmParamsHashValue object may need to have a default value
>AD> -- defined.    
WH> -- Well, it'd have to default to "" which isn't helpful.  I think
I'd rather state that the row
WH> -- can't be made active unless the values are legally set.  There is
no sensible default value.
 
You're right. Since tlstmParamsRowStatus will now be in control of it's
own table and the new text in the description clause states that the
value of tlstmParamsClientHashValue needs to meet certain criteria
before being activated, it may not be especially helpful if there is a
DEFVAL clause present. 

WH> -- How's this for new text for the tlstmParamsRowStatus object:

It looks very good.  
If the corresponding row in the tlstmParamsTable is deleted and the row
is automatically removed, I am assuming that setting
tlstmParamsRowStatus to createAndGo(4) or createAndWait(5) returns an
error if the corresponding row in the tlstmParamsTable is not present.
If so, maybe this can be added in the description text ?  I'm not too
sure what the appropriate error code should be in this case
(inconsistentValue ? ) - I'll need to take a closer look at RFC2579.   

Andy Donati
Motorola HN&M


-----Original Message-----
From: Wes Hardaker [mailto:wjhns1 at hardakers.net] 
Sent: Thursday, July 02, 2009 1:18 PM
To: Donati Andrew-MGIA0477
Cc: Wes Hardaker; isms at ietf.org
Subject: Re: (D)TLS question (#1): selecting a client certificate to use

>>>>> On Tue, 30 Jun 2009 23:25:26 -0400, "Donati Andrew-MGIA0477"
<adonati at motorola.com> said:

Donati,

Thanks for the response and the opinion.

DA> -- Since RowStatus and StorageType are already present the 
DA> snmpTargetParams table, it may be conflicting to have these columns 
DA> duplicated in the augmenting tlstmParams table.

I don't think so.  Not every row in the snmpTargetParams table will have
an entry in the tlstmParamsTable so creation needs to be managed
independently.  It could be done either way, you're right but I think it
makes more sense to have a separate creation/deletion object.  Other
opinions are welcome on the subject though.

However, it shouldn't be an AUGMENT in the first place.  I've changed
the next to be an identical copy of the snmpTargetParamsTable index
since it's not a 1:1 mapping, which rules out AUGMENT usage in the first
place.

Regardless the fate sharing needs to be documented better than it is
currently so I'll work on the wording for that.

DA> Note that the tlstmParamsRowStatus description states that "The 
DA> value of this object has no effect on whether other objects in this 
DA> conceptual row can be modified" and the values for objects in the 
DA> snmpTargetParams table cannot be set if the RowStatus is active.

Well, I suppose that I should copy that table's method of modification
method you're right.

DA> -- The tlstmParamsHashValue object may need to have a default value
DA> defined.    

Well, it'd have to default to "" which isn't helpful.  I think I'd
rather state that the row can't be made active unless the values are
legally set.  There is no sensible default value.

How's this for new text for the tlstmParamsRowStatus object:

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."

--
Wes Hardaker
Cobham Analytic Solutions