Subject: [imss] re-view: T11-FC-FABRIC-LOCK-MIB in draft-ietf-imss-fc-zs-mib-01.txt

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Tue, 2 Jan 2007 11:52:23 +0100

Here is my re-review for the frabic-lock-mib revision 01. 
My original review for revision zero is attached at the bottom.

None of the below is fatal, but pls consider my comments.

Open issues/concerns:

- I see (in the fabric-loc MIB module):

           TBD - reference for assignment of Application_ID for
           the benefit of this MIB module."

  It seems to me that that TBD needs to be decided upon, no?
  Or... when I read DESCRIPTION clause of t11FLockApplicationID
  then maybe the conclusion is that nothing more needs to be
  decided for this MIB module?

- Since you use RFC3584 in a REFERENCE clause, you may want to add
  it in the references section. I am not sure I would want it
  to be a normative ref, but at least an informative one I think.

- I wonder about:
   t11FLockInitiatorIpAddrType OBJECT-TYPE
    SYNTAX          InetAddressType
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
           "This object specifies the type of IP address contained
           in the corresponding instance of t11FLockInitiatorIpAddr.
           If the IP address of the location of the initiator is
           unknown or not applicable, this object is either not
           instantiated or has the value: 'unknown'."

   Would it not be better to use "unknown" instead of allowing a
   not instantiated case? That just creates gaps in the table and
   I believe that such is just (unneeded) extra complexity for
   NM applications.

   Same for: t11FLockInitiatorIpAddr

- for this Object:
   t11FLockInitiatorIpAddr OBJECT-TYPE
    SYNTAX          InetAddress
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
           "This object specifies the IP address of the location
           of the initiator whose request caused this lock to be
           established.  In cases where the corresponding instance

   I wonder which IP address is meant/intended for a row that is
   created via SNMP? Is it the IP address of the NMS that did send
   the SNMP SET command, or is it some other address? My reading is
   that it is the IP address of the NMS. Migth be good to just state
   so if indeed this is the case. If not, then it would also be good
   to state which address is intended.

Remaining NITs, just in case you want to consider them.

- I think I would change:

    REVISION  "200609120000Z"
    DESCRIPTION
           "Initial version of this MIB."

   into:

    REVISION  "200609120000Z"
    DESCRIPTION
           "Initial version of this MIB, published as RFC yyyy."

- I'd also add the IETF IMSS WG to the ORGANIZATION clause.

Bert

and a happy new year to all.

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: donderdag 7 september 2006 17:51
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/imss
> 

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