Re: [imss] WG last call review: T11-FC-ZONE-SERVER-MIB in
Keith McCloghrie <kzm@cisco.com> Mon, 11 September 2006 20:34 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMsUY-00049v-Iq; Mon, 11 Sep 2006 16:34:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMsUX-00049q-EV for imss@ietf.org; Mon, 11 Sep 2006 16:34:53 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMsUW-0007nF-JJ for imss@ietf.org; Mon, 11 Sep 2006 16:34:53 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 11 Sep 2006 13:34:52 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8BKYqfr015876; Mon, 11 Sep 2006 13:34:52 -0700
Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8BKYpYp028324; Mon, 11 Sep 2006 13:34:51 -0700 (PDT)
Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA01744; Mon, 11 Sep 2006 13:33:46 -0700 (PDT)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200609112033.NAA01744@cisco.com>
Subject: Re: [imss] WG last call review: T11-FC-ZONE-SERVER-MIB in
To: bwijnen@lucent.com
Date: Mon, 11 Sep 2006 13:33:46 -0700
In-Reply-To: <no.id> from "Wijnen, Bert (Bert)" at Sep 07, 2006 11:17:22 PM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=16157; t=1158006892; x=1158870892; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kzm@cisco.com; z=From:Keith=20McCloghrie=20<kzm@cisco.com> |Subject:Re=3A=20[imss]=20WG=20last=20call=20review=3A=20T11-FC-ZONE-SERVER-MIB=2 0in; X=v=3Dcisco.com=3B=20h=3DzwXAaKTd1FawHaAN/5DEG7WkNiU=3D; b=p9NgsMYoHXJ6Bwr9fFbIZXZJQiJgNhopVrmgMe01vp9bPfmsnyG25raA5Rxxq/IGMIsTJo3F gY8JdEANbjIsvvDUc1ktuV4l2ytzIm7mb+nojmouxAKoRgQ6sbrQ1jas;
Authentication-Results: sj-dkim-3.cisco.com; header.From=kzm@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505
Cc: imss@ietf.org, Black_David@emc.com, dromasca@avaya.com
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group <imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org
Thanks for the comments. Responses below. Keith. --------------------------- > 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. First, I would agree if its name was ZoningName, but prepended with "T11", the odds of it having any affect on "future name clashes" is negligible. Second, I regret that I named T11NsGs4RejectReasonCode with an "Ns" in the middle -- it would have been better to have named it T11Gs4RejectReasonCode, or better still T11GsRejectReasonCode, because it has been used in several FC MIBs for protocols defined in FC-GS-nn, i.e., it is not specific to the Name Server and not specific to FC-GS-4. Third, if used in another MIB, the place where it is defined is specified in the IMPORTS clause, and thus, doesn't have to be explicit from the name. Nevertheless, if you insist that I repeat my past mistakes:-), OK. > - 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. I disagree. I think it's bad practice to put error codes in DESCRIPTIONs. I just cricitized the IPSP WG MIBs for putting 'inconsistentValue' in their DESCRIPTIONs because that error code is NOT used if and when any of the nine higher-precedence error conditions prevails. How about I change it to: When the corresponding instance of t11ZsServerOperationMode has the value 'enhanced', or when the corresponding instance of t11ZsZoneSetResult has the value 'inProgress', it is inconsistent to try to set the value of this object. > - Now that I see t11ZsServerReasonCode, I wonder if the 2nd > para in the DESCRIPTION clause would also make sense for > the t11FLockRejectReasonCode object OK. > - do the SIZE for t11ZsServerReasonCodeExp > and t11ZsServerReasonVendorCode possibly also make sense for > t11FLockRejectReasonCodeExp, t11FLockRejectReasonVendorCode > that is allowing for a SIZE of zero? OK. > - 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. Each object in question refers to the setting of a single bit, which (obviously:-) takes the values 0 or 1, and so, yes, it would be possible to define each object as a TruthValue which has two values 'true' and 'false'. However, the FC-GS-5 spec does not define either bit as: true/false. Instead, it defines the behaviour when the bit is 0, and the behaviour when the bit is 1. I think it's better in these cases to emphasize the commonality with FC-GS-5 by using the same definition, rather than intepreting the definitions as true/false. > - 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 !!?? It can. I'll add a few words. > - 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. Well, yes, the row in the t11ZsServerTable must exist, but to say "already exist" would mislead the reader because there's no RowStatus in that table. Instead, there's an entry in the t11ZsServerTable for the Zone Server for a particular fabric on a particular switch. I think that's already implicit in: "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). In other words, this MIB about creating/editing information in the Zone Set Database of existing Zone Servers, not for creating new Zone Servers on switches and/or new Fabrics. Would it help to insert "existing" in the above paragraph to try to make it more explicit ?? > 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. Deleting a row from the t11ZsSetTable deletes the Zone Set from the Zone Set Database maintained by the Zone Server, but does not otherwise affect the Zone Server. > - I have the same/similar question for t11ZsZoneEntry So, shall I also insert "existing" into t11ZsZoneEntry's DESCRIPTION to try to make it similarly more explicit ?? > - 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. See the picture in section 5.6 -- all read-write objects in the Zone Set Database can be modified at any time. The reason that other MIBs don't allow writes while a row is active is because they overload the RowStatus for in-use/not-in-use as well as for create/delete. In this MIB, only the Active Zone Set is in-use and it is read-only except to be Activated/De-Activated. I too don't want to keep repeating it. So, suggest I add a paragraph to the MODULE-IDENTITY's DESCRIPTION explaining that the MIB is a combination of the Zone Set Database and the Active Zone Set, where all objects representing the former are modifiable at any time whereas all objects representing the latter are always read-only, other than by completely overwritting the Active Zone Set by a subset of Zone Set Database, or by completely deleting it. > - 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. OK. > - 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). Persistency is fully specified in those objects which include this statement: When read, the value of this object is always xxx. This statement: "A textual message indicating the reason for the most recent failure of a Zone Set activation or de-activation, or the zero-length string if no information is available. allows an agent to retain the info for as long as it can. I'll modify: The value 'none' indicates activation/de-activation has not been attempted. by appending "since the last restart of the management system." > - For namingconsistency in: > T11ZsActiveZoneEntry ::= SEQUENCE { > t11ZsActiveZoneIndex Unsigned32, > t11ZsActiveZoneName T11ZoningName, > t11ZsActiveBroadcast TruthValue, > t11ZsActiveHardZoning TruthValue > } > I would insert a "Zone" before "Broadcast" and before "Hardzoning" I didn't do that because whereas t11ZsActiveZoneIndex is the Zone's Index and t11ZsActiveZoneName is the Zone's Name, t11ZsActiveBroadcast is not the Zone's Broadcast. Further, t11ZsActiveBroadcast is about "Broadcast Zoning", not "Zone Broadcast" -- t11ZsActiveZoneBroadcast gives the wrong impression. So, I guess it has to be t11ZsActiveZoneBroadcastZoning. > 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? They are both in the t11ZsEnhancedModeGroup, and it is specified as: GROUP t11ZsEnhancedModeGroup DESCRIPTION "This group is mandatory only for those systems with Zone Servers which support Enhanced Mode." which I believe is sufficient. > --------- 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. If I recall correctly, I added them there due to some earlier comment on an exactly-equivalent definition (I don't remember which MIB it was in). > - 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. Values which are reserved today could easily be allocated tomorrow. Values which are allocated today will likely stay allocated to the same thing for a long time into the future. Thus, listing the allocated values and omitting the reserved values has the best chance of continuing to be correct in the future. > - 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. The example which is most well-known (at least to me) of a "special meaning" is InterfaceIndexOrZero which is not indicated like this. Further, I don't know where, if anywhere, your convention is documented, and I think you would have difficulty defining the term "special meaning" if you did try to document it. > 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. If I thought that it would be re-used, then yes, I'd do this. But, after so many (that I've lost count) Fibre Channel MIBs, and now that I'm working on the last set (at least, the last scheduled ones), I don't think it's worth it. > - I personally prefer to name notifications xxxNotification instead > of naming them xxxNotify. But I admit that that is subjective. > > Bert > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss
- [imss] Changes to draft-ietf-imss-fc-fam-mib-00.t… Keith McCloghrie
- [imss] Re: Changes to draft-ietf-imss-fc-fam-mib-… Keith McCloghrie
- Re: [imss] Re: Changes to draft-ietf-imss-fc-fam-… Keith McCloghrie
- [imss] Re: Agenda for next week's T11.5 Managemen… Keith McCloghrie
- Re: [imss] FW: MIB Doctor review draft-ietf-imss-… Keith McCloghrie
- Re: [imss] FW: MIB Doctor review draft-ietf-imss-… Keith McCloghrie
- Re: [imss] FW: MIB Doctor review draft-ietf-imss-… Keith McCloghrie
- Re: [imss] Last Call: 'Fibre-Channel Name Server … Keith McCloghrie
- Re: [imss] Last Call: 'Fibre-Channel Name Server … Keith McCloghrie
- [imss] Re: DISCUSS on Keith McCloghrie
- [imss] Re: AD review of: draft-ietf-imss-fc-fspf-… Keith McCloghrie
- [imss] Re: AD review of: draft-ietf-imss-fc-fspf-… Keith McCloghrie
- [imss] Re: AD review of: draft-ietf-imss-fc-rtm-m… Keith McCloghrie
- [imss] Re: AD review of: draft-ietf-imss-fc-fspf-… Keith McCloghrie
- [imss] Re: AD review of: draft-ietf-imss-fc-fspf-… Claudio DeSanti
- Re: [imss] RE: AD review of: draft-ietf-imss-fc-r… Keith McCloghrie
- Re: [imss] RE: AD review of: draft-ietf-imss-fc-r… Keith McCloghrie
- Re: [imss] imss WG Last Call: Fibre Channel RSCN,… Keith McCloghrie
- Re: [imss] imss WG Last Call: Fibre Channel RSCN,… Keith McCloghrie
- Re: [imss] imss WG Last Call: Fibre Channel RSCN,… Keith McCloghrie
- Re: [imss] WG last call: draft-ietf-imss-fc-rscn-… Keith McCloghrie
- Re: [imss] imss WG Last Call: Fibre Channel RSCN,… Keith McCloghrie
- Re: [imss] WG Last Call: draft-ietf-imss-fc-fcs-m… Keith McCloghrie
- [imss] A couple of loose ends Keith McCloghrie
- Re: [imss] WG last call review: T11-FC-FABRIC-LOC… Keith McCloghrie
- Re: [imss] WG last call review: T11-FC-FABRIC-LOC… Keith McCloghrie
- Re: [imss] WG last call review: T11-FC-FABRIC-LOC… Claudio DeSanti
- Re: [imss] WG last call review: T11-FC-ZONE-SERVE… Keith McCloghrie
- Re: [imss] Last Call comments on draft-ietf-imss-… Keith McCloghrie
- RE: [imss] Last Call comments on draft-ietf-imss-… Black_David
- Re: [imss] Keith McCloghrie
- Re: [imss] Keith McCloghrie
- Re: [imss] T11 MIB issue resolutions Keith McCloghrie
- Re: [imss] T11 MIB issue resolutions Keith McCloghrie
- [imss] Rereview for draft-ietf-imss-fc-rscn-mib-0… Wijnen, Bert (Bert)
- Re: [imss] Rereview of: draft-ietf-imss-fc-fcs-mi… Keith McCloghrie
- RE: [imss] Rereview of: draft-ietf-imss-fc-fcs-mi… Black_David
- Re: [imss] re-view: T11-FC-FABRIC-LOCK-MIB in Keith McCloghrie
- RE: [imss] re-view: T11-FC-FABRIC-LOCK-MIB in Wijnen, Bert (Bert)
- Re: [imss] re-review: T11-FC-ZONE-SERVER-MIB in Keith McCloghrie
- RE: [imss] re-review: T11-FC-ZONE-SERVER-MIB in Wijnen, Bert (Bert)
- Re: [imss] Acceptance of draft-kzm-imss-fc-fcsp-m… Keith McCloghrie
- RE: [imss] Acceptance of draft-kzm-imss-fc-fcsp-m… Romascanu, Dan (Dan)
- Re: [imss] imss WG Last Call: FC-SP MIB Keith McCloghrie
- RE: [imss] imss WG Last Call: FC-SP MIB Black_David
- Re: [imss] imss WG Last Call: FC-SP MIB Keith McCloghrie
- Re: [imss] imss WG Last Call: FC-SP MIB Keith McCloghrie
- RE: [imss] imss WG Last Call: FC-SP MIB WIJNEN, Bert (Bert)
- Re: [imss] imss WG Last Call: FC-SP MIB Keith McCloghrie
- RE: [imss] imss WG Last Call: FC-SP MIB Black_David
- Re: [imss] imss WG Last Call: FC-SP MIB Keith McCloghrie
- RE: [imss] imss WG Last Call: FC-SP MIB WIJNEN, Bert (Bert)
- RE: [imss] imss WG Last Call: FC-SP MIB WIJNEN, Bert (Bert)
- Re: [imss] imss WG Last Call: FC-SP MIB Keith McCloghrie
- Re: [imss] MIB doctor review part 1 (SYNTAX Check… Keith McCloghrie
- Re: [imss] MIB doctor review part 2 (T11-FC-SP-TC… Keith McCloghrie
- RE: [imss] MIB doctor review part 2 (T11-FC-SP-TC… WIJNEN, Bert (Bert)
- RE: [imss] imss WG Last Call: FC-SP MIB WIJNEN, Bert (Bert)
- Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-… Keith McCloghrie
- Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-… Black_David
- Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-… Romascanu, Dan (Dan)