Subject: [imss] re-review: T11-FC-ZONE-SERVER-MIB in draft-ietf-imss-fc-zs-mib-01.txt

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Tue, 2 Jan 2007 12:58:38 +0100

I did a rereview of the revision 1 MIB module.
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.

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

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

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

Bert
> -----Original Message-----
> From: Wijnen, Bert (Bert) 
> Sent: donderdag 7 september 2006 23:17
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: WG last call review: T11-FC-ZONE-SERVER-MIB in 
> draft-ietf-imss-fc-zs-mib-00.txt
> 
> T11-FC-ZONE-SERVER-MIB
> 
> --------- questions/comments
> 
> - 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
> 

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