Re: [imss] re-view: T11-FC-FABRIC-LOCK-MIB in

[Keith McCloghrie <[e-mail]>]

> Here is my re-review for the frabic-lock-mib revision 01. 

Thanks.

> 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?

What the referenced document would say *was* decided; what was
undecided was the name/number of the referenced document.  If you
recall, David's message to [e-mail] on 5 Oct 2006 stated:

  (2) The Zone Server MIB needed an FC-SW-* Application ID Value
  allocated for use in t11FLockFabricIndex.  After some initial
  bobbles, document T11/06-679v0 has been created to perform the
  allocation at this time (prior to the first draft of FC-SW-5).
  This document was formally approved by the T11 plenary (a roll
  call vote was involve, IIRC), and hence it is the reference
  that should be cited as the authority for the value FF (hex):

        S. Wilson, "FC-SW-5 Letter to T11.5" Document T11/06-697v0
        (http://www.t11.org/ftp/t11/pub/fc/sw-5/06-679v0.pdf)
        Approved by the T11 and T11.5 plenary meetings on
        October 5, 2006.

  The MIB should also state that this value, FF (hex), will
  appear in FC-SW-5.

I thought it was appropriate to include the FC-SW-5 document in the
REFERENCE clause since it was expected within the following few
months, but I wanted to get the update done and re-reviewed without
waiting for it.  Since then, the document was published on 22 November,
now available at: http://www.t11.org/ftp/t11/pub/fc/sw-5/06-804v0.pdf .
See the entry for "T11.5 MIB Support" in table 116 (on page 112).
Thus, I can now replace the TBD with a pointer to this new document.

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

> - 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
 
Whether it will be better is debatable, but I'll change it if that's
what you want.

> - 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.
 
The same phrase "request ... caused this lock to be established" is
used in the DESCRIPTION of t11FLockInitiatorType which can have
several values: other(1), ssb(2), cli(3), snmp(4).  For several of these
types, the initiator may or may not have an IP address; if it does, then
t11FLockInitiatorIpAddr is that IP address.  Note that the term "this lock"
is not ambiguous because t11FLockEntry's DESCRIPTION begins:

           "Each entry contains information specific to a current
           fabric lock setup by a particular 'managing' switch on a
           particular fabric. 

So, I don't believe there's any ambiguity.  Rather, I think you're
asking the question because the phrase, "request caused this lock to be
established", refers only implicitly to the *same* request that
t11FLockInitiatorType refers to.  So, to make it more explicit, I
propose to change:

    "initiator whose request caused this lock to be established."
to:
    "initiator which established this lock via a request of the type
     given by the corresponding instance of t11FLockInitiatorType."

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

> and a happy new year to all.
 
Likewise from me.

Keith.

> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[e-mail]] 
> > Sent: donderdag 7 september 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