From imss-bounces@ietf.org Mon Jan 01 13:27:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Rsc-0004Sr-JV; Mon, 01 Jan 2007 13:27:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Rsb-0004Sj-B8 for imss@ietf.org; Mon, 01 Jan 2007 13:27:25 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1RsW-00084R-6G for imss@ietf.org; Mon, 01 Jan 2007 13:27:25 -0500 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l01IQms4020831; Mon, 1 Jan 2007 13:26:48 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l01IQaRa006794; Mon, 1 Jan 2007 13:26:36 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 13:26:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [imss] Rereview of: draft-ietf-imss-fc-fcs-mib-01.txt Date: Mon, 1 Jan 2007 13:26:35 -0500 Message-ID: In-Reply-To: <200612311452.GAA05687@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [imss] Rereview of: draft-ietf-imss-fc-fcs-mib-01.txt Thread-Index: Accs65QylCHj0DYSSMuxakWy+aNyLAA5mPvA To: , X-OriginalArrivalTime: 01 Jan 2007 18:26:36.0223 (UTC) FILETIME=[5EEB9CF0:01C72DD2] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.1.95433 X-PerlMx-Spam: Gauge=, SPAM=6%, Reason='EMC_FROM_0+ -2, __LINES_OF_YELLING! 1, LINES_OF_YELLING_3 0.671, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 884d655656c6d298dae25b0122479d16 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org Keith, Go ahead and submit a revised draft, including the mention of the IMSS WG as having developed the MIB, since that does seem to be common practice. The existence of the imss WG and the RFCs it produced will archived long-term on the IETF web site, long after the WG completes its work. Thanks, --David > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com]=20 > Sent: Sunday, December 31, 2006 9:53 AM > To: bwijnen@alcatel-lucent.com > Cc: imss@ietf.org; dromasca@avaya.com > Subject: Re: [imss] Rereview of: draft-ietf-imss-fc-fcs-mib-01.txt >=20 > Thanks, Bert. I agree that it would be good to mention IMSS (as well > as T11) in the ORGANIZATION clause of the MODULE-IDENTITY, and since > that will require a new version of the I-D, I can add a WRITE-SYNTAX > clause (for t11FcsDiscoveryStatus) as you suggest at the same time. >=20 > So, a question for David (after he returns from his vacation two weeks > from now) and/or Dan: shall I submit an updated I-D with the these two > changes ? >=20 > Keith. > =20 > > I have re-reviewed this MIB document. > > My first review was the revision zero version. > > My comments to that one and the answer provided by Keith > > are attached below. I am happy with the new revision > > and/or the answers that were given by Keith. > >=20 > > No major issues anymore, So I think this doc is ready. > >=20 > > You may want to consider this: > >=20 > > - I wonder if the IETF IMSS WG should also be mentioned in > > the ORGANIZATION clause of the MODULE-IDENTITY > >=20 > > - For object t11FcsDiscoveryStatus I read in the DESCRIPTION > > clause that one can only SET it to localOnly via SNMP. > > I suggest to also express this in the MODULE-COMPLIANCE > > by changing: > >=20 > > OBJECT t11FcsDiscoveryStatus > > MIN-ACCESS read-only > > DESCRIPTION > > "Write access is not required." > >=20 > > into something like: > >=20 > > OBJECT t11FcsDiscoveryStatus > > WRITE-SYNTAX INTEGER { localOnly(3) } > > MIN-ACCESS read-only > > DESCRIPTION > > "Write access is not required. > > However, if write access is supported, then=20 > one can only > > write (SET) the value to 'localOnly'. > > " > >=20 > > It was discussed in the below inetraction between Keith=20 > and myself. > > I can live if you do not change the MODULE-COMPLIANCE. > >=20 > > Bert > >=20 > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com]=20 > > Sent: woensdag 6 september 2006 0:04 > > To: bwijnen@lucent.com > > Cc: imss@ietf.org > > Subject: Re: [imss] WG Last Call: draft-ietf-imss-fc-fcs-mib-00.txt > >=20 > > Bert, > >=20 > > Thanks for the comments. My responses are below. > >=20 > > Keith. > > ----------------- > >=20 > > > - In the MODULE-IDENTITY, I see: > > >=20 > > > REVISION "200608140000Z" > > > DESCRIPTION > > > "Initial version of this MIB module." > > > ::=3D { mib-2 nnn } -- to be=20 > determined later > > > =20 > > > I think I would make that: > > >=20 > > > REVISION "200608140000Z" > > > DESCRIPTION > > > "Initial version of this MIB module, published as RFC > > yyyy." > > > -- RFC-Editor, replace yyyy with actual RFC number &=20 > remove this > > note > > > ::=3D { mib-2 nnn } -- to be assigned by IANA. > > > -- RFC Editor: replace nnn with IANA-assigned number=20 > & remove this > >=20 > > > note > > >=20 > > > - To avoid later comments, I would also add this to the=20 > DESCRIPTION > > > clause of the MODULE-IDENTITY itself: > > >=20 > > > Copyright (C) The Internet Society (2006). =20 > This version of > > > this MIB module is part of RFC yyyy; see the=20 > RFC itself > > for > > > full legal notices." > > >=20 > > > -- RFC Editor: replace yyyy with actual RFC number &=20 > remove this=20 > > > note > > =20 > > Oops. All of this WG's other recent drafts have the required > > boilerplate; I'm not sure how this one slipped through without it. > >=20 > > > - I wonder if we would not better rename these TCs (for naming > > consistency): > > >=20 > > > FcIeType, FcPortState, FcPortTxType > > > =20 > > > and name them instead as follows: > > >=20 > > > T11FcIeType, T11FcPortState, T11FcPortTxType > > >=20 > > > Or are these 3 TCs extending the set of FcXxxx TCs in RFC4044? > > > If so, the I'd suggest to add at least a small SMI=20 > comment to state > > that, > > > so that it is clear why the names are as chosen. > > =20 > > I named them to be consistent with FcPortType, and, *if* we were > > updating > > RFC4044, then I'd put them in there, but we're not. So,=20 > rather than > > add a "small SMI comment", I'd prefer to change their names. > >=20 > > > - For consistency, but also for betetr info in the=20 > DESCRIPTION clause, > > > I would consider to change: > > >=20 > > > FcPortTxType ::=3D TEXTUAL-CONVENTION > > > STATUS current > > > DESCRIPTION > > > "The technology of the port transceiver: > > >=20 > > > unknown - unknown (includes the=20 > 'null' type) > > > other - some other technology > > > shortwave850nm - Short wave laser - SN (850 nm) > > > longwave1550nm - Long wave laser - LL (1550 nm) > > > longwave1310nm - Long wave laser cost > > > reduced - LC (1310 nm) > > > electrical - Electrical - EL." > > >=20 > > > into: > > >=20 > > > FcPortTxType ::=3D TEXTUAL-CONVENTION > > > STATUS current > > > DESCRIPTION > > > "The technology of the port transceiver: > > >=20 > > > unknown(1) - unknown (includes the=20 > 'null' type) > > > other(2) - some other technology > > > shortwave850nm(3) - Short wave laser - SN (850 nm) > > > longwave1550nm(4) - Long wave laser - LL (1550 nm) > > > longwave1310nm(5) - Long wave laser cost > > > reduced - LC (1310 nm) > > > electrical(6) - Electrical - EL." > > =20 > > OK. > >=20 > > > - I am a bit surprised by: > > >=20 > > > T11ListIndexPointer ::=3D TEXTUAL-CONVENTION > > > STATUS current > > > DESCRIPTION > > > "Objects with this syntax point to a list of elements > > > contained in a table, by holding the same value as the > > > object with syntax T11ListIndex defined in the table's > > > INDEX clause, or, zero to indicate an empty list. > > > The definition of an object with this syntax must > > > identify the table(s) into which it points." > > > SYNTAX Unsigned32 -- the default range of (0..4294967295) > > >=20 > > > First, I would make it: SYNTAX Unsigned32 (0..4294967295) > > > instead of putting that in a SMI comment field. > > =20 > > The reason I added the ASN.1 comment was to dispel all=20 > ambiguity, i.e., > > to make it clear that the definition intentionally uses the default > > range. Thus, there is no reason to include the default=20 > range explicitly > > in the syntax. Why do we have a default range if we're not=20 > allowed to > > use it ?? > >=20 > > > Second, I think we normally would use a name of > > >=20 > > > T11ListIndexOrZero ::=3D TEXTUAL-CONVENTION > > >=20 > > > To complement the T11ListIndex TC, which does not=20 > include the zaero. > > >=20 > > > Third, we also normally do not prescribe what a value=20 > of zero means, > > > but we normally say something aka (this is from > > InetrfaceIndexOrZero): > > >=20 > > > "This textual convention is an extension of the > > > InterfaceIndex convention. The latter=20 > defines a greater > > > than zero value used to identify an interface=20 > or interface > > > sub-layer in the managed system. This=20 > extension permits > > the > > > additional value of zero. the value zero is > > object-specific > > > and must therefore be defined as part of the=20 > description > > of > > > any object which uses this syntax. Examples=20 > of the usage > > of > > > zero might include situations where interface=20 > was unknown, > > > or when none or all interfaces need to be referenced." > > >=20 > > > We in fact have quite a few of these XxxSomeIndex and > > XxxSomeIndexOrZero > > > TCs, which all (i believe) follow/use that same concept. I would > > strongly > > > suggest that we do so here as well. > > >=20 > > > Mmmm... I see that for some other TCs in the=20 > FC/IMSS/IPS space you > > do > > > not follow the InterfaceIndex/InetrfaceInexOrZero so=20 > closely either. > > > Oh well... Up to you and the WG. I personally like the > > InterfaceIndeOrZero > > > approach better.=20 > > =20 > > OK, I'll rename the TC to T11ListIndexPointerOrZero. > >=20 > > > - I see REFERENCE clauses aka: > > >=20 > > > REFERENCE > > > "ANSI INCITS xxx-200x, Fibre Channel -=20 > Generic Services 5, > > > FC-GS-5 T11/Project 1677-D/Rev 8, Table 124." > > >=20 > > > which relates to this reference (I guess): > > >=20 > > > [FC-GS-5] > > > "Fibre Channel - Generic Services - 5 (FC-GS-5)", ANSI INCITS > > > xxx-200x, T11/Project 1677-D/Rev 8.00 > > > http://www.t11.org/t11/stat.nsf/upnum/1677-d, September 2004. > > >=20 > > > Do we know when we will get a stable reference? > > > It is normative, so we may have to say something about that. > > >=20 > > > I guess Keith already stated that David or Claudio should answer > > this=20 > > > question. > > =20 > > Claudio said this morning that revision 8.5 is the final one. > > So, I need to go ahead and update the MIB based on Rev 8.5,=20 > including > > adding any new enumerations which have been defined since Rev 8.0. > >=20 > > > - For t11FcsFabricDiscoveryRangeLow and > > t11FcsFabricDiscoveryRangeHigh, > > > is the value in these objects included in teh range? My=20 > read would > > > say they are. But we may want to make that clear by stating it? > > =20 > > OK, I'll change: > >=20 > > "The discovery by a particular switch operates > > within all existing Fabrics that have a fabric > > index within a specific range. ... > > to: > > "The discovery by a particular switch operates > > within all existing Fabrics that have a fabric > > index within a specific inclusive range. ... > >=20 > > > - For t11FcsFabricDiscoveryStart, how long does discovery take? > > > The reason I ask, is that if it may take a while, that we might > > > want to consider a value like "discoveryInProgress(3) ?? > > > Just thinking aloud, I can also live with what we have=20 > in there now. > > =20 > > I think this is already available since 'inProgress' is one of the > > defined values for t11FcsDiscoveryStatus. > >=20 > > > - t11FcsFabricDiscoveryTable > > > I guess that this table gets created/instantiated by the agent > > everytime > > > it starts. There are no default values for the two objects=20 > > > t11FcsFabricDiscoveryRangeLow and=20 > t11FcsFabricDiscoveryRangeHigh. > > > So how is the behavioud if I issue a DiscoveryStart when these > > objects > > > have not been SET yet? Should we define DEFVALs? > >=20 > > Just adding DEFVALs would be a temptation to write sloppy=20 > applications, > > because an NMS can not be sure whether a particular entry=20 > has been used > > or not since the last reboot. Thus, invoking DiscoveryStart without > > checking the values of RangeLow and RangeHigh, would be very sloppy. > > Given that an application needs to check, then it also has=20 > to change the > > values if they're wrong. Thus, the simplest way to write such an > > application is to always specify the range explicitly (i.e., write > > RangeLow and RangeHigh) at the same time as invoking DiscoveryStart. > >=20 > > So, I propose to add a recommendation to the DESCRIPTION like this: > >=20 > > t11FcsFabricDiscoveryStart OBJECT-TYPE > > SYNTAX INTEGER { > > start(1), > > noOp(2) > > } > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "This object provides the capability to=20 > trigger the start > > of a discovery by a Fabric Configuration=20 > Server. If this > > object is set to 'start', then the discovery=20 > is started on > > those fabrics which have their fabric index=20 > value in the > > range specified by t11FcsFabricDiscoveryRangeLow and > > t11FcsFabricDiscoveryRangeHigh. It is=20 > recommended that > > whenever an instance of this object is set to 'start', > > that the desired range be concurrently specified by > > setting the corresponding instances of > > t11FcsFabricDiscoveryRangeLow and > > t11FcsFabricDiscoveryRangeHigh. > >=20 > > > - Given the DESCRIPTION clause of t11FcsFabricDiscoveryStart, I=20 > > > suggest to add DEFVAL { noOp } > >=20 > > Since the value when read is always 'noOp', to specify a=20 > DEFVAL would > > either be redundant, or worse, it would weaken the=20 > definition because a > > DEFVAL is only advisory, whereas the statement: "the value=20 > when read is > > always 'noOp'" is mandatory. > >=20 > > > - I suppose that SETTING t11FcsDiscoveryStatus to one of > > > inProgress(1), > > > completed(2), > > > would have no effect? I.e. it would be ignored? > > > Whatever the intended behaviour is to be, we probably do best to > > > be specific as to what we want an agent to do. > > >=20 > > > I personally kind of like to add something to the=20 > MODULE-COMPLIANCE< > > > which states that the WRITE-SYNTAX is localOnly(3) and that > > > the SYNTAX is all 3 values. I think that expresses that only the > > > one value that makes sense can be SET/written. > > >=20 > > > I personally might do a similar thing for > > t11FcsFabricDiscoveryStart, > > > but that one at least explains what to do if I set the value to > > > something that does not trigger an action. > > =20 > > I prefer to add a sentence to the DESCRIPTION of=20 > t11FcsDiscoveryStatus, > > like this: > >=20 > > It is an error for a manager to set the value of this > > object to anything other than 'localOnly'." > >=20 > > > - t11FcsDiscoveryStatus has no persistency (or so is my reading of > > > the DESCRIPTION clause) and will be set to localOnly=20 > upon a restart? > > > If so, it might be usefull to add a sentence about=20 > that, just to be > > > explicit and clear. > > =20 > > It already has this sentence: > >=20 > > Initially when the switch comes up, all=20 > instances of this > > object have the value: 'localOnly' > >=20 > > Do you want me to change "switch comes up" to "agent restarts" ?? > >=20 > > > - For objects t11FcsIeName and t11FcsIeDomainId, I wonder=20 > if a zero > > > (i.e. zero length OCTET STRING) are really valid. If=20 > not, then we > > > should add a SIZE and RANGE restriction. > > =20 > > FC-GS-5 says: > >=20 > > 6.2.3.2.1 Interconnect Element Name > >=20 > > The format of the Interconnect Element Name attribute, as=20 > used by the > > Fabric Configuration Server, shall be identical to the=20 > Name_Identifier > > format defined in FC-FS. If the Interconnect Element is a=20 > Switch (see > > FC-SW), the Interconnect Element Name attribute shall be the > > Switch_Name of the Switch. > >=20 > > This standard does not define how this attribute is=20 > registered with > > the > > Fabric Configuration Server. The null value for the Interconnect > > Element Name attribute is 00 00 00 00 00 00 00 00h. > >=20 > > and > >=20 > > 6.2.3.2.3 Interconnect Element Domain Identifier > >=20 > > The format of the Interconnect Element Domain Identifier=20 > attribute, as > > used by the Fabric Configuration Server, shall be identical to the > > Domain Identifier format defined in FC-SW-3. > >=20 > > This standard does not define how this attribute is=20 > registered with > > the > > Fabric Configuration Server. The null value for the Interconnect > > Element Domain Identifier attribute is 00h. > >=20 > > Since t11FcsIeDomainId can have a value of zero,=20 > FcDomainIdOrZero (which > > is defined as "SYNTAX Integer32 (0..239)") should not be=20 > restricted. > >=20 > > For t11FcsIeName, the "null" value is specified as all zeros, rather > > than the zero-length value. So, yes, I'll add a restricted range: > >=20 > > t11FcsIeName OBJECT-TYPE > > SYNTAX FcNameIdOrZero (SIZE(8 | 16)) > >=20 > > > - This definition seems strange: > > >=20 > > > t11FcsIeFabricName OBJECT-TYPE > > > SYNTAX FcNameIdOrZero > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The Fabric_Name (WWN) of this Interconnect Element. > > > When the Fabric_Name is unknown, this object contains > > > the all-zeros value: x'00 00 00 00 00 00 00 00'." > > > REFERENCE > > > "ANSI INCITS xxx-200x, Fibre Channel -=20 > Generic Services 5, > > > FC-GS-5 T11/Project 1677-D/Rev 8, section 6.2.3.2.5." > > > DEFVAL { '0000000000000000'h } > > > ::=3D { t11FcsIeEntry 5 } > >=20 > > I'll add a restricted range here too. > >=20 > > t11FcsIeFabricName OBJECT-TYPE > > SYNTAX FcNameIdOrZero (SIZE(8 | 16)) > >=20 > > > - I see this: > > >=20 > > > t11FcsIeMgmtAddrListIndex OBJECT-TYPE > > > SYNTAX T11ListIndexPointer > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The management address list for this Interconnect > > Element. > > > This object points to an entry in the > > > t11FcsMgmtAddrListTable." > > >=20 > > > Reading the DESCRIPTIOn clause, I wonder why one would=20 > not use a=20 > > > RowPointer. The fact is that the pointer does not point to "an > > entry" > > > in the t11FcsMgmtAddrListTable, but to a SET of such entries. > > > So I guess the DESCRIPTION clause could be clarified. > >=20 > > It is sufficient (and simpler) for this TC to be an=20 > Unsigned32, whereas > > RowPointer is an OID. > > =20 > > As a clarification, I've added this sentence to > > T11ListIndexPointerOrZero's > > DESCRIPTION: > >=20 > > Note that such a table could have one row per list, or > > it could have one row per element of a list. > > =20 > > > - I see: > > > =20 > > > t11FcsIeInfoList OBJECT-TYPE > > > SYNTAX OCTET STRING (SIZE (0..252)) > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The information list for this Interconnect Element. > > > This object contains the following substrings=20 > in order: > > > vendor name, model name/number and release code/level, > > > followed by zero or more substrings of vendor-specific > > > information. Each substring is terminated with a byte > > > containing a null value (x'00')." > > >=20 > > > And that reads as if it is ASCII information to be=20 > (potentially)=20 > > > consumed by human beings. So in that case, the IETF wants it to > > > be an internationalized string. Comment? > > =20 > > FC-GS-5 requires the individual values to be ASCII strings=20 > (terminated > > by nulls). I'll edit the DESCRIPTION to be: > >=20 > > The value of this object is formatted as specified in > > FC-GS-5, i.e., it contains the following substrings in > > order: vendor name, model name/number and release > > code/level, followed by zero or more substrings of > > vendor-specific information. Each substring is=20 > terminated > > with a byte containing a null value (x'00')." > >=20 > > > - I see: > > >=20 > > > t11FcsMgmtAddr OBJECT-TYPE > > > SYNTAX SnmpAdminString > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The management address of this entry. > > > The format of this object may be based on the > > > format of the Uniform Resource Locator (URL). > > > For example, for SNMP, see RFC 4088." > > >=20 > > > So it syas "the format MAY be based on..." (my emphasis on MAY). > > > So, does that mean it may also be based on something else? > > > How do I determine what the actual format is? > > =20 > > On re-reading FC-GS-5, I see that it's required to be a=20 > URL, and it's > > the use of 4088 which is not required. So, I'll change it to: > >=20 > > The format of this object is a Uniform Resource Locator > > (URL), e.g., for SNMP, see RFC 4088." > >=20 > > > - SMICng gave a warning about the indexing of > > >=20 > > > t11FcsPortListEntry OBJECT-TYPE > > > SYNTAX T11FcsPortListEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "An entry which identifies that the port which has the > > > port name, t11FcsPortName, is in a particular list of > > > ports, which is known to a switch (identified by > > > fcmInstanceIndex and fcmSwitchIndex)." > > > INDEX { fcmInstanceIndex, fcmSwitchIndex, > > > t11FcsPortListIndex, t11FcsPortName } > > > ::=3D { t11FcsPortListTable 1 } > > >=20 > > > I read Keiths explanation, which seemed fine. But now that I am > > > reviewing the MIB module in details and try to=20 > understand things, > > > now I am no so sure this is goodness. > > >=20 > > > So, that t11FcsPortname is a value (embedded in the index) that > > > should help me find more detailed info, right? > > > So how do I find that info? I think I need to go to the > > > t11FcsPortTable, which is indexed by: > > >=20 > > > INDEX { fcmInstanceIndex, fcmSwitchIndex, > > > t11FcsFabricIndex, t11FcsPortName } > > >=20 > > > So assuming that the index values for fcmInstanceIndex, > > fcmSwitchIndex, > > > are the same in both tables, I can see that I can pick=20 > up 3 index > > > values from the list of t11FcsPortsList in the=20 > t11FcsPortsListTable. > > > But I am missing the 3rd index of the=20 > t11FcsPortnameTable, namely > > > t11FcsFabricIndex. So how am I going to wuickly pick that up? > > > Or how exactly are the tables connected/linked? > > >=20 > > > Maybe I need to study it deeper... but I'd prefer an=20 > explanation of > > > the people who created these tables with the current indexing > > schemes. > > =20 > > To generate an answer to your question, I needed to re-review the > > structure of the tables, and in doing so, I now think that=20 > the current > > structure is more open-ended/flexible than it needs to be=20 > -- having a > > less open-ended structure would make the MIB simpler. =20 > Specifically, the > > MIB currently has a table whose only purpose is to identify=20 > a list of > > (not necessarily related) ports. However, > >=20 > > - each IE is either a virtual IE attached to one virtual Fabric, or > > (if virtual Fabrics are not in use) it's a physical IE. > > - each port is either a virtual port attached to one=20 > virtual Fabric, or > > (if virtual Fabrics are not in use) it's a physical port. > > - GS-5 mentions that an IE has a "port list" and has a=20 > dotted line from > > the > > "Interconnect Element Object" to the "Port Object" in its=20 > "Figure 7 -- > > Interconnect Element and Port attributes". > > - However, all ports in an IE's port list will be attached=20 > to the same > > Fabric as that IE is attached to. In other words, the=20 > relationship > > between IEs and ports is hierarchical. > > - Thus, it would be simpler to: > >=20 > > - delete the t11FcsPortListTable, > > - delete the t11FcsIePortListIndex object, and > > - insert t11FcsIeName into the INDEX of the t11FcsPortTable, i.e., > > change the INDEX-ing of the t11FcsPortTable to be: > >=20 > > INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcsFabricIndex, > > t11FcsIeName, t11FcsPortName } > >=20 > > Increasing the INDEX clause from four to five objects makes=20 > it a little > > more cumbersome, but the length is still far short of the maximum > > length. > >=20 > > With these changes, while there will no longer be any=20 > explicit mention > > of a "port list" in the MIB, the list of ports on an IE=20 > will be all the > > rows in t11FcsPortTable which have the same values for the=20 > first four > > index objects, i.e., the value of t11FcsPortName will be=20 > the only index > > value for which they differ. So, a "port list" is=20 > (implicitly) a set of > > adjacent rows in the t11FcsPortTable. > >=20 > > David, since this is a MIB design change, may I suggest you=20 > ask the WG > > for approval of this as a separate/individual question. > >=20 > > > - for > > > =20 > > > t11FcsPortName OBJECT-TYPE > > > SYNTAX FcNameIdOrZero > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "The Port_Name (WWN) of the port for which this row > > > contains information." > > >=20 > > > I wonder if a zero value (zero length OCTET STRING) is=20 > really valid? > > > If not, then we may need to limit it with a SIZE paramter aka > > > SYNTAX FcNameIdOrZero SIZE (8 | 16) > > >=20 > > > But, I do see that in sect "6.2.3.3.1 Port Name" of document > > > http://www.t11.org/ftp/t11/pub/fc/gs-5/06-192v2.pdf, it says: > > >=20 > > > The null value for the Port Name attribute is > > > 00 00 00 00 00 00 00 00h. > > >=20 > > > So... is the SYNTAX of FcNameIdOrZero appropriate here?=20 > > > In any event, the name SIZE seems to be fixed at 8=20 > octets for the > > > PortName, so at least one would then define the syntax as: > > >=20 > > > SYNTAX FcNameIdOrZero (SIZE (8)) > > =20 > > A length of 16 is still a possibility -- section 6.2.3.3.1 refers to > > FC-FS, in which section 15 (table 66) includes one format=20 > which has a > > length of 128 (bits). > >=20 > > So, I'll chaneg it to: > > =20 > > SYNTAX FcNameIdOrZero (SIZE(8 | 16)) > >=20 > > > - For: > > >=20 > > > t11FcsPortModuleType OBJECT-TYPE > > > SYNTAX Unsigned32 (0..255) > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The port module type of this port." > > > REFERENCE > > > "ANSI INCITS xxx-200x, Fibre Channel -=20 > Generic Services 5, > > > FC-GS-5 T11/Project 1677-D/Rev 8, section 6.2.3.3.4." > > >=20 > > > It seems better to create a TC that ENUMerates the valid values? > >=20 > > The choice between using either an enumerated value, or, a=20 > numeric value > > to be looked up in another specification, is a trade-off of=20 > convenience > > versus maintenance. For something which changes=20 > frequently, it's better > > that the MIB *not* contain a list which is frequently=20 > out-of-date; for > > something which changes infrequently, it's better to have the > > convenience of enumeration. > > =20 > > Specifically, for those objects defined in this MIB as enumerations, > > when a new value is defined in T11, the new value cannot be=20 > used in the > > MIB until the MIB is updated. When the MIB syntax is=20 > Unsigned32, new > > values can be used in the MIB as soon as they are defined by T11. > >=20 > > So, we intentionally chose to specify some objects in this MIB as > > enumerations, and others as binary values, based on the frequency at > > which new values can be expected to be defined and used --=20 > not just in > > the now completed GS-5, but also in GS-6 and its successors. > >=20 > > > - For: > > >=20 > > > t11FcsPortSpeedCapab OBJECT-TYPE > > > SYNTAX OCTET STRING (SIZE (2)) > > >=20 > > > It seems that the references document and section say=20 > that it is a > > BITS > > > construct ?? > > >=20 > > > - Same for t11FcsPortOperSpeed > > =20 > > While the Capability could be a BITS, OperSpeed would only=20 > ever have one > > bit set, i.e., not a BITS. However, both of these are=20 > further examples > > of the enumerated versus numeric trade-off mentioned above.=20 > That is, > > port speed is another area where new enumerations can be=20 > expected and > > will need to be used. > >=20 > > > - For: > > >=20 > > > t11FcsPlatformName OBJECT-TYPE > > > SYNTAX OCTET STRING (SIZE (0..255)) > > >=20 > > > It seems to me that the SYNTAX better be: > > >=20 > > > SYNTAX OCTET STRING (SIZE (0 | 3..256)) > > >=20 > > > because http://www.t11.org/ftp/t11/pub/fc/gs-5/06-192v2.pdf > > > section 6.2.3.4.2 tells me: > > >=20 > > > The Platform Name attribute may be registered using the > > > protocol described in 6.2.2.3. The null value for the > > > Platform Name attribute is a zero-length Platform Name. > > >=20 > > > So maybe that is how we can get a length of zero. But I am > > > not even sure about that. It is also possible that the > > > first byte would be valued at zero. Is the format octet=20 > > > included in this case? Not clear from the PDF file for me. > > >=20 > > > If I understand the PDF file correctly, then (it speaks about > > > reserved to be of length 254-m) then there are 2 octets (1 for > > > length, one for format) plus 254 for the actual name. So that > > > would be a max size of 256 in my view. > > =20 > > Many of the format specifications in the GS-5 spec. are like this: > >=20 > > Logical Name length (m) 1 > > Logical Name m > > Reserved 255-m > >=20 > > where the aggregate length (of the three sub-fields) is 256 bytes. > >=20 > > So, the way that I interpret the Platform Name field: > >=20 > > Platform Name length (m) 1 > > Platform Name m > > Platform Name Format 1 > > Reserved 254-m > >=20 > > is similarly, to have an aggregate length is 256 bytes. =20 > Therefore, the > > correct MIB syntax is: > >=20 > > SYNTAX OCTET STRING (SIZE (0..254)) > >=20 > > where the range is the value of m. > >=20 > > > - Several objects in the t11FcsPlatformTable > > > (like t11FcsPlatformVendorId, t11FcsPlatformProductId , etc) > > > suggest (based on the SYNTAX of SnmpAdminString) that the value > > > can be an internationalized human readable string. > > > But the table 121 in the PDF file, section 6.2.3.4.5 seems to > > > tell me that they are all ASCII. So what is it? > >=20 > > It's the format as specified in section 6.2.3.4.5, which is=20 > a subset of > > SnmpAdminString, which I believe means that using=20 > SnmpAdminString as the > > syntax is fine. > >=20 > > > I know that IETF is not happy with using DisplayString, but if > > > that is what the underlying technology (outside IETF) uses, then > > > we should at least not suggest that it is different. > > > I could accept that we say "we want to be prepared for UTF-8=20 > > > strings, but for now it is ASCII as per DC-GS-5)". But it=20 > > > might be good to then explicitly state so in the DESCRIPTION > > > clauses of these objects. > > >=20 > > > At the other hand, the objects are all read-only, and so even > > > if they only present ASCII data (in UTF-8 that is exactly the > > > same), then it would still be fine. > >=20 > > How about I leave it as SnmpAdminString, and point to GS-5 for the > > definition of which characters are valid: > >=20 > > "The identifier of the vendor of this platform, in > > the format specified by FC-GS-5." > >=20 > > > I also wonder if the length for t11FcsPlatformVendorId, > > > t11FcsPlatformProductId can actually be zero, because table > > > 121 says that these are REQUIRED fields. > >=20 > > The table gives their minimum length when they are present, *but* a > > "Platform Attribute Block" doesn't necessarily contain them all. > > =20 > > > - For: > > >=20 > > > t11FcsPlatformFC4Types OBJECT-TYPE > > > SYNTAX OCTET STRING (SIZE (0 | 32)) > > >=20 > > > should be=20 > > > SYNTAX OCTET STRING (SIZE (0 | 20)) > > >=20 > > > that is what I read in table 121 of > > > http://www.t11.org/ftp/t11/pub/fc/gs-5/06-192v2.pdf > >=20 > > The text which follows the table says: > >=20 > > Supported FC-4 Types: This is an 8 word (256 bit) bit mask that > > indicates what FC-4 types are supported on this platform (see > > 5.2.3.8). > > FCP-2 (FC-4 type 08h) is represented by bit 8 of word 0.=20 > The Fabric > > Configuration Server shall not attempt validation of the=20 > FC-4 Types > > attribute, and any value shall be accepted for this attribute. > >=20 > > I think the table has a typo. > >=20 > > > - Object t11FcsNodeName. Is it supposed to represent this: > > >=20 > > > 6.2.3.4.6 Platform Node Name > > > The format of the Platform Node Name attribute, as used by > > > the Fabric Configuration Server, shall be identical to the > > > Name_Identifier format defined in FC-FS. Zero or more > > > Platform Node Name attributes may be associated with a=20 > > > Platform object. Node Names are registered to associate > > > a Platform with the Nodes. > > > This attribute may be registered using the protocol described > > > in 6.2.2.3. The null value for the platform Node Name > > > attribute is 00 00 00 00 00 00 00 00h > > >=20 > > > That last description of 8 hex zeroes for a null value seems > > > to conflict with the underlying > > >=20 > > > SYNTAX FcNameIdOrZero > > >=20 > > > that you are using in the MIB. > > =20 > > Ok, I'll change it to: > > =20 > > SYNTAX FcNameIdOrZero (SIZE(8 | 16)) > >=20 > > > - W.r.t. > > > =20 > > > t11FcsNotifyControlTable OBJECT-TYPE > > > SYNTAX SEQUENCE OF T11FcsNotifyControlEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "A table of control information for notifications > > > generated due to Fabric Configuration Server events. > > >=20 > > > Values written to objects in this table should be > > > persistent/retained over agent reboots." > > >=20 > > > I have the same questions/concerns about the "should be=20 > persistent" > > > as I had for the RSCN MIB module.=20 > > > So we can probably resolve this one in the same way (or leave it > > > if everyone thinks that I worry too much). > > =20 > > OK. > >=20 > > > - It might be good to rename the notifications (for example) > > >=20 > > > t11FcsReqRejectNotify NOTIFICATION-TYPE > > >=20 > > > from xxxxNotify to xxxxNotification. > >=20 > > I chose to use t11FcsReqRejectNotify because=20 > t11FcsReqRejectNotification > > is 33 characters long, and I think using t11FcsReqRejectNotify is a > > clearer abbreviation than t11FcsReqRejNotification. > > I guess I could go for: > >=20 > > t11FcsRqRejectNotification NOTIFICATION-TYPE > >=20 > > if you prefer. > >=20 > > > But I agree that this is really nitpicking.=20 > > > For consistency with (most) other MOB modules and notifications > > > I think my argument makes sense though. > > >=20 > > > - For the notifications (and the control there-of), it again seems > > > that the Transport Area may want us to say somehting about the > > > max number of nitifications to be expected per second/minute/xxx > > > or to provide a control varianle that a NMS can SET. > > =20 > > Their motivation is good, and is applicable to data-plane=20 > events, but > > asking for a max number per unit time for every type of=20 > notification is > > too simplistic. E.g., it's unreasonable to ask how many > > t11FcsDiscoveryCompleteNotify notifications can be generated in a > > second/minute/xxx -- how big is the network, how many=20 > virtual fabrics > > need to be discovered, how quickly can the operator ask for another > > discovery after the last one completes ?? > >=20 > > If a max rate is specified by an NMS, such that notifications can be > > suppressed due to their volume, then there needs to be some=20 > mechanism > > for the NMS to know that suppression(s) have happened/are happening, > > which means more notification-types and objects need to be defined. > > That is, it increases the complexity, which is not warranted unless > > there can really be a "flood" of notifications. > >=20 > > For notifications, like all the ones in this MIB, which are=20 > generated > > due to control plane events (and providing that none of=20 > them are able to > > start a chain-reaction), the extra complexity is not warranted. > >=20 > > _______________________________________________ > > imss mailing list > > imss@ietf.org > > https://www1.ietf.org/mailman/listinfo/imss > >=20 >=20 > _______________________________________________ > imss mailing list > imss@ietf.org > https://www1.ietf.org/mailman/listinfo/imss >=20 >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Tue Jan 02 05:53:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hGa-0008Gw-NG; Tue, 02 Jan 2007 05:53:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hGZ-0008Gp-HO for imss@ietf.org; Tue, 02 Jan 2007 05:53:11 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1hGY-0006CM-3D for imss@ietf.org; Tue, 02 Jan 2007 05:53:11 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l02AqrTj016432; Tue, 2 Jan 2007 04:52:53 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 04:52:53 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 11:52:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Jan 2007 11:52:23 +0100 Message-ID: In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550AA96D51@nl0006exch001u.nl.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: re-view: T11-FC-FABRIC-LOCK-MIB in draft-ietf-imss-fc-zs-mib-01.txt Thread-Index: AcbSmDai5TSjsL/xSFyXvB0DADt/pxbvtRIA From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 02 Jan 2007 10:52:50.0402 (UTC) FILETIME=[257AC420:01C72E5C] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: dromasca@avaya.com Subject: [imss] re-view: T11-FC-FABRIC-LOCK-MIB in draft-ietf-imss-fc-zs-mib-01.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org Here is my re-review for the frabic-lock-mib revision 01.=20 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? - 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. - 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 - 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. 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. Bert and a happy new year to all. > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > Sent: donderdag 7 september 2006 17:51 > To: Black_David@emc.com; imss@ietf.org > Cc: dromasca@avaya.com > Subject: [imss] WG last call review: T11-FC-FABRIC-LOCK-MIB=20 > in draft-ietf-imss-f c-zs-mib-00.txt >=20 > T11-FC-FABRIC-LOCK-MIB review >=20 > --------- questions/comments >=20 > - 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." >=20 > Do we have any idea as to "when such future FC-SW-nn will show > up ?? If not, is this acceptable? >=20 > - For t11FLockInitiator, in the case the SNMP, would it not be > wise/usefull to add the snmpSecuityName? >=20 > - Reading: >=20 > t11FLockRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The status of this conceptual row. >=20 > A row for which the value of t11FLockInitiatorType is > not 'snmp' cannot be deleted via this object." >=20 > 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=20 > sentence > - What is the persistence behaviour of a row created via snmp? > Probably nonVolatile? But would be good to say something > about it. >=20 > - SO I see: >=20 > t11FLockStatus OBJECT-TYPE > SYNTAX INTEGER { > active(1), > settingUp(2), > rejectFailure(3), > otherFailure(4) > } >=20 > and wonder what will happen if the lock gets released? > not sure I understand how such happens, but I would assume=20 > a lock does > not stay forever once it has become active, does it? > Does the entry disappear in that case?=20 >=20 >=20 > --------- NITS >=20 > - in t11FLockEntry DESCRIPTION clause I read 4th para: >=20 > 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 >=20 > I think I would remove "Recently" and "recent". > This document is intended for a reasonably long lifespan in the > future, no? >=20 > - REFERENCE clauses of course need to be updated. >=20 > - for t11FLockActiveGroup, the deascription clause does not say that > (if write/create-mode is supported) that a lock can also be > established. >=20 > Bert >=20 > _______________________________________________ > imss mailing list > imss@ietf.org > https://www1.ietf.org/mailman/listinfo/imss >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Tue Jan 02 06:06:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hTo-00019z-5C; Tue, 02 Jan 2007 06:06:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hTm-00016Y-UU for imss@ietf.org; Tue, 02 Jan 2007 06:06:50 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1hTl-0000z1-Iv for imss@ietf.org; Tue, 02 Jan 2007 06:06:50 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l02B6fBX005129 for ; Tue, 2 Jan 2007 06:06:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Jan 2007 13:06:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: re-view: T11-FC-FABRIC-LOCK-MIB in draft-ietf-imss-fc-zs-mib-01.txt Thread-Index: AcbSmDai5TSjsL/xSFyXvB0DADt/pxbvtRIAAAGcGuA= From: "Romascanu, Dan \(Dan\)" To: "Wijnen, Bert \(Bert\)" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [imss] RE: re-view: T11-FC-FABRIC-LOCK-MIB in draft-ietf-imss-fc-zs-mib-01.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org Thanks, Bert for the review.=20 A couple of observations: =20 =20 > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com]=20 >=20 > - 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. I would like to support this. New versions of id-nits issue warnings for such situations, so there are good chances that you will get comments later in the process if you do not add this reference now.=20 >=20 > - 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'." >=20 > 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. >=20 > Same for: t11FLockInitiatorIpAddr >=20 Are not instantiated objects in a row in a table legal at all SMI-wise?=20 Dan _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Tue Jan 02 06:59:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1iIg-0005jU-QU; Tue, 02 Jan 2007 06:59:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1iIg-0005jP-1g for imss@ietf.org; Tue, 02 Jan 2007 06:59:26 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1iIf-0006I6-D5 for imss@ietf.org; Tue, 02 Jan 2007 06:59:25 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l02BxJcs014203; Tue, 2 Jan 2007 05:59:20 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 05:59:19 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 12:58:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Jan 2007 12:58:38 +0100 Message-ID: In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550AA96D70@nl0006exch001u.nl.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: re-review: T11-FC-ZONE-SERVER-MIB in draft-ietf-imss-fc-zs-mib-01.txt Thread-Index: AcbIplbvyX18ONGZS26mqtNsXUqwOwJ5xsVQAAJOrZAW8WKagA== From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 02 Jan 2007 11:58:57.0881 (UTC) FILETIME=[62480490:01C72E65] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Cc: dromasca@avaya.com Subject: [imss] re-review: T11-FC-ZONE-SERVER-MIB in draft-ietf-imss-fc-zs-mib-01.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org 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)=20 > Sent: donderdag 7 september 2006 23:17 > To: Black_David@emc.com; imss@ietf.org > Cc: dromasca@avaya.com > Subject: WG last call review: T11-FC-ZONE-SERVER-MIB in=20 > draft-ietf-imss-fc-zs-mib-00.txt >=20 > T11-FC-ZONE-SERVER-MIB >=20 > --------- questions/comments >=20 > - Would it be better to rename T11ZoningName to T11ZsZoningName? > This for naming consistency and avoiding possible future name > clashes. >=20 > - 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'." > =20 > will fail with what? I assume/think 'inconsistentValue'. > Might be good to state so, to ensure proper implementation. >=20 > - Now that I see t11ZsServerReasonCode, I wonder if the 2nd > para in the DESCRIPTION clause would also make sense for > the t11FLockRejectReasonCode object >=20 > - do the SIZE for t11ZsServerReasonCodeExp > and t11ZsServerReasonVendorCode possibly also make sense for > t11FLockRejectReasonCodeExp, t11FLockRejectReasonVendorCode > that is allowing for a SIZE of zero? > =20 > - I wonder why this >=20 > t11ZsServerDefaultZoneSetting OBJECT-TYPE > SYNTAX INTEGER { > permit(1), > deny(2) > } >=20 > 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. >=20 > For t11ZsServerMergeControlSetting it is less obvious, but the > same question could be asked I guess. >=20 > - 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. >=20 > The Zone Set can be renamed by setting this object > to a new value." >=20 > and wonder if the rename can also be done while the row is in > 'active' state !!?? >=20 > - I am not sure I understand this: >=20 > 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). >=20 > 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. >=20 > 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 } > ::=3D { t11ZsSetTable 1 } >=20 > 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. >=20 > 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. > =20 > 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. >=20 > - I have the same/similar question for t11ZsZoneEntry >=20 > - Can t11ZsZoneAttribBlock be changed while row is active? >=20 > such questions can be asked for more read-write/read-create > objects in this MIB module. I won't keep repeating. >=20 > - 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? >=20 > - 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 ?? >=20 > 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? >=20 > - 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. >=20 > - 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). >=20 > - For namingconsistency in: > T11ZsActiveZoneEntry ::=3D SEQUENCE { > t11ZsActiveZoneIndex Unsigned32, > t11ZsActiveZoneName T11ZoningName, > t11ZsActiveBroadcast TruthValue, > t11ZsActiveHardZoning TruthValue > } > I would insert a "Zone" before "Broadcast" and before "Hardzoning" >=20 > 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. >=20 > - t11ZsActiveBroadcast and t11ZsActiveHardZoning both have in > their DESCRIPTION clauses: > This object is only instantiated in Enhanced mode." >=20 > would we not want to specify that in a MODULE-COMPLIANCE for > basic mode and one for enhanced mode? >=20 >=20 >=20 > --------- NITS/TYPOs >=20 > - In one but last para of DESCRIPTION clause of MODULE-IDENTITY >=20 > When this MIB is used for Basic Zoning Management, the same > set of MIBs objects as used for Enhanced mode are used to >=20 > s/MIBs objects/MIB objects/ >=20 > - 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=20 > the TC as a SYNTAX. >=20 > - t11ZsServerCapabilityObject > I think I would rename zonesetDb(1) to zoneSetDb(1) > but this is pretty subjective taste of course. >=20 > - last para of description clasue of t11ZsServerDatabaseStorageType >=20 > This value of this object is a... >=20 > s/This/The/ ?? > =20 > - For t11ZsAttribType maybe add "other values reserved" in the=20 > DESCRIPTION clause. I went looking it up, because in an=20 > earlier object we had E0-EF as Vendor specific. So I thought > that might also be the case here. But the text in the=20 > REFERENCEd docment/section told me they are reserved. >=20 > - 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. >=20 > 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. >=20 > The value of this object when read is always 0." >=20 > 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=20 > SYNTAX Unsigned32 (0 | 1..4294967295) > but that is subjective taste I guess. >=20 > - similarly, for >=20 > t11ZsFabricIndex OBJECT-TYPE > SYNTAX Unsigned32 (0..4096) >=20 > I think I would use =20 >=20 > SYNTAX Unsigned32 (0..4095 | 4096) >=20 > to indicate that 4096 has special meaning. >=20 > Maybe I would even create a=20 >=20 > T11FabricIndexOrAll ::=3D TEXTUAL-CONVENTION >=20 > 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. >=20 > - I personally prefer to name notifications xxxNotification instead > of naming them xxxNotify. But I admit that that is subjective. >=20 >=20 > Bert >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Tue Jan 02 07:04:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1iNQ-0001gU-16; Tue, 02 Jan 2007 07:04:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1iNO-0001dS-Kc for imss@ietf.org; Tue, 02 Jan 2007 07:04:18 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1iNL-0006vL-5a for imss@ietf.org; Tue, 02 Jan 2007 07:04:18 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l02C48sI018269; Tue, 2 Jan 2007 06:04:08 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 06:04:08 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 13:04:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [imss] RE: re-view: T11-FC-FABRIC-LOCK-MIB indraft-ietf-imss-fc-zs-mib-01.txt Date: Tue, 2 Jan 2007 13:03:35 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [imss] RE: re-view: T11-FC-FABRIC-LOCK-MIB indraft-ietf-imss-fc-zs-mib-01.txt Thread-Index: AcbSmDai5TSjsL/xSFyXvB0DADt/pxbvtRIAAAGcGuAAAhhWkA== From: "Wijnen, Bert \(Bert\)" To: "Romascanu, Dan \(Dan\)" , X-OriginalArrivalTime: 02 Jan 2007 12:04:06.0816 (UTC) FILETIME=[1A6BC200:01C72E66] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org Inline=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: dinsdag 2 januari 2007 12:07 > To: Wijnen, Bert (Bert); imss@ietf.org > Subject: [imss] RE: re-view: T11-FC-FABRIC-LOCK-MIB=20 > indraft-ietf-imss-fc-zs-mib-01.txt >=20 > Thanks, Bert for the review.=20 >=20 > A couple of observations: >=20 >=20 >=20 > =20 > =20 >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > >=20 > > - 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. >=20 > I would like to support this. New versions of id-nits issue=20 > warnings for such situations, so there are good chances that=20 > you will get comments later in the process if you do not add=20 > this reference now.=20 >=20 > >=20 > > - 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'." > >=20 > > 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. > >=20 > > Same for: t11FLockInitiatorIpAddr > >=20 >=20 > Are not instantiated objects in a row in a table legal at all=20 > SMI-wise?=20 >=20 Yes, I believe they are legal. a GET request would return a=20 noSuchInstance. But I know that many NM APPS have trouble with the HETNEXT (or GETBULK) when such entries are just skipped. Bert > Dan _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Tue Jan 02 09:50:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1kyS-00028t-7X; Tue, 02 Jan 2007 09:50:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1kyQ-00028n-Mb for imss@ietf.org; Tue, 02 Jan 2007 09:50:42 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1kyO-0005gD-1B for imss@ietf.org; Tue, 02 Jan 2007 09:50:42 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 02 Jan 2007 06:50:39 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l02EodV3000940; Tue, 2 Jan 2007 06:50:39 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l02EocUH012955; Tue, 2 Jan 2007 06:50:38 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA22514; Tue, 2 Jan 2007 06:50:23 -0800 (PST) From: Keith McCloghrie Message-Id: <200701021450.GAA22514@cisco.com> Subject: Re: [imss] re-view: T11-FC-FABRIC-LOCK-MIB in To: bwijnen@alcatel-lucent.com Date: Tue, 2 Jan 2007 06:50:23 -0800 (PST) In-Reply-To: from "Wijnen, Bert \(Bert\)" at Jan 02, 2007 11:52:23 AM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8976; t=1167749439; x=1168613439; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kzm@cisco.com; z=From:=20Keith=20McCloghrie=20 |Subject:=20Re=3A=20[imss]=20re-view=3A=20T11-FC-FABRIC-LOCK-MIB=20in |Sender:=20; bh=7FwbyAxBCQKjiAkH6nhhT9Xt8jNhQikvypIZR4+XDFA=; b=YWlhF74Yl6KX2GUSypwsIsv/edcr7G76ZxROPTvbf3CrPrewf7QSpdySlbJFsTBO1MRX33zl pGzGMDfAXJnLlD7rCUCrvH8y7ICOIpn/YSZkbZ11HdZQQpziVYXnt6Mm; Authentication-Results: sj-dkim-7; header.From=kzm@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: imss@ietf.org, 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org > 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 imss@ietf.org 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:bwijnen@lucent.com] > > Sent: donderdag 7 september 2006 17:51 > > To: Black_David@emc.com; imss@ietf.org > > Cc: dromasca@avaya.com > > 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 > > imss@ietf.org > > https://www1.ietf.org/mailman/listinfo/imss > > > > _______________________________________________ > imss mailing list > imss@ietf.org > https://www1.ietf.org/mailman/listinfo/imss > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Tue Jan 02 10:20:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1lR5-0003dB-NG; Tue, 02 Jan 2007 10:20:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1lR4-0003d1-8e for imss@ietf.org; Tue, 02 Jan 2007 10:20:18 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1lR2-0003kT-QS for imss@ietf.org; Tue, 02 Jan 2007 10:20:18 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l02FK5Rn023878; Tue, 2 Jan 2007 09:20:10 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 09:20:08 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 16:15:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [imss] re-view: T11-FC-FABRIC-LOCK-MIB in Date: Tue, 2 Jan 2007 16:19:55 +0100 Message-ID: In-Reply-To: <200701021450.GAA22514@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [imss] re-view: T11-FC-FABRIC-LOCK-MIB in Thread-Index: AccufWTB9jvHZ3VnRlWAM0gfAndD0QAA876w From: "Wijnen, Bert \(Bert\)" To: "Keith McCloghrie" X-OriginalArrivalTime: 02 Jan 2007 15:15:11.0082 (UTC) FILETIME=[CBA7ECA0:01C72E80] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: imss@ietf.org, 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org Inline=20 > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com]=20 > Sent: dinsdag 2 januari 2007 15:50 > To: Wijnen, Bert (Bert) > Cc: imss@ietf.org; dromasca@avaya.com > Subject: Re: [imss] re-view: T11-FC-FABRIC-LOCK-MIB in >=20 > > Here is my re-review for the frabic-lock-mib revision 01.=20 >=20 > Thanks. >=20 > > My original review for revision zero is attached at the bottom. > >=20 > > None of the below is fatal, but pls consider my comments. > >=20 > > Open issues/concerns: > >=20 > > - I see (in the fabric-loc MIB module): > >=20 > > TBD - reference for assignment of Application_ID for > > the benefit of this MIB module." > >=20 > > 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? >=20 > What the referenced document would say *was* decided; what=20 > was undecided was the name/number of the referenced document.=20 > If you recall, David's message to imss@ietf.org on 5 Oct 2006 stated: >=20 > (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): >=20 > 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. >=20 > The MIB should also state that this value, FF (hex), will > appear in FC-SW-5. >=20 > I thought it was appropriate to include the FC-SW-5 document=20 > in the REFERENCE clause since it was expected within the=20 > following few months, but I wanted to get the update done and=20 > re-reviewed without waiting for it. Since then, the document=20 > was published on 22 November, now available at:=20 > 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. >=20 great > > - 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. > =20 > OK. >=20 > > - 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'." > >=20 > > 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. > >=20 > > Same for: t11FLockInitiatorIpAddr > =20 > Whether it will be better is debatable, but I'll change it if=20 > that's what you want. >=20 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. > > - 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 > >=20 > > 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. > =20 > The same phrase "request ... caused this lock to be=20 > established" is used in the DESCRIPTION of=20 > t11FLockInitiatorType which can have several values:=20 > other(1), ssb(2), cli(3), snmp(4). For several of these=20 > types, the initiator may or may not have an IP address; if it=20 > does, then t11FLockInitiatorIpAddr is that IP address. Note=20 > that the term "this lock" > is not ambiguous because t11FLockEntry's DESCRIPTION begins: >=20 > "Each entry contains information specific to a current > fabric lock setup by a particular 'managing' switch on a > particular fabric.=20 >=20 > So, I don't believe there's any ambiguity. Rather, I think=20 > you're asking the question because the phrase, "request=20 > caused this lock to be established", refers only implicitly=20 > to the *same* request that t11FLockInitiatorType refers to. =20 > So, to make it more explicit, I propose to change: >=20 > "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." >=20 Helps (at least me). Thanks. > > Remaining NITs, just in case you want to consider them. > >=20 > > - I think I would change: > >=20 > > REVISION "200609120000Z" > > DESCRIPTION > > "Initial version of this MIB." > >=20 > > into: > >=20 > > REVISION "200609120000Z" > > DESCRIPTION > > "Initial version of this MIB, published as RFC yyyy." > >=20 > > - I'd also add the IETF IMSS WG to the ORGANIZATION clause. > =20 > OK. >=20 > > and a happy new year to all. > =20 > Likewise from me. >=20 > Keith. >=20 Bert _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Wed Jan 03 14:16:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2BbU-0002VG-04; Wed, 03 Jan 2007 14:16:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2BbS-0002V0-NY for imss@ietf.org; Wed, 03 Jan 2007 14:16:46 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2BbS-0005LT-0f for imss@ietf.org; Wed, 03 Jan 2007 14:16:46 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 03 Jan 2007 11:16:45 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l03JGjW9001564; Wed, 3 Jan 2007 11:16:45 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l03JGjIl002476; Wed, 3 Jan 2007 11:16:45 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA04560; Wed, 3 Jan 2007 11:16:37 -0800 (PST) From: Keith McCloghrie Message-Id: <200701031916.LAA04560@cisco.com> Subject: Re: [imss] re-review: T11-FC-ZONE-SERVER-MIB in To: bwijnen@alcatel-lucent.com Date: Wed, 3 Jan 2007 11:16:37 -0800 (PST) In-Reply-To: from "Wijnen, Bert \(Bert\)" at Jan 02, 2007 12:58:38 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: v=0.5; a=rsa-sha256; q=dns/txt; l=13260; t=1167851805; x=1168715805; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kzm@cisco.com; z=From:=20Keith=20McCloghrie=20 |Subject:=20Re=3A=20[imss]=20re-review=3A=20T11-FC-ZONE-SERVER-MIB=20in |Sender:=20; bh=uHYtuMSUffyWMDc7SYpOVqJOAVi9K6U1pliqz0eDYTw=; b=LflTFl+Sn6iqZYiwiUEuFN2BQTbfLrtL0Mu979776KWjqzIJaCHaTJyrH5PRxgy5EV2fChiw yeCPagW4JAO74xJYeMJLuCzjs79ON3OEf/imhyY2BQVux/WfGuEdlVi3; Authentication-Results: sj-dkim-6; header.From=kzm@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: imss@ietf.org, 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org > 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_David@emc.com; imss@ietf.org > > Cc: dromasca@avaya.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 > imss@ietf.org > https://www1.ietf.org/mailman/listinfo/imss > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Wed Jan 03 18:31:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2FZz-0001Bo-UY; Wed, 03 Jan 2007 18:31:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2FZy-00018M-90 for imss@ietf.org; Wed, 03 Jan 2007 18:31:30 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2FZv-00081q-Tq for imss@ietf.org; Wed, 03 Jan 2007 18:31:30 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l03NVFT8000219; Wed, 3 Jan 2007 17:31:15 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 17:31:15 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 00:31:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [imss] re-review: T11-FC-ZONE-SERVER-MIB in Date: Thu, 4 Jan 2007 00:31:05 +0100 Message-ID: In-Reply-To: <200701031916.LAA04560@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [imss] re-review: T11-FC-ZONE-SERVER-MIB in Thread-Index: Accva81esVn+1GhNRB+9u7MWII2bYAAIyhKw From: "Wijnen, Bert \(Bert\)" To: "Keith McCloghrie" X-OriginalArrivalTime: 03 Jan 2007 23:31:13.0679 (UTC) FILETIME=[41F591F0:01C72F8F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: imss@ietf.org, 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org W.r.t.=20 > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com]=20 > Sent: woensdag 3 januari 2007 20:17 > To: Wijnen, Bert (Bert) > Cc: imss@ietf.org; dromasca@avaya.com > Subject: Re: [imss] re-review: T11-FC-ZONE-SERVER-MIB in >=20 > > - 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. > >=20 > > 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." > >=20 > > Then it seems to me that the SYNTAX should show at least=20 > a size of 4. > > So I would make it > > SYNTAX OCTET STRING (SIZE (4..252)) > >=20 > > Or do I not correctly understand the DESCRIPTION clause? In which > > case it might be good to clarify it. > =20 > The length is: a) at least 4 bytes and b) a multiple of four.=20 > So, if the SYNTAX needs to exclude lengths of 0, 1, 2, and 3, > then for consistency, it also needs to exclude lengths of=20 > 4n+i where 0 < i < 4. > However, that would require a SIZE clause of more than 300=20 > characters (with normal spacing) or 200 characters (omitting=20 > all space characters), i.e., either five lines in an RFC, or=20 > an unreadable three lines in an RFC. So that it is both=20 > readable and consistent, I suggest that it's better to leave it as-is. >=20 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=20 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 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Tue Jan 09 09:33:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4I2F-0003my-Rq; Tue, 09 Jan 2007 09:33:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4I2E-0003dx-5m for imss@ietf.org; Tue, 09 Jan 2007 09:33:06 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4I2B-0006vI-6J for imss@ietf.org; Tue, 09 Jan 2007 09:33:06 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 09 Jan 2007 06:33:02 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l09EX2nG031656 for ; Tue, 9 Jan 2007 06:33:02 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l09EX2lb000622 for ; Tue, 9 Jan 2007 06:33:02 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA07883 for imss@ietf.org; Tue, 9 Jan 2007 06:32:54 -0800 (PST) From: Keith McCloghrie Message-Id: <200701091432.GAA07883@cisco.com> To: imss@ietf.org Date: Tue, 9 Jan 2007 06:32:54 -0800 (PST) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=719; t=1168353182; x=1169217182; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kzm@cisco.com; z=From:=20Keith=20McCloghrie=20 |Subject:=20Submission=20of=20two=20updated=20I-Ds=20(fwd) |Sender:=20; bh=rJS0TkP3xm6Q0JTTZQIo2LtoEe8ItH41tpAtt6afXaI=; b=m1sdIdQhafUvszf0aUcAll40jwRZfDPOA8ZXFdC6HwGgqzTB5gpS5QEEBLJkY7bKWp9EiAiK NHlmdmDVNIRxVewJHIXoowBuLJpV+g2brTT+OrlRNtSonQB6+yoXAHPN; Authentication-Results: sj-dkim-6; header.From=kzm@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [imss] Submission of two updated I-Ds (fwd) X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org FYI. Keith. -------------- Forwarded message: > From: Keith McCloghrie > Message-Id: <200701091428.GAA07210@cisco.com> > Subject: Submission of two updated I-Ds > To: internet-drafts@ietf.org (Internet Drafts Submissions) > Date: Tue, 9 Jan 2007 06:28:44 -0800 (PST) > Cc: Black_David@emc.com, bwijnen@alcatel-lucent.com, dromasca@avaya.com, > kzm@cisco.com (Keith McCloghrie), cds (Claudio Desanti), > hvivek (H Vivek) > > Please accept the following as submissions of updated Internet-Drafts: > > ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-fcs-mib-02.txt > and > ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-zs-mib-02.txt > > Thanks, > Keith. > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Tue Jan 09 18:50:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4QjH-0006vq-VM; Tue, 09 Jan 2007 18:50:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4QjD-0006vE-9L; Tue, 09 Jan 2007 18:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4QjD-0000GK-1M; Tue, 09 Jan 2007 18:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6F0B826E9D; Tue, 9 Jan 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H4QjC-00045p-Ad; Tue, 09 Jan 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 09 Jan 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: imss@ietf.org Subject: [imss] I-D ACTION:draft-ietf-imss-fc-fcs-mib-02.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet and Management Support for Storage Working Group of the IETF. Title : Fibre-Channel Fabric Configuration Server MIB Author(s) : C. DeSanti, et al. Filename : draft-ietf-imss-fc-fcs-mib-02.txt Pages : 55 Date : 2007-1-9 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fabric Configuration Server function of a Fibre Channel network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-fcs-mib-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imss-fc-fcs-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imss-fc-fcs-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-9153607.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imss-fc-fcs-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imss-fc-fcs-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-9153607.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss --NextPart-- From imss-bounces@ietf.org Tue Jan 09 18:50:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Qjm-0007Yo-7N; Tue, 09 Jan 2007 18:50:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Qjj-0007YB-Bk; Tue, 09 Jan 2007 18:50:35 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4Qjh-0003lr-1g; Tue, 09 Jan 2007 18:50:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id BD44717600; Tue, 9 Jan 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H4QjC-00045s-BC; Tue, 09 Jan 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 09 Jan 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: imss@ietf.org Subject: [imss] I-D ACTION:draft-ietf-imss-fc-zs-mib-02.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet and Management Support for Storage Working Group of the IETF. Title : Fibre-Channel Zone Server MIB Author(s) : C. DeSanti, et al. Filename : draft-ietf-imss-fc-zs-mib-02.txt Pages : 93 Date : 2007-1-9 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel Zone Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-zs-mib-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imss-fc-zs-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imss-fc-zs-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-9153746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imss-fc-zs-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imss-fc-zs-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-9153746.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss --NextPart-- From imss-bounces@ietf.org Thu Jan 18 20:33:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7icp-0000EZ-LY; Thu, 18 Jan 2007 20:33:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7icp-0000EU-BL for imss@ietf.org; Thu, 18 Jan 2007 20:33:03 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7icn-0001QN-UZ for imss@ietf.org; Thu, 18 Jan 2007 20:33:03 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0J1X0H3022685; Thu, 18 Jan 2007 19:33:00 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 19:33:00 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 02:32:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [imss] Submission of two updated I-Ds (fwd) Date: Fri, 19 Jan 2007 02:31:59 +0100 Message-ID: In-Reply-To: <200701091432.GAA07883@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [imss] Submission of two updated I-Ds (fwd) Thread-Index: Accz+x9CAXoJCoklQ0a/u4g0faCAdgHbllVw From: "Wijnen, Bert \(Bert\)" To: "Keith McCloghrie" , X-OriginalArrivalTime: 19 Jan 2007 01:32:58.0084 (UTC) FILETIME=[BFEB9240:01C73B69] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org Keith, WG chair and AD, I did check for both documents the revision 02, and I am now happy (as MIB doctor) with these documents. Bert > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com]=20 > Sent: dinsdag 9 januari 2007 6:33 > To: imss@ietf.org > Subject: [imss] Submission of two updated I-Ds (fwd) >=20 > FYI. >=20 > Keith. > -------------- > Forwarded message: > > From: Keith McCloghrie > > Message-Id: <200701091428.GAA07210@cisco.com> > > Subject: Submission of two updated I-Ds > > To: internet-drafts@ietf.org (Internet Drafts Submissions) > > Date: Tue, 9 Jan 2007 06:28:44 -0800 (PST) > > Cc: Black_David@emc.com, bwijnen@alcatel-lucent.com,=20 > dromasca@avaya.com, > > kzm@cisco.com (Keith McCloghrie), cds (Claudio Desanti), > > hvivek (H Vivek) > >=20 > > Please accept the following as submissions of updated=20 > Internet-Drafts: > >=20 > > =20 > ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-fcs-mib-02.txt > > and > > ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-zs-mib-02.txt > >=20 > > Thanks, > > Keith. > >=20 >=20 > _______________________________________________ > imss mailing list > imss@ietf.org > https://www1.ietf.org/mailman/listinfo/imss >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Fri Jan 19 21:27:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H85x1-00066l-6q; Fri, 19 Jan 2007 21:27:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H85x0-00064u-44 for imss@ietf.org; Fri, 19 Jan 2007 21:27:26 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H85wy-0004Rx-Q6 for imss@ietf.org; Fri, 19 Jan 2007 21:27:26 -0500 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id l0K2ROvB006725 for ; Fri, 19 Jan 2007 21:27:24 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0K2RL6w018089 for ; Fri, 19 Jan 2007 21:27:23 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 21:27:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [imss] Submission of two updated I-Ds (fwd) Date: Fri, 19 Jan 2007 21:27:20 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [imss] Submission of two updated I-Ds (fwd) Thread-Index: Accz+x9CAXoJCoklQ0a/u4g0faCAdgHbllVwADQUWDA= References: <200701091432.GAA07883@cisco.com> To: X-OriginalArrivalTime: 20 Jan 2007 02:27:20.0983 (UTC) FILETIME=[832C3270:01C73C3A] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.19.175932 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_PHRASE_24 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org Great, thanks - this completes WG last call comment resolution on all three MIBs: Fibre Channel Registered State Change Notification (RSCN) MIB draft-ietf-imss-fc-rscn-mib-00.txt Fibre-Channel Fabric Configuration Server MIB draft-ietf-imss-fc-fcs-mib-00.txt Fibre-Channel Zone Server MIB draft-ietf-imss-fc-zs-mib-00.txt Requests to publish these as RFCs will be coming shortly (and I will send copies to the WG list. Many thanks to Bert and everyone else who contributed, --David (imss WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com]=20 > Sent: Thursday, January 18, 2007 8:32 PM > To: Keith McCloghrie; imss@ietf.org > Subject: RE: [imss] Submission of two updated I-Ds (fwd) >=20 > Keith, WG chair and AD, >=20 > I did check for both documents the revision 02, > and I am now happy (as MIB doctor) with these documents. >=20 > Bert >=20 > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com]=20 > > Sent: dinsdag 9 januari 2007 6:33 > > To: imss@ietf.org > > Subject: [imss] Submission of two updated I-Ds (fwd) > >=20 > > FYI. > >=20 > > Keith. > > -------------- > > Forwarded message: > > > From: Keith McCloghrie > > > Message-Id: <200701091428.GAA07210@cisco.com> > > > Subject: Submission of two updated I-Ds > > > To: internet-drafts@ietf.org (Internet Drafts Submissions) > > > Date: Tue, 9 Jan 2007 06:28:44 -0800 (PST) > > > Cc: Black_David@emc.com, bwijnen@alcatel-lucent.com,=20 > > dromasca@avaya.com, > > > kzm@cisco.com (Keith McCloghrie), cds (Claudio Desanti), > > > hvivek (H Vivek) > > >=20 > > > Please accept the following as submissions of updated=20 > > Internet-Drafts: > > >=20 > > > =20 > > ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-fcs-mib-02.txt > > > and > > > =20 > ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-zs-mib-02.txt > > >=20 > > > Thanks, > > > Keith. > > >=20 > >=20 > > _______________________________________________ > > imss mailing list > > imss@ietf.org > > https://www1.ietf.org/mailman/listinfo/imss > >=20 >=20 > _______________________________________________ > imss mailing list > imss@ietf.org > https://www1.ietf.org/mailman/listinfo/imss >=20 >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Tue Jan 23 18:43:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9VIA-0006q2-Dz; Tue, 23 Jan 2007 18:43:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9VI9-0006or-4J for imss@ietf.org; Tue, 23 Jan 2007 18:43:05 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9VI8-0003Vv-MI for imss@ietf.org; Tue, 23 Jan 2007 18:43:05 -0500 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0NNh4QX025107 for ; Tue, 23 Jan 2007 18:43:04 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0NNgYcG016661 for ; Tue, 23 Jan 2007 18:43:02 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 18:42:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jan 2007 18:42:36 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publication Requested: FCS MIB Thread-Index: Acc/SCjw0f+FQuOgSI6fDzLNj1O+ww== To: X-OriginalArrivalTime: 23 Jan 2007 23:42:36.0646 (UTC) FILETIME=[294D1060:01C73F48] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.23.151432 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: Black_David@emc.com Subject: [imss] Publication Requested: FCS MIB X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org RFC publication has just been requested for the FCS MIB draft. The Doc Shepherding process (cf. draft-ietf-proto-wgchair-doc-shepherding-08.txt) is being used. Here is the Document Shepherd writeup: Document Shepherd writeup: Fibre-Channel Fabric Configuration Server MIB draft-ietf-imss-fc-fcs-mib-02.txt Requested Publication Status: Proposed Standard ------------------------------------------------------------------------ (1.a) Who is the Document Shepherd for this document? David L. Black (imss WG Chair) Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes, but an RFC Editor Note should be used to make two changes to text in Section 1 that is not appropriate for a Proposed Standard RFC: (A) Make the following change: OLD This memo was previously approved by T11.5 (http://www.t11.org); it is currently a work item of the IETF's IMSS working group. NEW This memo was previously approved by T11.5 (http://www.t11.org), and has been further developed in the IETF's IMSS working group. (B) Remove the following paragraph, leaving the RFC 2119 statement that occurs immediately after it: ----- This memo includes boilerplate which uses only one of the following terms, but is nevertheless required to mention all of the keywords in the following statement: ----- (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Yes. This document has been reviewed by Fibre Channel experts in Technical Committee T11 (Fibre Channel standards organization) in addition to members of the IMSS WG, and the IMSS WG's MIB expert. Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? An OPS Area MIB Doctor review was performed during WG Last Call. There does not appear to be a need for additional external reviews. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It's hard to distinguish the two cases due to somewhat thin WG membership. There is solid support for this document both in the WG and from T11. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Yes. The idnits checker (1.124) finds a couple of "non-RFC3330-compliant IPv4 addresses" - this is not an actual problem because these strings are actually section references into other standards, e.g., "ANSI INCITS 427-2006, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4". Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes, a MIB Doctor review occurred during WG Last Call, and the MIB Doctor (Bert Wijnen) is satisfied with this draft. (1.h) Has the document split its references into normative and informative? Yes. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? No, but there is an informative reference to an Internet-Draft: [SCSI-MIB] Hallak-Stamler, M., Bakke, M., Lederman, Y., Krueger, M., and K. McCloghrie, "Definition of Managed Objects for SCSI Entities", Internet-Draft (draft-ietf-ips-scsi-mib-nn.txt), work-in-progress. The SCSI-MIB has been published as RFC 4455 Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. No. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? Yes, and the draft contains an explicit instruction to the RFC Editor on where to insert the IANA assigned MIB number from the mib-2 subtree. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? N/A. If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. N/A. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? N/A. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes, the Document Shepherd has relied on MIB Doctor review for the MIB checks. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fabric Configuration Server function of a Fibre Channel network. Working Group Summary This document was reviewed in the IMSS WG and in Technical Committee T11 (the official Fibre Channel standards body). T11 voted to recommend a prior version of this document to the IETF. Document Quality The protocol has been reviewed for the IMSS WG by Keith McCloghrie. The protocol has been reviewed for the IESG by David L. Black (imss WG Chair). The MIB Doctor Review was performed by Bert Wijnen resulting in a simplification of the table structure in one area of the MIB, and correction of a large number of SMI syntax and documentation issues. The WG agreed with the proposed table structure simplification, and the current version of the draft reflects that simplification. Personnel Document Shepherd: David L. Black Responsible Area Director: Dan Romascanu ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Tue Jan 23 18:45:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9VK3-0007nS-7H; Tue, 23 Jan 2007 18:45:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9VK1-0007nJ-AE for imss@ietf.org; Tue, 23 Jan 2007 18:45:01 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9VJz-0003kp-Rd for imss@ietf.org; Tue, 23 Jan 2007 18:45:01 -0500 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id l0NNixLI025977 for ; Tue, 23 Jan 2007 18:44:59 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0NNigfW028466 for ; Tue, 23 Jan 2007 18:44:57 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 18:44:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jan 2007 18:44:43 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publication Requested: RSCN MIB Thread-Index: Acc/SHTwZ5f0Y71VT7i/0UGWY2XJ0Q== To: X-OriginalArrivalTime: 23 Jan 2007 23:44:44.0131 (UTC) FILETIME=[7549BB30:01C73F48] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.23.151432 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: Black_David@emc.com Subject: [imss] Publication Requested: RSCN MIB X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org RFC publication has just been requested for the RSCN MIB draft. The Doc Shepherding process (cf. draft-ietf-proto-wgchair-doc-shepherding-08.txt) is being used. Here is the Document Shepherd writeup: Document Shepherd writeup: Fibre Channel Registered State Change Notification (RSCN) MIB draft-ietf-imss-fc-rscn-mib-02.txt Requested Publication Status: Proposed Standard ------------------------------------------------------------------------ (1.a) Who is the Document Shepherd for this document? David L. Black (imss WG Chair) Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes, but an RFC Editor Note should be used to make two changes to text in Section 1 that is not appropriate for a Proposed Standard RFC: (A) Make the following change: OLD This memo was previously approved by T11.5 (http://www.t11.org); it is currently a work item of the IETF's IMSS working group. NEW This memo was previously approved by T11.5 (http://www.t11.org), and has been further developed in the IETF's IMSS working group. (B) Remove the following paragraph, leaving the RFC 2119 statement that occurs immediately after it: ----- This memo includes boilerplate which uses only one of the following terms, but is nevertheless required to mention all of the keywords in the following statement: ----- (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Yes. This document has been reviewed by Fibre Channel experts in Technical Committee T11 (Fibre Channel standards organization) in addition to members of the IMSS WG, and the IMSS WG's MIB expert. Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? An OPS Area MIB Doctor review was performed during WG Last Call. There does not appear to be a need for additional external reviews. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It's hard to distinguish the two cases due to somewhat thin WG membership. There is solid support for this document both in the WG and from T11. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Yes. The idnits checker (1.124) says that the RFC 3978 boilerplate in this draft is slightly out of date, but it is still acceptable. Any revision of this draft will need to use the new RFC 4748 boilerplate. This draft was submitted in 2006 and hence has a 2006 copyright date. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes, a MIB Doctor review occurred during WG Last Call, and the MIB Doctor (Bert Wijnen) is satisfied with this version of the draft. (1.h) Has the document split its references into normative and informative? Yes. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Yes, but the normative reference is to a document in another standards body, namely the FC-LS standard in INCITS Technical Committee T11: [FC-LS] "Fibre Channel - Link Services (FC-LS)", ANSI INCITS xxx-200n, Rev 1.61, http://www.t11.org/t11/stat.nsf/upnum/1620-d, November 2006. As of January 23, 2007, the designator "INCITS 433" has been assigned to the FC-LS standard, and the standard is in an INCITS public review that that will end on February 19, 2007. It is likely that FC-LS will be published as ANSI INCITS 433-2007 during 2007, but it will be necessary to verify this and enter the correct reference prior to publication of the RFC. RFC publication will have to be delayed until FC-LS is published as is the usual procedure for normative references. While the RFC Editor may not be able to track FC-LS as an external normative reference, there is an explicit Note to the RFC Editor in the draft saying that this reference update is necessary. That Note should cause the RFC Editor to query the authors and the WG chair about what is to be done, at which point any necessary wait for publication of FC-LS can be imposed. Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. No. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? Yes, and the draft contains an explicit instruction to the RFC Editor on where to insert the IANA assigned MIB number from the mib-2 subtree. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? N/A. If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. N/A. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? N/A. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes, the Document Shepherd has relied on MIB Doctor review for the MIB checks. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the management of Fibre Channel's Registered State Change Notifications (RSCNs). Working Group Summary This document was reviewed in the IMSS WG and in Technical Committee T11 (the official Fibre Channel standards body). T11 voted to recommend a prior version of this document to the IETF. Document Quality The protocol has been reviewed for the IMSS WG by Keith McCloghrie. The protocol has been reviewed for the IESG by David L. Black (imss WG Chair). The MIB Doctor Review performed by Bert Wijnen found a few issues in SMI syntax and documentation, as well as the FC-LS reference issue described above. Personnel Document Shepherd: David L. Black Responsible Area Director: Dan Romascanu ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Tue Jan 23 19:13:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Vlk-0003wP-B0; Tue, 23 Jan 2007 19:13:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Vlj-0003wK-O9 for imss@ietf.org; Tue, 23 Jan 2007 19:13:39 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Vli-0000Eh-GX for imss@ietf.org; Tue, 23 Jan 2007 19:13:39 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id l0O0Da5A011857 for ; Tue, 23 Jan 2007 19:13:38 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0O0Cuvn002828 for ; Tue, 23 Jan 2007 19:13:35 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 19:13:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jan 2007 19:13:24 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ZS MIB draft, -03 version coming Thread-Index: Acc/THaNuv84fmipSeGOW/HcWh5Yxw== To: X-OriginalArrivalTime: 24 Jan 2007 00:13:24.0736 (UTC) FILETIME=[76D93800:01C73F4C] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.23.155432 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Black_David@emc.com Subject: [imss] ZS MIB draft, -03 version coming X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org A -03 version of the ZS MIB draft (draft-ietf-imss-fc-zs-mib) will appear shortly; this message explains why. The current version of the draft contains a normative reference to a T11 working version of FC-SW-5. In your WG chair's expert opinion (your WG chair also chairs a working group in T11), FC-SW-5 is not sufficiently stable to be normatively referenced - it's actually in a relatively early stage of development. In consulting with the draft author (Keith), it has been determined that the ZS MIB draft's reference to FC-SW-5 is superfluous - FC-SW-5 was referenced solely to indicate where the Application_ID value allocated for the ZS MIB would show up in a T11 standard. The combination of the letter documenting the allocation of the value (T11/06-679v0) with FC-SW-4 is sufficient to implement the ZS MIB, and hence these two will remain as normative references after FC-SW-5 is removed. The publication request for the ZS MIB will appear shortly after the -03 version hits the Internet-Draft servers. Thanks, --David (imss WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Wed Jan 24 15:50:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9p4X-00075e-UE; Wed, 24 Jan 2007 15:50:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9p4F-0006uT-Vc; Wed, 24 Jan 2007 15:50:04 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9p4F-00023p-LH; Wed, 24 Jan 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6DDCB26F10; Wed, 24 Jan 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H9p4E-0008WB-JT; Wed, 24 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 24 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: imss@ietf.org Subject: [imss] I-D ACTION:draft-ietf-imss-fc-zs-mib-03.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet and Management Support for Storage Working Group of the IETF. Title : Fibre-Channel Zone Server MIB Author(s) : C. DeSanti, et al. Filename : draft-ietf-imss-fc-zs-mib-03.txt Pages : 93 Date : 2007-1-24 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel Zone Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-zs-mib-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imss-fc-zs-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imss-fc-zs-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-24134831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imss-fc-zs-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imss-fc-zs-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-24134831.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss --NextPart-- From imss-bounces@ietf.org Wed Jan 24 19:14:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9sGL-0005QH-8X; Wed, 24 Jan 2007 19:14:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9sGJ-0005Py-Mp for imss@ietf.org; Wed, 24 Jan 2007 19:14:43 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9sGJ-0004xF-7p for imss@ietf.org; Wed, 24 Jan 2007 19:14:43 -0500 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0P0Egxw007363 for ; Wed, 24 Jan 2007 19:14:43 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0P0EdiJ015811 for ; Wed, 24 Jan 2007 19:14:40 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 19:14:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jan 2007 19:14:39 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publication Requested: ZS MIB Thread-Index: AcdAFc2jbV0JVmR8TAuNR/XMwb3TPA== To: X-OriginalArrivalTime: 25 Jan 2007 00:14:39.0512 (UTC) FILETIME=[CDD4E180:01C74015] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.24.154933 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: Black_David@emc.com Subject: [imss] Publication Requested: ZS MIB X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org RFC publication has just been requested for the ZS MIB draft. The Doc Shepherding process (cf. draft-ietf-proto-wgchair-doc-shepherding-08.txt) is being used. Here is the Document Shepherd writeup: Document Shepherd writeup: Fibre-Channel Zone Server MIB draft-ietf-imss-fc-zs-mib-03.txt Requested Publication Status: Proposed Standard ------------------------------------------------------------------------ (1.a) Who is the Document Shepherd for this document? David L. Black (imss WG Chair) Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes, but an RFC Editor Note should be used to make two changes to text in Section 1 that is not appropriate for a Proposed Standard RFC: (A) Make the following change: OLD This memo was previously approved by T11.5 (http://www.t11.org); it is currently a work item of the IETF's IMSS working group. NEW This memo was previously approved by T11.5 (http://www.t11.org), and has been further developed in the IETF's IMSS working group. (B) Remove the following paragraph, leaving the RFC 2119 statement that occurs immediately after it: ----- This memo includes boilerplate which uses only one of the following terms, but is nevertheless required to mention all of the keywords in the following statement: ----- (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Yes. This document has been reviewed by Fibre Channel experts in Technical Committee T11 (Fibre Channel standards organization) in addition to members of the IMSS WG, and the IMSS WG's MIB expert. Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? An OPS Area MIB Doctor review was performed during WG Last Call. There does not appear to be a need for additional external reviews. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It's hard to distinguish the two cases due to somewhat thin WG membership. There is solid support for this document both in the WG and from T11. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Yes. The idnits checker (1.124) finds 3 lines with "non-RFC3330-compliant IPv4 addresses" - this is not an actual problem because these strings are actually section references into other standards, e.g., "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, section 6.4.10.2." Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes, a MIB Doctor review occurred during WG Last Call, and the MIB Doctor (Bert Wijnen) is satisfied with this version of the draft. (1.h) Has the document split its references into normative and informative? Yes. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? No. A potentially problematic normative reference to T11's in-progress FC-SW-5 standard was removed in the -03 version of the draft. Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. No. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? Yes, and the draft contains an explicit instruction to the RFC Editor on where to insert the IANA assigned MIB numbers from the mib-2 subtree. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? N/A. If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. N/A. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? N/A. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes, the Document Shepherd has relied on MIB Doctor review for the MIB checks. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel Zone Server. Working Group Summary This document was reviewed in the IMSS WG and in Technical Committee T11 (the official Fibre Channel standards body). T11 voted to recommend a prior version of this document to the IETF. Document Quality The protocol has been reviewed for the IMSS WG by Keith McCloghrie. The protocol has been reviewed for the IESG by David L. Black (imss WG Chair). The MIB Doctor Review performed by Bert Wijnen found a number of issues in SMI syntax and documentation, and triggered an allocation adventure with Technical Committee T11. The allocation adventure began because development of one of the MIBs in this draft required T11 to allocate a value from the FC-SW-5 standard that did not have a working draft at the time. T11 initially used an informal ad-hoc allocation method, and inadvertently did it twice, resulting in two different values. After strong remonstrations to T11 from the IMSS WG chair and others, T11 instituted a formal allocation process, resulting in the T11 plenary formally voting to adopt a document that records the allocation. That document (T11/06-679v0) is now part of T11's permanent archive and is the reference for the value used in this draft. Personnel Document Shepherd: David L. Black Responsible Area Director: Dan Romascanu ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Jan 29 20:16:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhbO-0002Xp-Mj; Mon, 29 Jan 2007 20:16:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhbN-0002XU-Cq for imss@ietf.org; Mon, 29 Jan 2007 20:16:01 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBhbM-0005Pw-5T for imss@ietf.org; Mon, 29 Jan 2007 20:16:01 -0500 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0U1Fx17000932 for ; Mon, 29 Jan 2007 20:15:59 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0U1FxQu013219 for ; Mon, 29 Jan 2007 20:15:59 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 20:15:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jan 2007 20:15:58 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: No IMSS meeting in Prague Thread-Index: AcdEDDJ3KvU20COYTea5S5tdb67VFw== To: X-OriginalArrivalTime: 30 Jan 2007 01:15:58.0955 (UTC) FILETIME=[330413B0:01C7440C] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.29.164932 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [imss] No IMSS meeting in Prague X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org The IMSS WG will not meet in Prague, as there are no active drafts or significant technical issues in the WG. I will be working with Dan over the next few months towards updating the charter to include FC-SP (security) MIB work. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss