Subject: [MIB-DOCTORS] WG last call review: T11-FC-ZONE-SERVER-MIB in draft-ietf-imss-f c-zs-mib-00.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 7 Sep 2006 23:17:22 +0200

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

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors