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

[Keith McCloghrie <[e-mail]>]

> 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