re-review: T11-FC-ZONE-SERVER-MIB in

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

> Bert
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) 
> > Sent: donderdag 7 september 2006 23:17
> > To: Black_Davidemc.com; imssietf.org
> > Cc: dromascaavaya.com
> > 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
> imssietf.org
> https://w
ww1.ietf.org/mailman/listinfo/imss
> 

_______________________________________________
imss mailing list
imssietf.org
https://w
ww1.ietf.org/mailman/listinfo/imss

re-review: T11-FC-ZONE-SERVER-MIB in

Thread: re-review: T11-FC-ZONE-SERVER-MIB in