Re: [imss] WG last call review: T11-FC-FABRIC-LOCK-MIB in

[Claudio DeSanti <[e-mail]>]

Keith,

in a different conversation (unfortunately not happened on this list) 
with the FC-SW-x editor, we agreed that the proper value should be FFh, 
255 decimal. The first revision of FC-SW-5 is expected to contain this 
assignment.
Thanks,

                          Claudio.


Keith McCloghrie wrote:
>> T11-FC-FABRIC-LOCK-MIB review
>>
>> --------- questions/comments
>>
>> - DESSCIPTION clause of t11FLockApplicationID says:
>>            The value assigned to identify the 'application' for a
>>            lock established via Acquire Change Authorization (ACA)
>>            request is: 'D0'h (208 decimal).  This value will be
>>            documented in a future revision of the FC-SW-nn
>>            specification."
>>
>>    Do we have any idea as to "when such future FC-SW-nn will show
>>    up ?? If not, is this acceptable?
>>     
>  
> My understanding is that FC-SW-4 is closed, and it lists 'D0'h as one
> of the reserved values.  The long-time editor of FC-SW-nn sent an email
> message dated 8Aug06 to the T11.5 mailing-list with the assignment of
> a range of values including 'D0'h for this purpose.  The assignment
> will be documented in FC-SW-5 which is approved as a new project, but
> there is no initial draft of it yet.
>
> Would you like a formal liaison message from T11 to the IETF stating
> what number has been assigned ??
>
>   
>> - For t11FLockInitiator, in the case the SNMP, would it not be 
>>   wise/usefull to add the snmpSecuityName?
>>     
>  
> I suggest it should be possible to be a compliant implementation of this
> MIB even for an SNMPv1/SNMPv2 implementation which doesn't support SNMPv3.
> So, if we define an object to hold the value of snmpSecurityName, we
> need to define what value that object will have in an agent which does
> not implement the SNMP-COMMUNITY-MIB (in which snmpCommunitySecurityName
> is defined).  What value would you propose ??
>
>   
>> - Reading:
>>
>>    t11FLockRowStatus OBJECT-TYPE
>>       SYNTAX        RowStatus
>>       MAX-ACCESS    read-create
>>       STATUS        current
>>       DESCRIPTION
>>            "The status of this conceptual row.
>>
>>            A row for which the value of t11FLockInitiatorType is
>>            not 'snmp' cannot be deleted via this object."
>>
>>   I wonder:
>>   - can a row be set to notReady or notInservice for rows that
>>     were not created by 'snmp'? I guess not, but one could get
>>     the impression that such is possible based on this one 
>>     sentence
>>     
>
> How about we change "be deleted" to "have its status changed" ??
>
>   
>>   - What is the persistence behaviour of a row created via snmp?
>>     Probably nonVolatile? But would be good to say something
>>     about it.
>>     
>  
> No, I think it should be volatile, because an agent restart is the
> equivalent of the "various error situations" mentioned in the last
> paragraph of t11FLockEntry's DESCRIPTION.  Yes, I'll add some text.
>
>   
>> - SO I see:
>>
>>     t11FLockStatus OBJECT-TYPE
>>         SYNTAX        INTEGER {
>>                       active(1),
>>                       settingUp(2),
>>                       rejectFailure(3),
>>                       otherFailure(4)
>>                   }
>>
>>   and wonder what will happen if the lock gets released?
>>   not sure I understand how such happens, but I would assume a lock does
>>   not stay forever once it has become active, does it?
>>     
>
> No.  It gets released explicitly or implicitly (as mentioned above). 
>
>   
>>   Does the entry disappear in that case? 
>>     
>  
> Yes, because the table is defined as the list of all *current* locks.
>  
>   
>> --------- NITS
>>
>> - in t11FLockEntry DESCRIPTION clause I read 4th para:
>>
>>           Recently, a distinct value of Application_ID has also been
>>           assigned/reserved as a means of distinguishing locks
>>           established via Acquire Change Authorization (ACA)
>>           requests.  With this recent assignment, an Application_ID
>>
>>   I think I would remove "Recently" and "recent".
>>   This document is intended for a reasonably long lifespan in the
>>   future, no?
>>     
>  
> OK, how about I can change it to:
>
>           Not long before this MIB was defined, a distinct value of
>           Application_ID was also assigned/reserved as the means to
>           distinguish locks established via Acquire Change
> 	  Authorization (ACA) requests.  This additional assignment
> 	  allows an Application_ID to be used to uniquely identify a
> 	  lock amongst all active locks established either by an EACA
> 	  or by an ACA.
>
>   
>> - REFERENCE clauses of course need to be updated.
>>     
>  
> Right.
>
>   
>> - for t11FLockActiveGroup, the description clause does not say that
>>   (if write/create-mode is supported) that a lock can also be
>>   established.
>>     
>  
> I don't understand.  One of the objects in the t11FLockActiveGroup is
> t11FLockRowStatus, which is defined with a MAX-ACCESS of read-create
> and a MIN-ACCESS of read-only.  So, what do you want clarified ??
>
> Keith.
>
> _______________________________________________
> imss mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/imss
>
>   

_______________________________________________
imss mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/imss