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

[Keith McCloghrie <[e-mail]>]

Sure, I'll make the changes you suggest.

Keith.

> I also see another few NITs now that I am reviewing the 2nd 
> MIB module in the same document.
> 
> - t11FLockRejectReasonCode OBJECT-TYPE
>     SYNTAX        T11NsGs4RejectReasonCode
>     MAX-ACCESS    read-only
>     STATUS        current
>     DESCRIPTION
>            "When the value of the corresponding instance of
>            t11FLockStatus is 'rejected', this object contains
>            the rejection's reason code."
> 
>   Based on the ENUMerated values for t11FlockStatus, I 
>   think we should change 'rejected' into 'rejectFailure'.
> 
> - same for t11FLockRejectReasonCodeExp
>   and t11FLockRejectReasonVendorCode
> 
> - Now that I see t11ZsServerReasonCode, I wonder if the 2nd
>   para in the DESCRIPTION clause would also make sense for
>   the t11FLockRejectReasonCode object
> 
> - do the SIZE for t11ZsServerReasonCodeExp
>   and t11ZsServerReasonVendorCode possibly also make sense for 
>   t11FLockRejectReasonCodeExp, t11FLockRejectReasonVendorCode
>   that is allowing for a SIZE of zero?
> 
> 
> Bert
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[e-mail]]
> > Sent: Thursday, September 07, 2006 17:51
> > To: [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: [imss] WG last call review: T11-FC-FABRIC-LOCK-MIB in
> > draft-ietf-imss-f c-zs-mib-00.txt
> > 
> > 
> > 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?
> > 
> > - For t11FLockInitiator, in the case the SNMP, would it not be 
> >   wise/usefull to add the snmpSecuityName?
> > 
> > - 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
> >   - What is the persistence behaviour of a row created via snmp?
> >     Probably nonVolatile? But would be good to say something
> >     about it.
> > 
> > - 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?
> >   Does the entry disappear in that case? 
> > 
> > 
> > --------- 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?
> > 
> > - REFERENCE clauses of course need to be updated.
> > 
> > - for t11FLockActiveGroup, the deascription clause does not say that
> >   (if write/create-mode is supported) that a lock can also be
> >   established.
> > 
> > Bert
> > 
> > _______________________________________________
> > imss mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/imss
> > 
> 
> _______________________________________________
> imss mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/imss
> 

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