From imss-bounces@ietf.org Wed Jan 02 11:03:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA63q-0001hp-Fv; Wed, 02 Jan 2008 11:03:18 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1JA63p-0001hk-CR for imss-confirm+ok@megatron.ietf.org; Wed, 02 Jan 2008 11:03:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA63o-0001hT-Dp for imss@ietf.org; Wed, 02 Jan 2008 11:03:17 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JA63n-0005Ny-MM for imss@ietf.org; Wed, 02 Jan 2008 11:03:16 -0500 X-IronPort-AV: E=Sophos;i="4.24,235,1196668800"; d="scan'208";a="9267298" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 02 Jan 2008 08:03:14 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m02G3CZ8017007; Wed, 2 Jan 2008 08:03:12 -0800 Received: from sjc-cde-021.cisco.com (sjc-cde-021.cisco.com [171.69.20.56]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m02G3CHA022411; Wed, 2 Jan 2008 16:03:12 GMT Received: (from kzm@localhost) by sjc-cde-021.cisco.com (8.11.2/8.11.2) id m02G3At08234; Wed, 2 Jan 2008 08:03:10 -0800 (PST) From: Keith McCloghrie Message-Id: <200801021603.m02G3At08234@sjc-cde-021.cisco.com> To: bertietf@bwijnen.net (Bert Wijnen - IETF) Date: Wed, 2 Jan 2008 08:03:10 -0800 (PST) In-Reply-To: from "Bert Wijnen - IETF" at Dec 29, 2007 12:53:40 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=1; a=rsa-sha256; q=dns/txt; l=4825; t=1199289792; x=1200153792; c=relaxed/simple; s=sjdkim1004; 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=20MIB=20doctor=20review=20for=3A=20T11-FC -SP-SA-MIB |Sender:=20; bh=ITuEEppKjhtomWbQ2Ht/yxFVdTfX9iW9oa0p8uTXi9o=; b=HdTEcFT5uGujgTrxB1yOG7SDxAEOV4WwQHotsi34gSDkYT/8O+lxC/EfrI FZJUrqrAPnCqAvbbWiCK6hPc89PFzUYoNDH+ddpGXx0AhDAJXVpED5NTr7/0 OaxJj07NFXJzsCgiYCdM5g1sV9dgAkl8RqOIEmrC49FrFPvYTOJz0=; Authentication-Results: sj-dkim-1; header.From=kzm@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: imss@ietf.org, Dan Romascanu , Keith McCloghrie , Black_David Subject: [imss] Re: MIB doctor review for: T11-FC-SP-SA-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 Bert, > This is a review of the module as extracted from the > prelimenary draft-ietf-imss-fc-fcsp-mib-01.txt document > > - I see: > > t11FcSpSaMIB MODULE-IDENTITY > LAST-UPDATED "200702190000Z" > ORGANIZATION "T11" > > I think that IETF IMSS WG should be included as one of > the ORGANIZATIONs that worked on this MIB module Done. > - Similar question w.r.t. discontinuity of timers as in my > earlier MIB reviews yesterday See my response to the question (in my response to your comments on T11-FC-SP-AUTHENTICATION-MIB). > - t11FcSpSaPropSecurityProt OBJECT-TYPE > SYNTAX INTEGER { espHeader(1), ctAuth(2) } > > I see this SYNTAX 3 times. > Possibly candidate for a TC. Just a subjective thought. OK, done. > - FOr t11FcSpSaPropTSelListIndex and t11FcSpSaPropTransListIndex, > I assume that a zero value means that there is no such list? > Although from the DESCRIPTION clause of the t11FcSpSaPropRowStatus > object I get the impression that a row with a zero value for > either of these 2 objects cannot be made active. So maybe zero is > not a valid value? I've changed the first sentence of t11FcSpSaPropTSelListIndex's DESCRIPTION to say: "When the value of this objct is non-zero, it points to the proposal's list of Traffic Selectors. The value must be non-zero in an active row of this table. Similarly for to t11FcSpSaPropTransListIndex. > - For t11FcSpSaTSelPropEntry I am a bit confused by: > > The StorageType of a row in this table is specified by > the instance of t11FcSpSaIfStorageType which is INDEX-ed > by the same values of fcmInstanceIndex, t11FcSpSaIfIndex > and t11FcSpSaIfFabricIndex." > INDEX { fcmInstanceIndex, t11FcSpSaIfIndex, > t11FcSpSaTSelPropListIndex, t11FcSpSaTSelPropIndex } > > The t11FcSpSaIfFabricIndex is not part of this INDEX clause, is it? > So how can it be the same? > > - Same question for t11FcSpSaTransEntry Thanks for catching this - the intent of omitting the FabricIndex from the INDEX clause of t11FcSpSaTSelPropTable (and t11FcSpSaTransTable) was so that the same list of Traffic Selectors (or transforms) could be proposed for multiple SA's even when the SA's are on different Fabrics, which seemed like it would be useful in some situations. However, the need to have a StorageType which is common for the lists and for the SA proposals, introduces an (always present) complication which I think outweighs the potential (and at most occasional) benefit. That is, I no longer believe the omission is worthwhile. If the WG agrees, I propose to change the rows in t11FcSpSaTSelPropTable and t11FcSpSaTransTable to be per-Fabric, i.e., to add t11FcSpSaIfFabricIndex into the INDEX clause of the t11FcSpSaTSelPropTable and of the t11FcSpSaTransTable. (Indeed, the DESCRIPTION of t11FcSpSaIfStorageType is already worded to assume this change will be made.) > - I think that for t11FcSpSaPairTransListIndex and t11FcSpSaPairTransIndex > a vlue of zero is impossible (or makes no sense). If I am correct you > may want to exclude that via a RANGE spec. Done. > - I have seen thos combination multipel times (in the set of MIB modules) > > t11FcSpSaPairLifetimeLeft OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The remaining lifetime of this SA pair, given in the > units specified by the value of the corresponding > instance of t11FcSpSaPairLifetimeLeft." > ::= { t11FcSpSaPairEntry 6 } > > t11FcSpSaPairLifetimeLeftUnits OBJECT-TYPE > SYNTAX INTEGER { > seconds(1), -- seconds > kiloBytes(2), -- 10^^3 bytes > megaBytes(3), -- 10^^6 bytes > gigaBytes(4), -- 10^^9 bytes > teraBytes(5), -- 10^^12 bytes > petaBytes(6), -- 10^^15 bytes > exaBytes(7), -- 10^^18 bytes > zettaBytes(8), -- 10^^21 bytes > yottaBytes(9) -- 10^^24 bytes > } > > > Possibel candidates for a TC? OK, done. > - I have seen > t11FcSpSaPairTerminate OBJECT-TYPE > SYNTAX INTEGER { noop(1), terminate(2) } > > That SYNTAX a few times. Candidate for a TC? In this case, I think it's better to leave them as-is, because the two usages have different targets, and future additions to the enumerated values have the potential to apply in one usage but not in the other. Thanks, Keith. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Thu Jan 03 06:56:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAOgb-0003EO-CB; Thu, 03 Jan 2008 06:56:33 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1JAOgZ-00035m-He for imss-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 06:56:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAOgZ-00031J-5x for imss@ietf.org; Thu, 03 Jan 2008 06:56:31 -0500 Received: from relay.versatel.net ([62.250.3.110]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JAOgX-0005Hs-EL for imss@ietf.org; Thu, 03 Jan 2008 06:56:30 -0500 Received: (qmail 49736 invoked from network); 3 Jan 2008 11:56:27 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 3 Jan 2008 11:56:27 -0000 From: "Bert Wijnen - IETF" To: "Keith McCloghrie" Date: Thu, 3 Jan 2008 12:56:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200712311650.IAA04108@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: imss@ietf.org, Black_David , Dan Romascanu Subject: [imss] RE: MIB doctor review for T11-FC-SP-AUTHENTICATION-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 Thanks Keith. ALso for the explanation on the discontinuity question I had. I am OK with it Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Keith McCloghrie [mailto:kzm@cisco.com] > Verzonden: maandag 31 december 2007 17:50 > Aan: Bert Wijnen - IETF > CC: imss@ietf.org; Keith McCloghrie; Black_David; Dan Romascanu > Onderwerp: Re: MIB doctor review for T11-FC-SP-AUTHENTICATION-MIB > > > Hi Bert, > > Thanks for your reviews. Here is my response to the first: > > > This is a review of the module as extracted from the > > prelimenary draft-ietf-imss-fc-fcsp-mib-01.txt document > > > > - I see > > t11FcSpAuthenticationMIB MODULE-IDENTITY > > LAST-UPDATED "200702190000Z" > > ORGANIZATION "T11" > > > > I think that IOETF IMSS WG should be included as one of > > the ORGANIZATIONs that worked on this MIB module > > Done. > > > - This is just a nit: > > > > t11FcSpAuMIBIdentities > > OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 1 } > > t11FcSpAuMIBObjects > > OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 2 } > > t11FcSpAuMIBConformance > > OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 3 } > > t11FcSpAuMIBNotifications > > OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 0 } > > > > Most MIB modules have MIBObjects as 1 and Conformace as 2. > > This MIB module has additional a set of Identities. SO I personally > > would do: > > > > t11FcSpAuMIBNotifications > > OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 0 } > > t11FcSpAuMIBObjects > > OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 1 } > > t11FcSpAuMIBConformance > > OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 2 } > > t11FcSpAuMIBIdentities > > OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 3 } > > > > But and OID is just an OID, so this is not a flaw. Just a consistency > > thing > > that I personally would try to follow. > > Done. > > > - It is unclear to me why > > t11FcSpAuEntityName OBJECT-TYPE > > SYNTAX FcNameIdOrZero (SIZE (8)) > > > > Has a fixed size of 8. I think I would have expected (8 | 16) > > You reference > > "fcmInstanceWwn & fcmSwitchWWN, > > 'Fibre Channel Management MIB', RFC 4044, May 2005." > > And fcmInstanceWwn and fcmSwitchWWN there (as far as I can tell also > > allow 8 or 16. In fact they even allows for zero, but I can > see you do > > (or may) not want to allow that here. > > Section 5.3.3 of FC-SP restricts the length to 8 bytes, so I believe the > restriction is correct. I will add section 5.3.3 to the REFERENCE clause. > > > - So for my undestanding, when I see this: > > > > t11FcSpAuIfStatTimeouts OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The number of FC-SP Authentication Protocol messages sent > > by the particular entity on the particular Fabric on the > > particular interface, for which no response was received > > within a timeout period. > > > > This counter has no discontinuities other than those > > which all Counter32's have when sysUpTime=0." > > > > Then I understand from that that the instrumentation code > for this MIB > > module will save these values in persistent storage, and so when it > > restarts it still knows the values? > > Or are you saying that the "master-agent" and "t11-subagent" > are always > > a monolithic entity and will die/restart together? > > I'm saying is that sysUpTime gets reset to zero in any MIB view which > includes this MIB whenever this Counter32 has a discontinutity. > Yes, this can achieved by "a monolithic entity" and by "persistent > storage of the value" but it can also be achieved in other ways as > well. > > The alternative is to define one or more additional discontinuity > timestamps. The number (of these additional timestamps) required > is dependent on the architecture of the implementation. One > possibility would be to add a TimeStamp object to fcmInstanceTable > (defined in RFC 4044), but if we were going to do that, I think we > should have done it three years ago, before RFCs 4438, 4439, 4625, > 4626, 4747, 4935, 4936 and 4983 were approved without referencing such > a TimeStamp object. > > Thanks, > Keith. > > PS. I'll make the updated document available after I've responded to > your other reviews. > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Thu Jan 03 07:07:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAOrP-00036u-BN; Thu, 03 Jan 2008 07:07:43 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1JAOrO-0002xz-81 for imss-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 07:07:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAOrN-0002wP-Tf for imss@ietf.org; Thu, 03 Jan 2008 07:07:41 -0500 Received: from relay.versatel.net ([62.250.3.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JAOrM-0006bI-1h for imss@ietf.org; Thu, 03 Jan 2008 07:07:41 -0500 Received: (qmail 58678 invoked from network); 3 Jan 2008 12:07:39 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 3 Jan 2008 12:07:39 -0000 From: "Bert Wijnen - IETF" To: "Keith McCloghrie" Subject: RE: [imss] Re: MIB doctor review for: T11-FC-SP-SA-MIB Date: Thu, 3 Jan 2008 13:07:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200801021603.m02G3At08234@sjc-cde-021.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: imss@ietf.org, Black_David , Dan Romascanu 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 for the answers Keith. Suggested changed look OK to me. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Keith McCloghrie [mailto:kzm@cisco.com] > Verzonden: woensdag 2 januari 2008 17:03 > Aan: Bert Wijnen - IETF > CC: imss@ietf.org; Dan Romascanu; Keith McCloghrie; Black_David > Onderwerp: [imss] Re: MIB doctor review for: T11-FC-SP-SA-MIB > > > Bert, > > > This is a review of the module as extracted from the > > prelimenary draft-ietf-imss-fc-fcsp-mib-01.txt document > > > > - I see: > > > > t11FcSpSaMIB MODULE-IDENTITY > > LAST-UPDATED "200702190000Z" > > ORGANIZATION "T11" > > > > I think that IETF IMSS WG should be included as one of > > the ORGANIZATIONs that worked on this MIB module > > Done. > > > - Similar question w.r.t. discontinuity of timers as in my > > earlier MIB reviews yesterday > > See my response to the question (in my response to your comments on > T11-FC-SP-AUTHENTICATION-MIB). > > > - t11FcSpSaPropSecurityProt OBJECT-TYPE > > SYNTAX INTEGER { espHeader(1), ctAuth(2) } > > > > I see this SYNTAX 3 times. > > Possibly candidate for a TC. Just a subjective thought. > > OK, done. > > > - FOr t11FcSpSaPropTSelListIndex and t11FcSpSaPropTransListIndex, > > I assume that a zero value means that there is no such list? > > Although from the DESCRIPTION clause of the t11FcSpSaPropRowStatus > > object I get the impression that a row with a zero value for > > either of these 2 objects cannot be made active. So maybe zero is > > not a valid value? > > I've changed the first sentence of t11FcSpSaPropTSelListIndex's > DESCRIPTION to say: > > "When the value of this objct is non-zero, it points to > the proposal's list of Traffic Selectors. The value > must be non-zero in an active row of this table. > > Similarly for to t11FcSpSaPropTransListIndex. > > > - For t11FcSpSaTSelPropEntry I am a bit confused by: > > > > The StorageType of a row in this table is specified by > > the instance of t11FcSpSaIfStorageType which is INDEX-ed > > by the same values of fcmInstanceIndex, t11FcSpSaIfIndex > > and t11FcSpSaIfFabricIndex." > > INDEX { fcmInstanceIndex, t11FcSpSaIfIndex, > > t11FcSpSaTSelPropListIndex, t11FcSpSaTSelPropIndex } > > > > The t11FcSpSaIfFabricIndex is not part of this INDEX clause, is it? > > So how can it be the same? > > > > - Same question for t11FcSpSaTransEntry > > Thanks for catching this - the intent of omitting the FabricIndex from > the INDEX clause of t11FcSpSaTSelPropTable (and t11FcSpSaTransTable) > was so that the same list of Traffic Selectors (or transforms) could be > proposed for multiple SA's even when the SA's are on different Fabrics, > which seemed like it would be useful in some situations. However, the > need to have a StorageType which is common for the lists and for the SA > proposals, introduces an (always present) complication which I think > outweighs the potential (and at most occasional) benefit. That is, I no > longer believe the omission is worthwhile. If the WG agrees, I propose > to change the rows in t11FcSpSaTSelPropTable and t11FcSpSaTransTable to > be per-Fabric, i.e., to add t11FcSpSaIfFabricIndex into the INDEX > clause of the t11FcSpSaTSelPropTable and of the t11FcSpSaTransTable. > (Indeed, the DESCRIPTION of t11FcSpSaIfStorageType is already worded to > assume this change will be made.) > > > - I think that for t11FcSpSaPairTransListIndex and > t11FcSpSaPairTransIndex > > a vlue of zero is impossible (or makes no sense). If I am correct you > > may want to exclude that via a RANGE spec. > > Done. > > > - I have seen thos combination multipel times (in the set of > MIB modules) > > > > t11FcSpSaPairLifetimeLeft OBJECT-TYPE > > SYNTAX Unsigned32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The remaining lifetime of this SA pair, given in the > > units specified by the value of the corresponding > > instance of t11FcSpSaPairLifetimeLeft." > > ::= { t11FcSpSaPairEntry 6 } > > > > t11FcSpSaPairLifetimeLeftUnits OBJECT-TYPE > > SYNTAX INTEGER { > > seconds(1), -- seconds > > kiloBytes(2), -- 10^^3 bytes > > megaBytes(3), -- 10^^6 bytes > > gigaBytes(4), -- 10^^9 bytes > > teraBytes(5), -- 10^^12 bytes > > petaBytes(6), -- 10^^15 bytes > > exaBytes(7), -- 10^^18 bytes > > zettaBytes(8), -- 10^^21 bytes > > yottaBytes(9) -- 10^^24 bytes > > } > > > > > > Possibel candidates for a TC? > > OK, done. > > > - I have seen > > t11FcSpSaPairTerminate OBJECT-TYPE > > SYNTAX INTEGER { noop(1), terminate(2) } > > > > That SYNTAX a few times. Candidate for a TC? > > In this case, I think it's better to leave them as-is, because the two > usages have different targets, and future additions to the enumerated > values have the potential to apply in one usage but not in the other. > > Thanks, > Keith. > > > _______________________________________________ > 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 Thu Jan 03 07:07:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAOrQ-0003EU-GA; Thu, 03 Jan 2008 07:07:44 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1JAOrP-00033z-2b for imss-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 07:07:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAOrO-000326-OX for imss@ietf.org; Thu, 03 Jan 2008 07:07:42 -0500 Received: from relay.versatel.net ([62.250.3.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JAOrL-0006bG-O8 for imss@ietf.org; Thu, 03 Jan 2008 07:07:42 -0500 Received: (qmail 58664 invoked from network); 3 Jan 2008 12:07:38 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 3 Jan 2008 12:07:38 -0000 From: "Bert Wijnen - IETF" To: "Keith McCloghrie" Date: Thu, 3 Jan 2008 13:07:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200712312022.MAA10683@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 Cc: imss@ietf.org, Black_David , Dan Romascanu Subject: [imss] RE: MIB Doctor review for: T11-FC-SP-POLICY-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 Inline Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Keith McCloghrie [mailto:kzm@cisco.com] > Verzonden: maandag 31 december 2007 21:22 > Aan: Bert Wijnen - IETF > CC: imss@ietf.org; Black_David; Keith McCloghrie; Dan Romascanu > Onderwerp: Re: MIB Doctor review for: T11-FC-SP-POLICY-MIB > > > Bert, > > > This is a review of the module as extracted from the > > prelimenary draft-ietf-imss-fc-fcsp-mib-01.txt document > > > > - I see: > > > > t11FcSpPolicyMIB MODULE-IDENTITY > > LAST-UPDATED "200702190000Z" > > ORGANIZATION "T11" > > > > I think that IETF IMSS WG should be included as one of > > the ORGANIZATIONs that worked on this MIB module > > Done. > > > - I see: > > > > t11FcSpPoAdminFabricName OBJECT-TYPE > > SYNTAX FcNameIdOrZero (SIZE (8)) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The administratively-specified name for this Fabric, as > > specified in the active Switch Membership List Object. > > This value is meaningful only when Static Domain_IDs are > > in use in a Fabric (see FC-SW-4). Static Domain_IDs are > > administratively enabled by a setting of the Switch Flags > > in each Switch Entry in the Switch Membership List Object. > > If Static Domain_IDs are not in use, this value might be > > '0000000000000000'h. > > > > The t11FamEnable, t11FamFabricName and > > t11FamConfigDomainIdType objects defined in the > > T11-FC-FABRIC-ADDR-MGR-MIB module are also concerned with > > the use of an administratively-specified name for a Fabric > > and Static Domain_IDs. When FC-SP Policy is in use in a > > Fabric, the values of t11FamEnable, t11FamFabricName and > > t11FamConfigDomainIdType must be read-only and reflect the > > active Policy Objects. For example, the value of > > t11FamFabricName must reflect the value of > > t11FcSpPoAdminFabricName." > > > > And I then wonder if the SIZE (8) is indeed intended or if it ought > > to be SIZE (8 | 16). > > Table 108 of FC-SP (which in this case is listed in the REFERENCE clause) > limits the size to 8 bytes. > I can live with it as long as it is indeed understood. So one reference makes it clear. But the REFERENCE to RFC4439 confused me, because there the FcNameIdOrZero TC is used without subtyping, so it allows for zero, 8 and 16 I think. That got me to ask the question. > > Futher, when reading the restrinctions on t11FamEnable, t11FamFabricName > > and t11FamConfigDomainIdType that this MIB module imposes on another > > MIB module, I wonder > > - is that for all entries in the t11FamTable? In other words, once > > you use the POLICY-MIB, would it apply to all Fabrics, or just to the > > ones fro which there are entries in this Table. > > Just the ones which reference Fabrics which have entries in this table. > > > - And is that a "must be read-only" a dynamic thing? In other words, > > once an Active Policy gets deactivated, doe the objects in the > > t11FamTable then become read-write again? > > Yes. > > > - Depending on the answers, would it make sense to add more to the > > DESCRIPTION clause? > > I think the phrase "When FC-SP Policy is in use in a Fabric," is a concise > way of stating when (and for which instances) the dependence exists. > Maybe yes, maybe no. It is good to get confimration from you that I more or less indeed did understand what the intention was/is. I wonder if it is so obvious to all readers of this MIB module. Specifically the "must be read-only" to be dynamic is not so obvious I think. Maybe adding some extra text might help. > > - Depending on the answers, would it make sense to IMPORT these > > obecjts and use them in the MODULE-CONFORMANCE to indicate that > > MAX-ACCESS is read-only ?? > > I think the relationship is on a per-instance basis, i.e., if FC-SP > Policy is only being used on some (virtual) Fabrics, then only some > of the t11FamXxxx objects must be read-only. > Might be good to also make that "on a per instance basis" more explicit in the DESCRIPTION clause. > However, consideration of your comment exposes two related issues: > > The first is that there's a minor flaw in RFC 4439, in that a > MIN-ACCESS clause is defined for t11FamConfigDomainIdType but did not > get added (as it should have) for t11FamEnable and t11FamFabricName. > In other words, I think fixing RFC 4439 would be the way to address > your comment (even though that probably won't happen). > Yep I see that now. I suspect we do not have a good tool (or at least I do not know which one) that will check if all objects that are read-write and for which you would want them to be allowed with MIN-ACCESS of something else. And checking manually is cumbersome (and erroneous) process as we now find out. > The second is that t11FcSpPoAdminFabricNameis read-only, as indeed it > must be because it's part of the Active Policy which cannot be modified > once it's active. So, how is the Fabric name specified when Policy is > in use ?? I believe the answer is that t11FcSpPoNaSummaryFabricName > needs to be added as a read-create object in the t11FcSpPoNaSummaryTable. > If the WG agrees, then I will add this new object. > Mmm... I guess I had assumed that would be picked up vi fcmInstanceIndex, t11FcSpPoFabricIndex But had not actually checked that. Anyway, I can live with your suggested change. > > - I find this a bit confusing: > > > > t11FcSpPoSummaryPolicyType OBJECT-TYPE > > SYNTAX T11FcSpPolicyObjectType > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The 'Identifier' which specifies the type of this > > Policy Object." > > > > It is just the "type" is it not? ANd it is indicated by the valu of this > > object whioch is an enumeration. So wht is the 'Identifier'? > > Why no just say: > > > > DESCRIPTION > > "The type of this Policy Object." > > I used "'Identifier'" because that it is the term used in FC-SP. I too > believe think it is confusing, but it is a type, because the REFERENCE > clause lists section 7.1.3.1 which says: > > Policy Object Identifier fields: the identifier of a Policy Object (see > table 102). > > and table 102 enumerates the six possible values. (I guess that for those > types which have at most one active policy object, the type can be used > as an implicit identifier.) > > Would you prefer the DESCRIPTION to say: > > "The 'Identifier' (i.e., the type) of this Policy Object." > OK thanks for explaining how/why you used the (for me confusing) term. Adding that clarification in parentheses does help I think. > > - When I read (in the TC-MIB about T11FcSpPolicyNameType and > > T11FcSpPolicyName, > > I sort of assumed/thought that these two would always be used in > > combination. > > However in this POLICY-MIB I see the T11FcSpPolicyNameType > (subtypef in > > OBJECT-TYPE t11FcSpPoSwMembSwitchNameType) being used together with: > > t11FcSpPoSwMembSwitchName OBJECT-TYPE > > SYNTAX FcNameIdOrZero (SIZE (8)) > > Is that not at least somewhat weird and possibly confusing? > > I can see that it is not absolutely flawed, but I am not sure > we want to > > do this sort of thing, do we? > > > > Further in the POLICY-MIB I see how I expected it to see, namely when > > t11FcSpPoSwConnAllowedNameType and t11FcSpPoSwConnAllowedName are bing > > used. > > And in this case it has the same subtypes as above. So > > t11FcSpPoSwConnAllowedName OBJECT-TYPE > > SYNTAX T11FcSpPolicyName > > Could possibly be changed to > > t11FcSpPoSwConnAllowedName OBJECT-TYPE > > SYNTAX T11FcSpPolicyName (SIZE (8)) > > > > In any event, here we see already inconsistency within the same MIB > > Module. > > You are correct. I'll fix it such that: > > SYNTAX T11FcSpPolicyName (SIZE (8)) > > is used consistently in these situations. > > > - I see: > > > > t11FcSpPoIpMgmtEntryNameType OBJECT-TYPE > > SYNTAX InetAddressType > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The combination of t11FcSpPoIpMgmtNameType, > > t11FcSpPoIpMgmtNameLow and t11FcSpPoIpMgmtNameHigh > > specify the IP Address range of this IP Management > > Entry in the IP Management List Object. > > > > The FC-SP specification does not allow the use of a > > DNS domain name to specify the address at the lower end > > or at the higher end of the IP Address range, nor does it > > allow the specification of a zone index. Therefore, the > > type of address must be one of: 'ipv4', or 'ipv6'." > > > > You are not using MUST (as in RFC2119), yet, when I read > > > > Therefore, the > > type of address must be one of: 'ipv4', or 'ipv6' > > > > then I think I would subtype the SYNTAX as > > > > SYNTAX InetAddressType (ipv4(1), ipv6(2)) > > > > That makes the requirement machine readable. > > By using > > > > t11FcSpPoIpMgmtEntryNameLow OBJECT-TYPE > > SYNTAX InetAddress (SIZE(4 | 16)) > > > > You basically do the same. > > You haven't mentioned t11FcSpPoNaIpMgmtEntryNameType, which is defined > like this: > > t11FcSpPoNaIpMgmtEntryNameType OBJECT-TYPE > SYNTAX InetAddressType > -- INTEGER { ipv4(1), ipv6(2) } > > where the subtype is put in an ASN.1 comment as a convenience for > developers because it avoids the compile error which SMICng generates > for "InetAddressType (ipv4(1), ipv6(2))". > > So, I suggest I add the same ASN.1 comment for > t11FcSpPoIpMgmtEntryNameType. > Why a comment if the types are really restricted (as is also stated in the DESCRIPTIONs and in the SIZE restrictions for teh Address itself. Why not just subtype it, so it is clear and machine readable and consistent with the SIZE restrictions in the ...Address object? > > - When I read > > t11FcSpPoWkpDescrDestPort OBJECT-TYPE > > SYNTAX Unsigned32 (0..65535) > > and its DESCRIPTION clause, I wonder why you do not use InetPortNumber > > TC?? > > I will change it. > > > - I am surprised/confused by this: > > > > t11FcSpPoWkpDescrWkpNumber OBJECT-TYPE > > SYNTAX Unsigned32 (0..255) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "When the 'wkpWildcard' bit is set in the corresponding > > instance of t11FcSpPoWkpDescrFlags, this object specifies > > the IP protocol number of the Well-Known Protocol." > > REFERENCE > > "- INCITS xxx/200x, T11/Project 1570-D/Rev 1.8, > > Fibre Channel - Security Protocols (FC-SP), 13 June 2006, > > section 7.1.7.1 and table 131. > > - http://www.iana.org/assignments/protocol-numbers." > > > > In those protocol numbers listed at IANA, is there any other protocol > > that one would sensibly use except TCP and UDP ??? > > I do see that you just represent what table 130 (not 131) on page 138 > > in the T11 document shows. I still find it strange > > As you note, the intent was to reproduce what FC-SP allows, and that does > have the future potential of an SCTP-based protocol. > Understood. Still find it strange. But can live with it. In practice I guess it won't matter that much. > > - For this > > > > t11FcSpPoAttribExtension OBJECT-TYPE > > SYNTAX OBJECT IDENTIFIER > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "For some types of Attribute Policy Object, the value of > > this MIB object points to type-specific MIB objects which > > contain individual/broken-out parts of the Attribute Policy > > Object's value. If this object doesn't point to such > > type-specific MIB objects, then it contains the value: > > zeroDotZero. > > > > In particular, when the value of t11FcSpPoAttribType > > indicates 'AUTH_Negotiate Message Payload', one or more > > Authentication Protocol Identifiers and their associated > > Authentication Protocol Parameters are embedded within the > > value of the corresponding instance of t11FcSpPoAttribValue; > > MIB objects to contain these individual values are defined > > in the t11FcSpPoAuthProtTable. Thus, for an 'AUTH_Negotiate > > Message Payload' Attribute, the value of this object > > contains the OID of t11FcSpPoAuthProtTable." > > > > Is it really the idea that you would point to the table, or would > > you rather point to the relevant first part of > t11FcSpPoAuthProtParams > > This pointer needs to apply generically in any/all cases, and so its > definition cannot be too specific. E.g., for the example given in the > DESCRIPTION, it needs to point to "one or more ... Identifiers and ...". > So, I think the problem you've identified is that the example is too > specific. How about I fix it like this: > > .... Thus, for an 'AUTH_Negotiate > Message Payload' Attribute, the value of this object > contains an OID within the t11FcSpPoAuthProtTable, e.g., > of the whole table, of an individual row, or of an individual > instance within the table." > Yes, Makes it clearer I think. > > Some of the above comments apply equally well to the Non-Active Policy > > Objects. I won't repeat them. > > > > - I see: > > > > t11FcSpPoNaSummaryHashStatus OBJECT-TYPE > > SYNTAX INTEGER { > > calculate(1), > > correct(2), > > stale(3) > > } > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "When read, the value of this object is either: > > > > correct -- the corresponding instance of > > t11FcSpPoNaSummaryHashValue contains > > the correct value; or > > stale -- the corresponding instance of > > t11FcSpPoNaSummaryHashValue contains > > a stale (possibly incorrect) value; > > > > Writing a value of 'calculate' is a request to re-calculate > > and update the value of the corresponding instance of > > t11FcSpPoNaSummaryHashValue. Writing a value of 'correct' > > or 'stale' to this object is a ('wrongValue') error." > > DEFVAL { stale } > > > > And the STorageType object t11FcSpPoStorageType that is > controlling this > > table entry states: > > Even if an instance of this object has the value > > 'permanent(4)', none of the information defined in > > this MIB module for the given Fabric needs to be > > writable." > > > > So how does a stale value for a permanent row get re-calculated? > > A hash value only becomes 'stale' after a modification of the Policy > object(s) for which it is the hash value. (The intent of havign this > separate object is so that teh hash doesn't have to be re-calculated > after each and every modification of multiple Policy Objects.) > So, for Policy objects in a 'permanent(4)' row, their hash value will > be 'correct' permanently. > OK, would it make sense to document that? > > - For your counters, you write: > > > > This counter has no discontinuities other than those > > which all Counter32's have when sysUpTime=0." > > > > So if the instrumentation restarts, it keeps track of the values? > > Of is the instrunmentation alsways a monolithic entity together with > > the main/master SNMP agent? > > Not necessarily. See my response to your same comment for the previous > MIB module. > Yep seen that and responded to in the other email. Bert > Thanks, > Keith. > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Fri Jan 04 11:19:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApH0-0002c4-Ka; Fri, 04 Jan 2008 11:19:54 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1JApH0-0002bx-23 for imss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 11:19:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApGz-0002bj-M3 for imss@ietf.org; Fri, 04 Jan 2008 11:19:53 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JApGz-0002gD-8Z for imss@ietf.org; Fri, 04 Jan 2008 11:19:53 -0500 X-IronPort-AV: E=Sophos;i="4.24,245,1196668800"; d="scan'208";a="2687525" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 04 Jan 2008 08:19:52 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m04GJq1w008435; Fri, 4 Jan 2008 08:19:52 -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 m04GJlq7006211; Fri, 4 Jan 2008 16:19:47 GMT Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA12026; Fri, 4 Jan 2008 08:17:41 -0800 (PST) From: Keith McCloghrie Message-Id: <200801041617.IAA12026@cisco.com> Subject: Re: [imss] MIB doctor review for T11-FC-SP-ZONING-MIB To: bertietf@bwijnen.net (Bert Wijnen - IETF) Date: Fri, 4 Jan 2008 08:17:41 -0800 (PST) In-Reply-To: from "Bert Wijnen - IETF" at Dec 29, 2007 03:01:20 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=1; a=rsa-sha256; q=dns/txt; l=2023; t=1199463592; x=1200327592; c=relaxed/simple; s=sjdkim4002; 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]=20MIB=20doctor=20review=20for=20 T11-FC-SP-ZONING-MIB |Sender:=20; bh=i6d0TTGirCrUlalMur/DsXic91e/SgnZ04YAa4YfdrA=; b=rdmiT7cEtvw9fUyUK4IKfOJd8IHjtYRmnQkJM3dbsXDZJ5hRgeJHvERD2r QbrQhHEX6k9Ynm9YZUVclOwZ3TIl0tdGGiPqyWOAIiOxrZ+kJsdPoXDiBM12 1aOs3mkHDW; Authentication-Results: sj-dkim-4; header.From=kzm@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: imss@ietf.org, Keith McCloghrie , Black_David , Dan Romascanu 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 Bert, I believe that with my responses below, I have now responded to all of the comments that you have sent for this I-D. Further, especially given the number and size of the MIB modules, we thank you for expending the large amount of effort needed to provide all the comments. > This is a review of the module as extracted from the > prelimenary draft-ietf-imss-fc-fcsp-mib-01.txt document > > - I see: > > t11FcSpZoningMIB MODULE-IDENTITY > LAST-UPDATED "200702190000Z" > ORGANIZATION "T11" > > I think that IETF IMSS WG should be included as one of > the ORGANIZATIONs that worked on this MIB module Done. > - I have seen > > t11FcSpZoneSetHashStatus OBJECT-TYPE > SYNTAX INTEGER { > calculate(1), > correct(2), > stale(3) > } > > That SYNTAX a number of times in the set of MIB modules. > Candidate for a TC? Done. > - FOr that same object, I wonder how a re-calculate can be done > for a permanent row, since the storage type states: > > If an instance of this object has the value > 'permanent(4)', the Zone Set database for the given > fabric on the given switch is not required to be > writeable." Assuming that I've correctly understood your question, I'll add: a sentence in the DESCRIPTION of t11FcSpZoneSetHashStatus to say: If and when the corresponding instance of t11ZsServerDatabaseStorageType (defined in RFC 4936) has the value 'permanent(4)', then if any the instance of an object in if any row of any table governed by t11ZsServerDatabaseStorageType has an object that is writable, then so too must be the corresponding instance of this object. OK? > - Same question about counter discontinuities as in my earlier > MIB reviews yesterday. I hope the same answer I gave to them will suffice here also. Thanks, Keith. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Fri Jan 04 12:23:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqGC-0005zk-2Y; Fri, 04 Jan 2008 12:23:08 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1JAqGB-0005zT-1k for imss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 12:23:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqGA-0005zI-O3 for imss@ietf.org; Fri, 04 Jan 2008 12:23:06 -0500 Received: from relay.versatel.net ([62.250.3.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JAqG8-0008Bf-FB for imss@ietf.org; Fri, 04 Jan 2008 12:23:06 -0500 Received: (qmail 91904 invoked from network); 4 Jan 2008 17:23:02 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 4 Jan 2008 17:23:02 -0000 From: "Bert Wijnen - IETF" To: "Keith McCloghrie" Subject: RE: [imss] MIB doctor review for T11-FC-SP-ZONING-MIB Date: Fri, 4 Jan 2008 18:23:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200801041617.IAA12026@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: imss@ietf.org, Black_David , Dan Romascanu 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 Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Keith McCloghrie [mailto:kzm@cisco.com] > Verzonden: vrijdag 4 januari 2008 17:18 > Aan: Bert Wijnen - IETF > CC: imss@ietf.org; Keith McCloghrie; Black_David; Dan Romascanu > Onderwerp: Re: [imss] MIB doctor review for T11-FC-SP-ZONING-MIB > > > Bert, > > I believe that with my responses below, I have now responded to all of > the comments that you have sent for this I-D. Further, especially > given the number and size of the MIB modules, we thank you for > expending the large amount of effort needed to provide all the > comments. > > > This is a review of the module as extracted from the > > prelimenary draft-ietf-imss-fc-fcsp-mib-01.txt document > > > > - I see: > > > > t11FcSpZoningMIB MODULE-IDENTITY > > LAST-UPDATED "200702190000Z" > > ORGANIZATION "T11" > > > > I think that IETF IMSS WG should be included as one of > > the ORGANIZATIONs that worked on this MIB module > > Done. > > > - I have seen > > > > t11FcSpZoneSetHashStatus OBJECT-TYPE > > SYNTAX INTEGER { > > calculate(1), > > correct(2), > > stale(3) > > } > > > > That SYNTAX a number of times in the set of MIB modules. > > Candidate for a TC? > > Done. > > > - FOr that same object, I wonder how a re-calculate can be done > > for a permanent row, since the storage type states: > > > > If an instance of this object has the value > > 'permanent(4)', the Zone Set database for the given > > fabric on the given switch is not required to be > > writeable." > > Assuming that I've correctly understood your question, I'll add: > a sentence in the DESCRIPTION of t11FcSpZoneSetHashStatus to say: > > If and when the corresponding instance of > t11ZsServerDatabaseStorageType (defined in RFC 4936) has the value > 'permanent(4)', then if any the instance of an object in if any row :if any the instance" ?? do you mean "if any instance" "in if any row" ?? maybe remove the last "if" ?? > of any table governed by t11ZsServerDatabaseStorageType has an > object that is writable, then so too must be the corresponding > instance of this object. > > OK? > Not sure I underatand, so you say this one only needs to be writable if any other wrietable object is writable? I am confused? > > - Same question about counter discontinuities as in my earlier > > MIB reviews yesterday. > > I hope the same answer I gave to them will suffice here also. > That one is OK with me. Hope the WG understood/understands the implications and agrees as well. Bert > Thanks, > Keith. > > > _______________________________________________ > 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 Fri Jan 04 13:02:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqrt-0008Rb-Kz; Fri, 04 Jan 2008 13:02:05 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1JAqrs-0008RP-2P for imss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 13:02:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqrr-0008RG-Ox for imss@ietf.org; Fri, 04 Jan 2008 13:02:03 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAqrq-0000Ur-4T for imss@ietf.org; Fri, 04 Jan 2008 13:02:03 -0500 X-IronPort-AV: E=Sophos;i="4.24,246,1196668800"; d="scan'208";a="9841297" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 04 Jan 2008 10:02:01 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m04I21Z7003717; Fri, 4 Jan 2008 10:02:01 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m04I21HA010755; Fri, 4 Jan 2008 18:02:01 GMT Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA04384; Fri, 4 Jan 2008 10:00:03 -0800 (PST) From: Keith McCloghrie Message-Id: <200801041800.KAA04384@cisco.com> Subject: Re: [imss] MIB doctor review for T11-FC-SP-ZONING-MIB To: bertietf@bwijnen.net (Bert Wijnen - IETF) Date: Fri, 4 Jan 2008 10:00:03 -0800 (PST) In-Reply-To: from "Bert Wijnen - IETF" at Jan 04, 2008 06:23:15 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=1; a=rsa-sha256; q=dns/txt; l=3452; t=1199469721; x=1200333721; c=relaxed/simple; s=sjdkim2002; 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]=20MIB=20doctor=20review=20for=20 T11-FC-SP-ZONING-MIB |Sender:=20; bh=fKBO/g/bZKCyLVJkZO28p77rbVG8ccHk8ImM0nBsDKo=; b=WP7oWy8Uv6JP/lPijOaYOlIKPiApKVKsr2fW0bHhQav3Quxa22ZLoU18/X y5x4Q53vBwiZ3gP6VM0552aQiRVoKJAY9UyBiqoGCd6RQzpaBH4P7NvKvs/9 U61Ge0/aNC; Authentication-Results: sj-dkim-2; header.From=kzm@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: imss@ietf.org, Dan Romascanu , Keith McCloghrie , Black_David 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 Extracting the one issue out of your response: > > > t11FcSpZoneSetHashStatus OBJECT-TYPE > > > SYNTAX INTEGER { > > > calculate(1), > > > correct(2), > > > stale(3) > > > } > > > > > > That SYNTAX a number of times in the set of MIB modules. > > > Candidate for a TC? > > > > Done. > > > > > - FOr that same object, I wonder how a re-calculate can be done > > > for a permanent row, since the storage type states: > > > > > > If an instance of this object has the value > > > 'permanent(4)', the Zone Set database for the given > > > fabric on the given switch is not required to be > > > writeable." > > > > Assuming that I've correctly understood your question, I'll add: > > a sentence in the DESCRIPTION of t11FcSpZoneSetHashStatus to say: > > > > If and when the corresponding instance of > > t11ZsServerDatabaseStorageType (defined in RFC 4936) has the value > > 'permanent(4)', then if any the instance of an object in if any row > > "if any the instance" ?? do you mean "if any instance" > "in if any row" ?? maybe remove the last "if" ?? Sorry for the confusion, let me try again: If and when the corresponding instance of t11ZsServerDatabaseStorageType (defined in RFC 4936) has the value 'permanent(4)', then if write access is supported to any instance of a read-write object in any row of any table governed by the 'permanent' value of t11ZsServerDatabaseStorageType, then write acces to the corresponding instance of this object must also be supported. > > of any table governed by t11ZsServerDatabaseStorageType has an > > object that is writable, then so too must be the corresponding > > instance of this object. > > > > OK? > > Not sure I underatand, so you say this one only needs to be writable > if any other wrietable object is writable? > I am confused? Doubtful -- it's probably that I've interpreted your comment wrongly. Here's the conclusion that I "jumped" to: RFC 2579 says (for StorageType): Every usage of this textual convention is required to specify the columnar objects which a permanent(4) row must at a minimum allow to be writable." but t11ZsServerDatabaseStorageType is aleady defined in RFC 4936 and we aren't modifying RFC 4936, and so you want the specification of "must at a minimum allow to be writable" to be updated in the DESCRIPTION of t11FcSpZoneSetHashStatus. Now, one instance of t11ZsServerDatabaseStorageType covers all the associated rows of many tables, including rows in this new table which AUGMENTS t11ZsServerEntry. If t11ZsServerDatabaseStorageType is 'permanent', then some of the instances in the identified set of rows might be writeable -- if any are, then the Hash value is likely to change when such modifying such instances, and so the corresponding instance of t11FcSpZoneSetHashStatus needs to be writable. In contrast, if none of the instances of objects in the identified set of rows are writable, then that instance of t11FcSpZoneSetHashStatus doesn't need to be writable either. Is that what you meant ?? If so, did I capture it in my proposed addition to t11FcSpZoneSetHashStatus ? Keith. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Fri Jan 04 13:49:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JArbX-0004M9-TE; Fri, 04 Jan 2008 13:49:15 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1JArbX-0004M4-2T for imss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 13:49:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JArbW-0004Lv-Ou for imss@ietf.org; Fri, 04 Jan 2008 13:49:14 -0500 Received: from relay.versatel.net ([62.250.3.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JArbU-0001O2-Ej for imss@ietf.org; Fri, 04 Jan 2008 13:49:14 -0500 Received: (qmail 35081 invoked from network); 4 Jan 2008 18:49:11 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 4 Jan 2008 18:49:11 -0000 From: "Bert Wijnen - IETF" To: "Keith McCloghrie" Subject: RE: [imss] MIB doctor review for T11-FC-SP-ZONING-MIB Date: Fri, 4 Jan 2008 19:49:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200801041800.KAA04384@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: imss@ietf.org, Black_David , Dan Romascanu 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 Yes, now we are in agreement Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Keith McCloghrie [mailto:kzm@cisco.com] > Verzonden: vrijdag 4 januari 2008 19:00 > Aan: Bert Wijnen - IETF > CC: Keith McCloghrie; imss@ietf.org; Black_David; Dan Romascanu > Onderwerp: Re: [imss] MIB doctor review for T11-FC-SP-ZONING-MIB > > > Extracting the one issue out of your response: > > > > > t11FcSpZoneSetHashStatus OBJECT-TYPE > > > > SYNTAX INTEGER { > > > > calculate(1), > > > > correct(2), > > > > stale(3) > > > > } > > > > > > > > That SYNTAX a number of times in the set of MIB modules. > > > > Candidate for a TC? > > > > > > Done. > > > > > > > - FOr that same object, I wonder how a re-calculate can be done > > > > for a permanent row, since the storage type states: > > > > > > > > If an instance of this object has the value > > > > 'permanent(4)', the Zone Set database for the given > > > > fabric on the given switch is not required to be > > > > writeable." > > > > > > Assuming that I've correctly understood your question, I'll add: > > > a sentence in the DESCRIPTION of t11FcSpZoneSetHashStatus to say: > > > > > > If and when the corresponding instance of > > > t11ZsServerDatabaseStorageType (defined in RFC 4936) has the value > > > 'permanent(4)', then if any the instance of an object in > if any row > > > > "if any the instance" ?? do you mean "if any instance" > > "in if any row" ?? maybe remove the last "if" ?? > > Sorry for the confusion, let me try again: > > If and when the corresponding instance of > t11ZsServerDatabaseStorageType (defined in RFC 4936) has the value > 'permanent(4)', then if write access is supported to any instance of > a read-write object in any row of any table governed by the > 'permanent' value of t11ZsServerDatabaseStorageType, then write > acces to the corresponding instance of this object must also be > supported. > > > > of any table governed by t11ZsServerDatabaseStorageType has an > > > object that is writable, then so too must be the corresponding > > > instance of this object. > > > > > > OK? > > > > Not sure I underatand, so you say this one only needs to be writable > > if any other wrietable object is writable? > > I am confused? > > Doubtful -- it's probably that I've interpreted your comment wrongly. > Here's the conclusion that I "jumped" to: > > RFC 2579 says (for StorageType): > > Every usage of this textual convention is required to > specify the columnar objects which a permanent(4) row must > at a minimum allow to be writable." > > but t11ZsServerDatabaseStorageType is aleady defined in RFC 4936 and > we aren't modifying RFC 4936, and so you want the specification of > "must at a minimum allow to be writable" to be updated in the > DESCRIPTION of t11FcSpZoneSetHashStatus. > > Now, one instance of t11ZsServerDatabaseStorageType covers all the > associated rows of many tables, including rows in this new table > which AUGMENTS t11ZsServerEntry. If t11ZsServerDatabaseStorageType > is 'permanent', then some of the instances in the identified set of > rows might be writeable -- if any are, then the Hash value is likely > to change when such modifying such instances, and so the > corresponding instance of t11FcSpZoneSetHashStatus needs to be > writable. In contrast, if none of the instances of objects in the > identified set of rows are writable, then that instance of > t11FcSpZoneSetHashStatus doesn't need to be writable either. > > Is that what you meant ?? If so, did I capture it in my proposed > addition to t11FcSpZoneSetHashStatus ? > > Keith. > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Jan 07 11:18:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBugU-0007SV-IK; Mon, 07 Jan 2008 11:18:42 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1JBugT-0007Kb-Sf for imss-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 11:18:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBugT-0007FD-Ck for imss@ietf.org; Mon, 07 Jan 2008 11:18:41 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBugS-0000PV-Tc for imss@ietf.org; Mon, 07 Jan 2008 11:18:41 -0500 Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m07GIeoR001010 for ; Mon, 7 Jan 2008 11:18:40 -0500 (EST) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor) for ; Mon, 7 Jan 2008 11:18:40 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m07GIRGV027810 for ; Mon, 7 Jan 2008 11:18:39 -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, 7 Jan 2008 11:18:38 -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, 7 Jan 2008 11:18:38 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085E7E@CORPUSMX20A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FC-SP MIB - consensus check thread-index: AchRSPWe1ji+CuHbTyiyhQe5WwUwYA== To: X-OriginalArrivalTime: 07 Jan 2008 16:18:38.0739 (UTC) FILETIME=[F609C630:01C85148] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Black_David@emc.com Subject: [imss] FC-SP MIB - consensus check 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 MIB Doctor review (many thanks to Bert for his usual detailed level of review) has turned up a few issues that need to be rechecked with the imss WG. The current draft is draft-ietf-imss-fc-fcsp-mib-00.txt: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-fcsp-mib-00.txt In addition to the decision we've already made to delete the CERTS-MIB module, here are the three issues on which comments are requested: 1) In the SA-MIB: > the intent of omitting the FabricIndex from > the INDEX clause of t11FcSpSaTSelPropTable (and t11FcSpSaTransTable) > was so that the same list of Traffic Selectors (or transforms) could be > proposed for multiple SA's even when the SA's are on different Fabrics, > which seemed like it would be useful in some situations. However, the > need to have a StorageType which is common for the lists and for the SA > proposals, introduces an (always present) complication which I think > outweighs the potential (and at most occasional) benefit. That is, I no > longer believe the omission is worthwhile. If the WG agrees, I propose > to change the rows in t11FcSpSaTSelPropTable and t11FcSpSaTransTable to > be per-Fabric, i.e., to add t11FcSpSaIfFabricIndex into the INDEX > clause of the t11FcSpSaTSelPropTable and of the t11FcSpSaTransTable. > (Indeed, the DESCRIPTION of t11FcSpSaIfStorageType is already worded to > assume this change will be made.) 2) In the POLICY-MIB: > The second is that t11FcSpPoAdminFabricNameis read-only, as indeed it > must be because it's part of the Active Policy which cannot be modified > once it's active. So, how is the Fabric name specified when Policy is > in use ?? I believe the answer is that t11FcSpPoNaSummaryFabricName > needs to be added as a read-create object in the t11FcSpPoNaSummaryTable. > If the WG agrees, then I will add this new object. 3) Counter behavior: I want to recheck this: > sysUpTime gets reset to zero in any MIB view which > includes this MIB whenever this Counter32 has a discontinuity. The MIBs have always been specified with this behavior - if something happens that causes the implementation to lose track of the counter values (think hard reset of some form), sysUpTime is reset to zero. Note that Counter32 is essentially a counter modulo 2^32, hence the rollover from 2^32-1 to 0 is not a discontinuity, and SNMP managers are already expecting to sample counter variables often enough to not get confused by this sort of rollover. If anyone has objections to these approaches, please post them to the list by next Monday, January 14th. Absence of objection will be taken as an indication of WG agreement with these approaches. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer 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 Thu Jan 17 20:05:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFffG-0004TQ-Nu; Thu, 17 Jan 2008 20:04:58 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1JFffF-0004RO-G9 for imss-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 20:04:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFffF-0004MU-43 for imss@ietf.org; Thu, 17 Jan 2008 20:04:57 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFffE-0002YU-DH for imss@ietf.org; Thu, 17 Jan 2008 20:04:56 -0500 Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m0I14tuD017587 for ; Thu, 17 Jan 2008 20:04:55 -0500 (EST) Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor) for ; Thu, 17 Jan 2008 20:04:55 -0500 Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m0I14XFH021099 for ; Thu, 17 Jan 2008 20:04:53 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 20:04:34 -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: Thu, 17 Jan 2008 20:04:34 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085F73@CORPUSMX20A.corp.emc.com> In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91085E7E@CORPUSMX20A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FC-SP MIB - consensus check Thread-Index: AchRSPWe1ji+CuHbTyiyhQe5WwUwYAIJIkJQ References: <8CC6CEAB44F131478D3A7B429ECACD91085E7E@CORPUSMX20A.corp.emc.com> To: X-OriginalArrivalTime: 18 Jan 2008 01:04:34.0324 (UTC) FILETIME=[16C36D40:01C8596E] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [imss] RE: FC-SP MIB - consensus check 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 Having seen no comment on this message in the week and a half since it was posted, I believe that the approaches it describes represent the rough consensus of the imss WG. Hence, Keith should prepare and upload a revision of the FC-SP MIB draft that is in accordance with these approaches and contains the other changes identified from Bert's MIB Doctor reviews. That revision should be suitable to be sent to our ADs with a request to publish as an RFC. Thanks, --David (imss WG chair) ---------------------------------------------------- David L. Black, Distinguished Engineer 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: Black, David=20 > Sent: Monday, January 07, 2008 11:19 AM > To: imss@ietf.org > Cc: Black, David > Subject: FC-SP MIB - consensus check >=20 > The MIB Doctor review (many thanks to Bert for his usual > detailed level of review) has turned up a few issues that > need to be rechecked with the imss WG. >=20 > The current draft is draft-ietf-imss-fc-fcsp-mib-00.txt: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-fcsp-mib-00.txt >=20 > In addition to the decision we've already made to delete > the CERTS-MIB module, here are the three issues on which > comments are requested: >=20 > 1) In the SA-MIB: >=20 > > the intent of omitting the FabricIndex from > > the INDEX clause of t11FcSpSaTSelPropTable (and t11FcSpSaTransTable) > > was so that the same list of Traffic Selectors (or transforms) could be > > proposed for multiple SA's even when the SA's are on different Fabrics, > > which seemed like it would be useful in some situations. However, the > > need to have a StorageType which is common for the lists and for the SA > > proposals, introduces an (always present) complication which I think > > outweighs the potential (and at most occasional) benefit. That is, I no > > longer believe the omission is worthwhile. If the WG agrees, I propose > > to change the rows in t11FcSpSaTSelPropTable and t11FcSpSaTransTable to > > be per-Fabric, i.e., to add t11FcSpSaIfFabricIndex into the INDEX > > clause of the t11FcSpSaTSelPropTable and of the t11FcSpSaTransTable. > > (Indeed, the DESCRIPTION of t11FcSpSaIfStorageType is already worded to > > assume this change will be made.) >=20 > 2) In the POLICY-MIB: >=20 > > The second is that t11FcSpPoAdminFabricNameis read-only, as indeed it > > must be because it's part of the Active Policy which cannot be modified > > once it's active. So, how is the Fabric name specified when Policy is > > in use ?? I believe the answer is that t11FcSpPoNaSummaryFabricName > > needs to be added as a read-create object in the t11FcSpPoNaSummaryTable. > > If the WG agrees, then I will add this new object. >=20 > 3) Counter behavior: >=20 > I want to recheck this: >=20 > > sysUpTime gets reset to zero in any MIB view which > > includes this MIB whenever this Counter32 has a discontinuity. >=20 > The MIBs have always been specified with this behavior - if > something happens that causes the implementation to lose track > of the counter values (think hard reset of some form), sysUpTime > is reset to zero. Note that Counter32 is essentially a counter > modulo 2^32, hence the rollover from 2^32-1 to 0 is not a > discontinuity, and SNMP managers are already expecting to sample > counter variables often enough to not get confused by this > sort of rollover. >=20 > If anyone has objections to these approaches, please post them > to the list by next Monday, January 14th. Absence of objection > will be taken as an indication of WG agreement with these > approaches. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > 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 > ---------------------------------------------------- >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From shirin@der.com Thu Jan 31 23:49:11 2008 Return-Path: X-Original-To: ietfarch-imss-archive@core3.amsl.com Delivered-To: ietfarch-imss-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D333A6842 for ; Thu, 31 Jan 2008 23:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 75.088 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=75.088 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_DHCP=1.295, HTML_MESSAGE=1, MANGLED_CIALIS=2.5, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_DRUG_GAP_C=0.003, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 4.3 HELO_DYNAMIC_HCC Relay HELO'd using suspicious hostname (HCC) * 1.3 HOST_EQ_DHCP HOST_EQ_DHCP * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 0.0 SUBJECT_DRUG_GAP_C Subject contains a gappy version of 'cialis' * 2.5 MANGLED_CIALIS BODY: mangled Cialis * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: colonysettle.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: colonysettle.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: colonysettle.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [71.54.75.16 listed in dnsbl.sorbs.net] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: colonysettle.com] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [71.54.75.16 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 1.5 DRUGS_ERECTILE_OBFU Obfuscated reference to an erectile drug * 1.0 DRUGS_ERECTILE Refers to an erectile drug * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZx51i5bH+sY for ; Thu, 31 Jan 2008 23:49:11 -0800 (PST) Received: from oh-71-54-75-16.dhcp.embarqhsd.net (oh-71-54-75-16.dhcp.embarqhsd.net [71.54.75.16]) by core3.amsl.com (Postfix) with ESMTP id A847D3A6813 for ; Thu, 31 Jan 2008 23:49:10 -0800 (PST) Message-ID: <000501c864a7$04939481$789511ae@ucfvyvej> From: "claudianus cyprian" To: Subject: ***SPAM*** 75.088 (5) CIALLIS. Huge Discount Today! Date: Fri, 01 Feb 2008 06:03:23 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C864A7.04921CB8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C864A7.04921CB8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you develop dizziness, nausea, or angina (pain, tightness, = discomfort, numbness, or tingling in the chest, arms, neck, or jaw) = during sexual activity, refrain from further sexual activity and notify = your doctor. CIALLIS. Huge Discount Today! Indian ccheap piills ------=_NextPart_000_0002_01C864A7.04921CB8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If you develop dizziness, nausea, or angina (pain, tightness, = discomfort, numbness, or tingling in the chest, arms, neck, or jaw) = during sexual activity, refrain from further sexual activity and notify = your doctor.

CIALLIS. Huge = Discount Today! Indian ccheap piills

------=_NextPart_000_0002_01C864A7.04921CB8--