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

["Wijnen, Bert \(Bert\)" <[e-mail]>]

Inline 

> -----Original Message-----
> From: Keith McCloghrie [mailto:[e-mail]] 
> Sent: dinsdag 2 januari 2007 15:50
> To: Wijnen, Bert (Bert)
> Cc: [e-mail]; [e-mail]
> Subject: Re: [imss] re-view: T11-FC-FABRIC-LOCK-MIB in
> 
> > 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.
> 

great

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

As I said, I considered none of my comments fatal.
So I personally prefer the change, but it is rather a WG decision
I think.

> > - 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."
> 
Helps (at least me). Thanks.

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

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