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

From: Keith McCloghrie <[email-masked]>
Date: Tue, 2 Jan 2007 06:50:23 -0800 (PST)

> 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 [email-masked] 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:[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
> 

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

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Tue, 2 Jan 2007 16:19:55 +0100

Inline 

> From: Keith McCloghrie [mailto:[email-masked]] 
> Sent: dinsdag 2 januari 2007 15:50
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [imss] re-view: T11-FC-FABRIC-LOCK-MIB in
> 
> 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 [email-masked] on 5 Oct 2006 stated:
> 
> 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 .

great

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

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

Bert

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 3 Jan 2007 11:16:37 -0800 (PST)

> I did a rereview of the revision 1 MIB module.

Thanks.

> At the end of this email, I have attached my earlier comment on
> revision 00.
> 
> Thanks for the revision, and also thanks for the explanatory answers
> from Keith. I see no showstoppers anymore.
> 
> remaining NIT(s):
> 
> - might want to add IETF IMSS WG in ORGANIZATION clause.
 
OK.

> - for object t11ZsActivateResult
>            The value 'none' indicates activation/de-activation
>            has not been attempted since since the last restart
>            of the management system."
>   s/since since/since/
 
OK.

> - When I read
>    t11ZsActiveAttribValue  OBJECT-TYPE
>     SYNTAX       OCTET STRING (SIZE (0..252))
>     MAX-ACCESS   read-only
>     STATUS       current
>     DESCRIPTION
>            "The value of the attribute, formatted according to
>            its type as indicated by the corresponding instance
>            of t11ZsActiveAttribType.
> 
>            As specified in FC-GS-5, the length of an attribute
>            value is at least 4 bytes, and if necessary, the value
>            is appended with zero bytes so that the length is a
>            multiple of four.  For a Vendor Specific attribute
>            value, the first 8 bytes contains the T10 Vendor ID
>            as described in FC-GS-5."
> 
>    Then it seems to me that the SYNTAX should show at least a size of 4.
>    So I would make it
>     SYNTAX       OCTET STRING (SIZE (4..252))
> 
>    Or do I not correctly understand the DESCRIPTION clause? In which
>    case it might be good to clarify it.
 
The length is: a) at least 4 bytes and b) a multiple of four.  So, if
the SYNTAX needs to exclude lengths of 0, 1, 2, and 3, then for
consistency, it also needs to exclude lengths of 4n+i where 0 < i < 4.
However, that would require a SIZE clause of more than 300 characters
(with normal spacing) or 200 characters (omitting all space characters),
i.e., either five lines in an RFC, or an unreadable three lines in an
RFC.  So that it is both readable and consistent, I suggest that it's
better to leave it as-is.

> - What is the persistency behaviour for entries in
> t11ZsNotifyControlTable?
>   From the DESCRIPTION clause of t11ZsServerDatabaseStorageType I think
>   it is controlled by that object. Would be good to list that in the
>   DESCRIPTON clause of t11ZsNotifyControlEntry, as you have done for the
>   other tables.
 
OK.

Keith.

> > From: Wijnen, Bert (Bert) 
> > Sent: donderdag 7 september 2006 23:17
> > Subject: WG last call review: T11-FC-ZONE-SERVER-MIB in 
> > draft-ietf-imss-fc-zs-mib-00.txt
> > 
> > T11-FC-ZONE-SERVER-MIB
> > 
> > - Would it be better to rename T11ZoningName to T11ZsZoningName?
> >   This for naming consistency and avoiding possible future name
> >   clashes.
> > 
> > - For t11ZsServerDistribute
> >           Setting this object will fail if the corresponding
> >           instance of t11ZsServerOperationMode has the value
> >           'enhanced', or if the corresponding instance of
> >           t11ZsZoneSetResult has the value 'inProgress'."
> >   
> >   will fail with what? I assume/think 'inconsistentValue'.
> >   Might be good to state so, to ensure proper implementation.
> > 
> > - 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?
> >  
> > - I wonder why this
> > 
> >     t11ZsServerDefaultZoneSetting OBJECT-TYPE
> >         SYNTAX       INTEGER {
> >                         permit(1),
> >                         deny(2)
> >                      }
> > 
> >   Is not done with a TruthValue possibly using a different
> >   descriptor.
> >   Not a fatal flaw though, but a missed opportunity for
> >   re-use in my view. Unless if one expects more values in
> >   the future.
> > 
> >   For t11ZsServerMergeControlSetting it is less obvious, but the
> >   same question could be asked I guess.
> > 
> > - I see:
> >     t11ZsSetName OBJECT-TYPE
> >         SYNTAX       T11ZoningName
> >         MAX-ACCESS   read-create
> >         STATUS       current
> >         DESCRIPTION
> >            "The name of this Zone Set. The t11ZsSetName should
> >            be unique within a fabric.
> > 
> >            The Zone Set can be renamed by setting this object
> >            to a new value."
> > 
> >   and wonder if the rename can also be done while the row is in
> >   'active' state !!??
> > 
> > - I am not sure I understand this:
> > 
> >     t11ZsSetEntry  OBJECT-TYPE
> >         SYNTAX       T11ZsSetEntry
> >         MAX-ACCESS   not-accessible
> >         STATUS       current
> >         DESCRIPTION
> >            "Each entry contains information about a Zone Set
> >            in the Zone Set database of a particular fabric
> >            (identified by the value of t11ZsServerFabricIndex)
> >            on a particular switch (identified by values of
> >            fcmInstanceIndex and fcmSwitchIndex).
> > 
> >            A Zone Set is created containing zero or more
> >            existing Zones.  As and when new Zones are created
> >            (as rows in the t11ZsZoneTable), they can be added
> >            to a Zone Set by creating an entry for each in the
> >            t11ZsSetZoneTable.
> > 
> >            The StorageType of a row in this table is specified by
> >            the instance of t11ZsServerDatabaseStorageType which is
> >            INDEX-ed by the same values of fcmInstanceIndex,
> >            fcmSwitchIndex and t11ZsServerFabricIndex."
> >         INDEX   { fcmInstanceIndex, fcmSwitchIndex,
> >                   t11ZsServerFabricIndex, t11ZsSetIndex }
> >         ::= { t11ZsSetTable 1 }
> > 
> >   So it seems to me I can do SNMP SET to create an entry in this
> >   table. But is is not clear if, when I do so, and entry in the
> >   t11ZsServerTable must already exist or not. Probably so,
> >   because it uses the actual (index) objects from that table.
> >   But in practice, can an SNMP utility not just create entries
> >   with index values that do not really exists in the base
> >   table? I'd like to know how the agent is supposed to react.
> > 
> >   So if the base table entrues must exist first,
> >   then it would be good to say so, i.e. spell it out.
> >   And to say what happens if it does not yet exist.
> >   If not, then I wonder how/when the entry in that t11ZsServerTable
> >   does get created, because otherwise it is unclear how/if/when
> >   the persistency works.
> >   
> >   And what when I delete the row? Does it have any effect on the
> >   associated rows in t11ZsServerTable. Possibly not. But I am
> >   not sure how I can determine that based on the current
> >   DESCRIPTION clauses.
> > 
> > - I have the same/similar question for t11ZsZoneEntry
> > 
> > - Can t11ZsZoneAttribBlock be changed while row is active?
> > 
> >   such questions can be asked for more read-write/read-create
> >   objects in this MIB module. I won't keep repeating.
> > 
> > - For t11ZsSetZoneEntry, it seems that the 3 other tables MUST
> >   have an existing associated entry(entries) before creating
> >   an entry in this row makes sense. But maybe it is OK to
> >   prepare this table before the other tables have been
> >   completed/created?
> > 
> > - for t11ZsSetZoneRowStatus I wonder what happens if this
> >   one has a value of active, byt the rowstatus in some of
> >   the other (base) tables have a value of notInservice or
> >   notReady ??
> > 
> >   Are we all supposed to try and figure this out, or would it
> >   be better to put something about this in the various
> >   DESCRIPTION clauses?
> > 
> > - In fact the whole fate-sharing between all the tables may
> >   need to be described. I see some of it in section 5.5. and
> >   5.6 of the document, but also from that I do not yet see
> >   what the implications are if the rowstatus in one table is
> >   notInservice, while others are actve or  maybe notReady,
> >   or maybe do not (yet) exist.
> >   I must also admit that I have not studied the T11 documents
> >   much (in fact very little) yet. But I'd hope that these
> >   basic question would be answered in the IETF MIB document
> >   itself.
> > 
> > - I see no persistency behaviour (or a link to the StorageType
> >   objects in the base table in t11ZsActivateTable.
> >   I think it is clear that the writable objects are all
> >   volatile (they seem to be control objects that cause an
> >   action when SET).
> > 
> > - For namingconsistency in:
> >     T11ZsActiveZoneEntry ::= SEQUENCE {
> >        t11ZsActiveZoneIndex      Unsigned32,
> >        t11ZsActiveZoneName       T11ZoningName,
> >        t11ZsActiveBroadcast      TruthValue,
> >        t11ZsActiveHardZoning     TruthValue
> >     }
> >   I would insert a "Zone" before "Broadcast" and before "Hardzoning"
> > 
> >   By the way, t11ZsActiveZoneSetName in the T11ZsActiveEntry might be
> >   (at first sight) perceived to be in the T11ZsActiveZoneEntry.
> >   I understand why it has that name, but it may consfuse some
> >   people.
> > 
> > - t11ZsActiveBroadcast and t11ZsActiveHardZoning both have in
> >   their DESCRIPTION clauses:
> >              This object is only instantiated in Enhanced mode."
> > 
> >   would we not want to specify that in a MODULE-COMPLIANCE for
> >   basic mode and one for enhanced mode?
> > 
> > 
> > 
> > --------- NITS/TYPOs
> > 
> > - In one but last para of DESCRIPTION clause of MODULE-IDENTITY
> > 
> >      When this MIB is used for Basic Zoning Management, the same
> >      set of MIBs objects as used for Enhanced mode are used to
> > 
> >   s/MIBs objects/MIB objects/
> > 
> > - In t11ZsServerFabricIndex, the last 2 paragraphs of the
> >   DESCRIPTION clause seem redundant with the DESCRIPTION clause
> >   of the TC itself. I would remove them. The idea of a TC is
> >   to have one place (namely in the DESCRIPTION clause of the TC)
> >   to describe the (basic) semantics of the objects that use 
> >   the TC as a SYNTAX.
> > 
> > - t11ZsServerCapabilityObject
> >   I think I would rename zonesetDb(1) to zoneSetDb(1)
> >   but this is pretty subjective taste of course.
> > 
> > - last para of description clasue of t11ZsServerDatabaseStorageType
> > 
> >            This value of this object is a...
> > 
> >   s/This/The/ ??
> >   
> > - For t11ZsAttribType maybe add "other values reserved" in the 
> >   DESCRIPTION clause. I went looking it up, because in an 
> >   earlier object we had E0-EF as Vendor specific. So I thought
> >   that might also be the case here. But the text in the 
> >   REFERENCEd docment/section told me they are reserved.
> > 
> > - for
> >    t11ZsActivateRequest OBJECT-TYPE
> >      SYNTAX       Unsigned32 (0..4294967295)
> >      MAX-ACCESS   read-write
> >      STATUS       current
> >      DESCRIPTION
> >            "Setting this object to a value is a request for a
> >            Zone Set to be activated on the fabric which is
> >            represented by this row.  The Zone Set to be
> >            activated is the one for which t11ZsSetIndex has
> >            the same value.
> > 
> >            If a Zone Set is already active on a fabric when a
> >            request is made to activate a different one on that
> >            fabric, then the existing Zone Set is automatically
> >            deactivated and the specified Zone Set is activated
> >            in its place.
> > 
> >            The value of this object when read is always 0."
> > 
> >    It seems that setting the value to zero has no effect. Right?
> >    But zero seems to also have special meaning. Oh well. I might
> >    indicate it by using 
> >      SYNTAX       Unsigned32 (0 | 1..4294967295)
> >    but that is subjective taste I guess.
> > 
> > - similarly, for
> > 
> >     t11ZsFabricIndex OBJECT-TYPE
> >         SYNTAX       Unsigned32 (0..4096)
> > 
> >   I think I would use  
> > 
> >         SYNTAX       Unsigned32 (0..4095 | 4096)
> > 
> >   to indicate that 4096 has special meaning.
> > 
> >   Maybe I would even create a 
> > 
> >       T11FabricIndexOrAll ::= TEXTUAL-CONVENTION
> > 
> >   So it could if an "ALL" option is needed in the future that it is
> >   (or at least can be) done in a consistent maner.
> > 
> > - I personally prefer to name notifications xxxNotification instead
> >   of naming them xxxNotify. But I admit that that is subjective.
> > 
> > 
> > Bert
> > 
>

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 4 Jan 2007 00:31:05 +0100

W.r.t. 

> Sent: woensdag 3 januari 2007 20:17
> To: Wijnen, Bert (Bert)
> Subject: Re: [imss] re-review: T11-FC-ZONE-SERVER-MIB in
> 
> > - When I read
> The length is: a) at least 4 bytes and b) a multiple of four. 
> So, if the SYNTAX needs to exclude lengths of 0, 1, 2, and 3,
> then for consistency, it also needs to exclude lengths of 
> 4n+i where 0 < i < 4.
> However, that would require a SIZE clause of more than 300 
> characters (with normal spacing) or 200 characters (omitting 
> all space characters), i.e., either five lines in an RFC, or 
> an unreadable three lines in an RFC.  So that it is both 
> readable and consistent, I suggest that it's better to leave it as-is.
> 

I can live with it. Persoanlly I would still make the minimum SIZE 4.
I can agree that making the SIZE spec such that only multiples of 
4 octets get accepted woul be a bit excessive (for a human reader,
for a machine reader it would be fine I guess). But we have many
human readers as well.

Bert