From imss-bounces@ietf.org Thu Nov 01 13:12:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IndaR-00047s-0p; Thu, 01 Nov 2007 13:12:07 -0400 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IndaQ-000473-Be for imss-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 13:12:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IndaQ-00041X-1l for imss@ietf.org; Thu, 01 Nov 2007 13:12:06 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Inda9-0001CN-0L for imss@ietf.org; Thu, 01 Nov 2007 13:11:58 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lA1HBNtg001363; Thu, 1 Nov 2007 13:11:23 -0400 (EDT) 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 lA1HAh1s023325; Thu, 1 Nov 2007 13:11:21 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 13:09:50 -0400 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, 1 Nov 2007 13:10:12 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: imss WG Last Call: FC-SP MIB Thread-Index: AcgK0vLbbD32Q+kDSKqF52DDcvyXNQR1sm7Q References: To: , X-OriginalArrivalTime: 01 Nov 2007 17:09:50.0301 (UTC) FILETIME=[0327B0D0:01C81CAA] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 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-Spam-Score: -4.0 (----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Black_David@emc.com Subject: [imss] RE: imss WG Last Call: FC-SP 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 The WG Last Call on this MIB has ended, but in addition to my comments, I think it would be prudent to wait for Bert to finish wading through this MIB before producing a revised version and submitting it to the ADs/IESG. Bert - do you have a timeframe for completing your review. 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: Tuesday, October 09, 2007 8:18 PM > To: 'imss@ietf.org' > Cc: Black, David; 'Romascanu, Dan (Dan)' > Subject: imss WG Last Call: FC-SP MIB > Importance: High >=20 > This is to announce an imss WG Last Call on the following > MIB draft: >=20 > MIB for Fibre-Channel Security Protocols (FC-SP) > draft-ietf-imss-fc-fcsp-mib-00.txt >=20 > This WG Last Call will run through 12 midnight Eastern Time on > Friday, October 26, 2007 (your WG chair hopes to deal with > Last Call results during the week of October 29th and hopes > that any revisions can be completed prior to the November > 19th Internet Draft submission cutoff for the Vancouver meeting). >=20 > Technical comments *must* be sent to the imss mailing list. > Editorial comments may be sent directly to the draft editor > (but please cc: me): >=20 > Keith McCloghrie [kzm@cisco.com] >=20 > In order to try to set a good example, I have completed my > WG chair review of the MIB prior to announcing this Last Call. >=20 > I found two technical concerns: > (1) The MIB defines precedence values for traffic selectors > as opposed to implicitly presenting them in order of > precedence. I guess this is ok, but Section 4.7 should > explain why this approach was chosen. > (2) Section 4.9 defines rate control for Authentication > failures on a per-fabric granularity. That strikes > me as overly coarse, and I wonder if per-SA would > be a more appropriate/useful granularity. >=20 > I also found a number of editorial concerns: >=20 > Section 1, 2nd paragraph. Remove the sentence starting > with "This latest draft" or insert an instruction to the > RFC Editor to remove it before publication as an RFC. >=20 > Section 3.1 - Delete "The" at the start of the first paragraph. >=20 > Should Section 3.5 and subsequent subsections of Section 3 > all be subsections of Section 3.4 Security? >=20 > Section 3.10 - "To provide better scaling, the Switch Connectivity > Objects are not Fabric-wide information such that they are > distributed only to where they are needed." >=20 > "information such that they are" -> information, but are" >=20 > Section 3.10 introduces "Active Zone Set" but does not explain > what this term means. >=20 > T11FcSpPolicyNameType - the DESCRIPTION needs to explain the > concept of "restricted" - how does a "restricted" entity > differ from the corresponding unrestricted entity? >=20 > 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 > ---------------------------------------------------- >=20 >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Fri Nov 02 11:08:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iny8e-0007dP-32; Fri, 02 Nov 2007 11:08:48 -0400 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1Iny8c-0007dB-V6 for imss-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 11:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iny8c-0007d3-LZ for imss@ietf.org; Fri, 02 Nov 2007 11:08:46 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iny8X-0000tT-DJ for imss@ietf.org; Fri, 02 Nov 2007 11:08:46 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lA2F7FSG027782; Fri, 2 Nov 2007 10:08:22 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Nov 2007 10:07:24 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Nov 2007 16:07:22 +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: Fri, 2 Nov 2007 16:07:21 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: imss WG Last Call: FC-SP MIB Thread-Index: AcgK0vLbbD32Q+kDSKqF52DDcvyXNQR1sm7QACzkDYA= References: From: "WIJNEN, Bert \(Bert\)" To: , X-OriginalArrivalTime: 02 Nov 2007 15:07:22.0185 (UTC) FILETIME=[11BFEB90:01C81D62] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Subject: [imss] RE: imss WG Last Call: FC-SP 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 David, Things are not going as I wanted.=20 I was on vacation for a week, just returned this morning. I have serious workload next week that I must give priority. The week after I am at IEEE 802.1 meetings (with quite a bit of MIB related work as well). So It seem it will be at least in the last week of November that I can seriously get to it (I had planned (in fact I started) to do so earlier). But it is also possible that yet other high priority activities get in the=20 way at that time. Can't elaborate now on that though. I will not feel offended if you do not want to wait for that=20 and instead look for another MIB Doctor for review. Bert Wijnen =20 > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > Sent: Thursday, November 01, 2007 6:10 PM > To: imss@ietf.org; WIJNEN, Bert (Bert) > Cc: Black_David@emc.com > Subject: RE: imss WG Last Call: FC-SP MIB >=20 > The WG Last Call on this MIB has ended, but in addition to my=20 > comments, I think it would be prudent to wait for Bert to=20 > finish wading through this MIB before producing a revised=20 > version and submitting it to the ADs/IESG. >=20 > Bert - do you have a timeframe for completing your review. >=20 > 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 > ---------------------------------------------------- >=20 > > -----Original Message----- > > From: Black, David > > Sent: Tuesday, October 09, 2007 8:18 PM > > To: 'imss@ietf.org' > > Cc: Black, David; 'Romascanu, Dan (Dan)' > > Subject: imss WG Last Call: FC-SP MIB > > Importance: High > >=20 > > This is to announce an imss WG Last Call on the following MIB draft: > >=20 > > MIB for Fibre-Channel Security Protocols (FC-SP) > > draft-ietf-imss-fc-fcsp-mib-00.txt > >=20 > > This WG Last Call will run through 12 midnight Eastern Time=20 > on Friday,=20 > > October 26, 2007 (your WG chair hopes to deal with Last=20 > Call results=20 > > during the week of October 29th and hopes that any revisions can be=20 > > completed prior to the November 19th Internet Draft=20 > submission cutoff=20 > > for the Vancouver meeting). > >=20 > > Technical comments *must* be sent to the imss mailing list. > > Editorial comments may be sent directly to the draft editor (but=20 > > please cc: me): > >=20 > > Keith McCloghrie [kzm@cisco.com] > >=20 > > In order to try to set a good example, I have completed my WG chair=20 > > review of the MIB prior to announcing this Last Call. > >=20 > > I found two technical concerns: > > (1) The MIB defines precedence values for traffic selectors > > as opposed to implicitly presenting them in order of > > precedence. I guess this is ok, but Section 4.7 should > > explain why this approach was chosen. > > (2) Section 4.9 defines rate control for Authentication > > failures on a per-fabric granularity. That strikes > > me as overly coarse, and I wonder if per-SA would > > be a more appropriate/useful granularity. > >=20 > > I also found a number of editorial concerns: > >=20 > > Section 1, 2nd paragraph. Remove the sentence starting with "This=20 > > latest draft" or insert an instruction to the RFC Editor to=20 > remove it=20 > > before publication as an RFC. > >=20 > > Section 3.1 - Delete "The" at the start of the first paragraph. > >=20 > > Should Section 3.5 and subsequent subsections of Section 3 all be=20 > > subsections of Section 3.4 Security? > >=20 > > Section 3.10 - "To provide better scaling, the Switch Connectivity > > Objects are not Fabric-wide information such that they are > > distributed only to where they are needed." > >=20 > > "information such that they are" -> information, but are" > >=20 > > Section 3.10 introduces "Active Zone Set" but does not explain what=20 > > this term means. > >=20 > > T11FcSpPolicyNameType - the DESCRIPTION needs to explain=20 > the concept=20 > > of "restricted" - how does a "restricted" entity differ from the=20 > > corresponding unrestricted entity? > >=20 > > 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 > > ---------------------------------------------------- > >=20 > >=20 >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Fri Nov 16 11:57:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4Vi-0008Pd-RA; Fri, 16 Nov 2007 11:57:42 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1It4Vh-0008PO-7d for imss-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 11:57:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4Vg-0008P9-S7 for imss@ietf.org; Fri, 16 Nov 2007 11:57:40 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It4Vg-0002os-5r for imss@ietf.org; Fri, 16 Nov 2007 11:57:40 -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 lAGGvWeQ010154; Fri, 16 Nov 2007 11:57:32 -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); Fri, 16 Nov 2007 11:57:32 -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 lAGGujjV026205; Fri, 16 Nov 2007 11:57:29 -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); Fri, 16 Nov 2007 11:57:14 -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: Fri, 16 Nov 2007 11:57:13 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: imss WG Last Call: FC-SP MIB Thread-index: AcgK0vLbbD32Q+kDSKqF52DDcvyXNQR1sm7QACzkDYACxRH+oA== References: To: , X-OriginalArrivalTime: 16 Nov 2007 16:57:14.0358 (UTC) FILETIME=[BCC63160:01C82871] 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_NOT_1 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: 29dc808194f5fb921c09d0040806d6eb Cc: Subject: [imss] RE: imss WG Last Call: FC-SP 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, If there's a reasonable possibility that you'll be able to complete this review by the end of the year, I'd prefer to wait for that review rather than go looking for another MIB doctor (which could take even longer). Is that a reasonable possibility? 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 ---------------------------------------------------- > -----Original Message----- > From: WIJNEN, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com]=20 > Sent: Friday, November 02, 2007 11:07 AM > To: Black, David; imss@ietf.org > Subject: RE: imss WG Last Call: FC-SP MIB >=20 > David, >=20 > Things are not going as I wanted.=20 > I was on vacation for a week, just returned this morning. >=20 > I have serious workload next week that I must give priority. > The week after I am at IEEE 802.1 meetings (with quite a bit > of MIB related work as well). So It seem it will be at least in > the last week of November that I can seriously get to it (I had > planned (in fact I started) to do so earlier). But it is > also possible that yet other high priority activities get in the=20 > way at that time. Can't elaborate now on that though. >=20 > I will not feel offended if you do not want to wait for that=20 > and instead look for another MIB Doctor for review. >=20 > Bert Wijnen =20 >=20 > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > > Sent: Thursday, November 01, 2007 6:10 PM > > To: imss@ietf.org; WIJNEN, Bert (Bert) > > Cc: Black_David@emc.com > > Subject: RE: imss WG Last Call: FC-SP MIB > >=20 > > The WG Last Call on this MIB has ended, but in addition to my=20 > > comments, I think it would be prudent to wait for Bert to=20 > > finish wading through this MIB before producing a revised=20 > > version and submitting it to the ADs/IESG. > >=20 > > Bert - do you have a timeframe for completing your review. > >=20 > > 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 > > ---------------------------------------------------- > >=20 > > > -----Original Message----- > > > From: Black, David > > > Sent: Tuesday, October 09, 2007 8:18 PM > > > To: 'imss@ietf.org' > > > Cc: Black, David; 'Romascanu, Dan (Dan)' > > > Subject: imss WG Last Call: FC-SP MIB > > > Importance: High > > >=20 > > > This is to announce an imss WG Last Call on the following=20 > MIB draft: > > >=20 > > > MIB for Fibre-Channel Security Protocols (FC-SP) > > > draft-ietf-imss-fc-fcsp-mib-00.txt > > >=20 > > > This WG Last Call will run through 12 midnight Eastern Time=20 > > on Friday,=20 > > > October 26, 2007 (your WG chair hopes to deal with Last=20 > > Call results=20 > > > during the week of October 29th and hopes that any=20 > revisions can be=20 > > > completed prior to the November 19th Internet Draft=20 > > submission cutoff=20 > > > for the Vancouver meeting). > > >=20 > > > Technical comments *must* be sent to the imss mailing list. > > > Editorial comments may be sent directly to the draft editor (but=20 > > > please cc: me): > > >=20 > > > Keith McCloghrie [kzm@cisco.com] > > >=20 > > > In order to try to set a good example, I have completed=20 > my WG chair=20 > > > review of the MIB prior to announcing this Last Call. > > >=20 > > > I found two technical concerns: > > > (1) The MIB defines precedence values for traffic selectors > > > as opposed to implicitly presenting them in order of > > > precedence. I guess this is ok, but Section 4.7 should > > > explain why this approach was chosen. > > > (2) Section 4.9 defines rate control for Authentication > > > failures on a per-fabric granularity. That strikes > > > me as overly coarse, and I wonder if per-SA would > > > be a more appropriate/useful granularity. > > >=20 > > > I also found a number of editorial concerns: > > >=20 > > > Section 1, 2nd paragraph. Remove the sentence starting=20 > with "This=20 > > > latest draft" or insert an instruction to the RFC Editor to=20 > > remove it=20 > > > before publication as an RFC. > > >=20 > > > Section 3.1 - Delete "The" at the start of the first paragraph. > > >=20 > > > Should Section 3.5 and subsequent subsections of Section 3 all be=20 > > > subsections of Section 3.4 Security? > > >=20 > > > Section 3.10 - "To provide better scaling, the Switch Connectivity > > > Objects are not Fabric-wide information such that they are > > > distributed only to where they are needed." > > >=20 > > > "information such that they are" -> information, but are" > > >=20 > > > Section 3.10 introduces "Active Zone Set" but does not=20 > explain what=20 > > > this term means. > > >=20 > > > T11FcSpPolicyNameType - the DESCRIPTION needs to explain=20 > > the concept=20 > > > of "restricted" - how does a "restricted" entity differ from the=20 > > > corresponding unrestricted entity? > > >=20 > > > 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 > > > ---------------------------------------------------- > > >=20 > > >=20 > >=20 >=20 >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Fri Nov 16 13:58:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It6OY-00052j-0v; Fri, 16 Nov 2007 13:58:26 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1It6OW-00052I-PR for imss-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 13:58:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It6OW-000528-Fh for imss@ietf.org; Fri, 16 Nov 2007 13:58:24 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It6OQ-0001hw-9r for imss@ietf.org; Fri, 16 Nov 2007 13:58:24 -0500 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lAGIwDQX028620; Fri, 16 Nov 2007 12:58:13 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 12:58:12 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 19:58:10 +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: Fri, 16 Nov 2007 19:57:34 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: imss WG Last Call: FC-SP MIB Thread-Index: AcgK0vLbbD32Q+kDSKqF52DDcvyXNQR1sm7QACzkDYACxRH+oAAEOUpw References: From: "WIJNEN, Bert \(Bert\)" To: , X-OriginalArrivalTime: 16 Nov 2007 18:58:10.0309 (UTC) FILETIME=[A1A87350:01C82882] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: Subject: [imss] RE: imss WG Last Call: FC-SP 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 Yes, I can commit to complete this before the end of the year. Bert Wijnen =20 > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > Sent: Friday, November 16, 2007 11:57 AM > To: WIJNEN, Bert (Bert); imss@ietf.org > Subject: RE: imss WG Last Call: FC-SP MIB >=20 > Bert, >=20 > If there's a reasonable possibility that you'll be able to=20 > complete this review by the end of the year, I'd prefer to=20 > wait for that review rather than go looking for another MIB=20 > doctor (which could take even longer). Is that a reasonable=20 > possibility? >=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 > > -----Original Message----- > > From: WIJNEN, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > Sent: Friday, November 02, 2007 11:07 AM > > To: Black, David; imss@ietf.org > > Subject: RE: imss WG Last Call: FC-SP MIB > >=20 > > David, > >=20 > > Things are not going as I wanted.=20 > > I was on vacation for a week, just returned this morning. > >=20 > > I have serious workload next week that I must give priority. > > The week after I am at IEEE 802.1 meetings (with quite a bit of MIB=20 > > related work as well). So It seem it will be at least in=20 > the last week=20 > > of November that I can seriously get to it (I had planned=20 > (in fact I=20 > > started) to do so earlier). But it is also possible that yet other=20 > > high priority activities get in the way at that time. Can't=20 > elaborate=20 > > now on that though. > >=20 > > I will not feel offended if you do not want to wait for that and=20 > > instead look for another MIB Doctor for review. > >=20 > > Bert Wijnen > >=20 > > > -----Original Message----- > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > Sent: Thursday, November 01, 2007 6:10 PM > > > To: imss@ietf.org; WIJNEN, Bert (Bert) > > > Cc: Black_David@emc.com > > > Subject: RE: imss WG Last Call: FC-SP MIB > > >=20 > > > The WG Last Call on this MIB has ended, but in addition to my=20 > > > comments, I think it would be prudent to wait for Bert to finish=20 > > > wading through this MIB before producing a revised version and=20 > > > submitting it to the ADs/IESG. > > >=20 > > > Bert - do you have a timeframe for completing your review. > > >=20 > > > Thanks, > > > --David (imss WG chair) > > > ---------------------------------------------------- > > > David L. Black, Distinguished Engineer EMC Corporation, 176 South=20 > > > St., Hopkinton, MA 01748 > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > >=20 > > > > -----Original Message----- > > > > From: Black, David > > > > Sent: Tuesday, October 09, 2007 8:18 PM > > > > To: 'imss@ietf.org' > > > > Cc: Black, David; 'Romascanu, Dan (Dan)' > > > > Subject: imss WG Last Call: FC-SP MIB > > > > Importance: High > > > >=20 > > > > This is to announce an imss WG Last Call on the following > > MIB draft: > > > >=20 > > > > MIB for Fibre-Channel Security Protocols (FC-SP) > > > > draft-ietf-imss-fc-fcsp-mib-00.txt > > > >=20 > > > > This WG Last Call will run through 12 midnight Eastern Time > > > on Friday, > > > > October 26, 2007 (your WG chair hopes to deal with Last > > > Call results > > > > during the week of October 29th and hopes that any > > revisions can be > > > > completed prior to the November 19th Internet Draft > > > submission cutoff > > > > for the Vancouver meeting). > > > >=20 > > > > Technical comments *must* be sent to the imss mailing list. > > > > Editorial comments may be sent directly to the draft=20 > editor (but=20 > > > > please cc: me): > > > >=20 > > > > Keith McCloghrie [kzm@cisco.com] > > > >=20 > > > > In order to try to set a good example, I have completed > > my WG chair > > > > review of the MIB prior to announcing this Last Call. > > > >=20 > > > > I found two technical concerns: > > > > (1) The MIB defines precedence values for traffic selectors > > > > as opposed to implicitly presenting them in order of > > > > precedence. I guess this is ok, but Section 4.7 should > > > > explain why this approach was chosen. > > > > (2) Section 4.9 defines rate control for Authentication > > > > failures on a per-fabric granularity. That strikes > > > > me as overly coarse, and I wonder if per-SA would > > > > be a more appropriate/useful granularity. > > > >=20 > > > > I also found a number of editorial concerns: > > > >=20 > > > > Section 1, 2nd paragraph. Remove the sentence starting > > with "This > > > > latest draft" or insert an instruction to the RFC Editor to > > > remove it > > > > before publication as an RFC. > > > >=20 > > > > Section 3.1 - Delete "The" at the start of the first paragraph. > > > >=20 > > > > Should Section 3.5 and subsequent subsections of=20 > Section 3 all be=20 > > > > subsections of Section 3.4 Security? > > > >=20 > > > > Section 3.10 - "To provide better scaling, the Switch=20 > Connectivity > > > > Objects are not Fabric-wide information such that they are > > > > distributed only to where they are needed." > > > >=20 > > > > "information such that they are" -> information, but are" > > > >=20 > > > > Section 3.10 introduces "Active Zone Set" but does not > > explain what > > > > this term means. > > > >=20 > > > > T11FcSpPolicyNameType - the DESCRIPTION needs to explain > > > the concept > > > > of "restricted" - how does a "restricted" entity differ=20 > from the=20 > > > > corresponding unrestricted entity? > > > >=20 > > > > Thanks, > > > > --David > > > > ---------------------------------------------------- > > > > David L. Black, Senior Technologist EMC Corporation, 176 South=20 > > > > St., Hopkinton, MA 01748 > > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > > ---------------------------------------------------- > > > >=20 > > > >=20 > > >=20 > >=20 > >=20 >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Nov 26 09:47:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfEp-00073N-PQ; Mon, 26 Nov 2007 09:47:07 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IwfEo-000735-Il for imss-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 09:47:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfEo-00072b-6M for imss@ietf.org; Mon, 26 Nov 2007 09:47:06 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwfEn-00022s-A3 for imss@ietf.org; Mon, 26 Nov 2007 09:47:06 -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 lAQEl12n016395; Mon, 26 Nov 2007 08:47:01 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 08:47:01 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 15:46: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 Date: Mon, 26 Nov 2007 15:46:51 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIB doctor review part 1 (SYNTAX Checks): draft-ietf-imss-fc-fcsp-mib-00.txt Thread-Index: AcgK0vLbbD32Q+kDSKqF52DDcvyXNQR1sm7QACzkDYACxRH+oAAEOUpwAevc29A= References: From: "WIJNEN, Bert \(Bert\)" To: , X-OriginalArrivalTime: 26 Nov 2007 14:46:58.0880 (UTC) FILETIME=[32846400:01C8303B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: Subject: [imss] MIB doctor review part 1 (SYNTAX Checks): draft-ietf-imss-fc-fcsp-mib-00.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 1. T11-FC-SP-TC-MIB C:\bwijnen\smicng\imss>smicng T11-FC-SP-TC-MIB.inc W: f(T11-FC-SP-TC-MIB), (40,15) The first revision should match the last update for MODULE-IDENTITY t11FcTcMIB *** 0 errors and 1 warning in parsing C:\bwijnen\smicng\imss>smilint ./T11-FC-SP-TC-MIB ./T11-FC-SP-TC-MIB:44: revision for last update is missing I think it would be good to to get the REVISION and LAST-UPDATED timestamps in sync. No big deal though. 2. T11-FC-SP-ZONING-MIB C:\bwijnen\smicng\imss>smicng T11-FC-SP-ZONING-MIB.inc W: f(T11-FC-SP-ZONING-MIB), (404,20) Variable "ifIndex" in notification "t11FcSpZsFabricJoinSuccessNotify" is an index for a table W: f(T11-FC-SP-ZONING-MIB), (420,20) Variable "ifIndex" in notification "t11FcSpZsFabricJoinFailureNotify" is an index for a table *** 0 errors and 2 warnings in parsing C:\bwijnen\smicng\imss>smilint -l 6 -m -s ./T11-FC-SP-ZONING-MIB .. OK I think this is OK in this situation. 3. T11-FC-SP-SA-MIB C:\bwijnen\smicng\imss>smicng T11-FC-SP-SA-MIB.inc E: f(T11-FC-SP-SA-MIB), (1781,36) Item "t11FcSpSaTSelSpiDirection" in sequence "T11FcSpSaTSelSpiEntry" has conflicting syntax specified bw: caused by INTEGER and T11FcSaDirection TC (which has underlying SYNTAX of INTEGER (enumerated). So I am not sure it is a real error. At the other hand, the/a fix is easy, namely change T11FcSpSaTSelSpiEntry ::=3D SEQUENCE { t11FcSpSaTSelSpiInboundSpi T11FcSpiIndex, t11FcSpSaTSelSpiTrafSelIndex Unsigned32, t11FcSpSaTSelSpiDirection INTEGER, t11FcSpSaTSelSpiTrafSelPtr Unsigned32 } into: T11FcSpSaTSelSpiEntry ::=3D SEQUENCE { t11FcSpSaTSelSpiInboundSpi T11FcSpiIndex, t11FcSpSaTSelSpiTrafSelIndex Unsigned32, t11FcSpSaTSelSpiDirection T11FcSaDirection, t11FcSpSaTSelSpiTrafSelPtr Unsigned32 } It would also make it more consistent with other places where you have used T11FcSaDirection TC. E: f(T11-FC-SP-SA-MIB), (512,14) Index item "t11FcSpSaPropIndex" must be defined with syntax that includes a range bw: I tend to agree with that. For example I wonder of zero is a valid index value. If it is, then we better explicitly include it (and add=20 text to the DESCRIPTION clause what that means). If it is not, then we better exclude it. E: f(T11-FC-SP-SA-MIB), (684,14) Index item "t11FcSpSaTSelPropListIndex" must be defined with syntax that includes a range E: f(T11-FC-SP-SA-MIB), (684,42) Index item "t11FcSpSaTSelPropIndex" must be defined with syntax that includes a range bw: same story for those above 2 error messages. E: f(T11-FC-SP-SA-MIB), (928,14) Index item "t11FcSpSaTransListIndex" must be defined with syntax that includes a range E: f(T11-FC-SP-SA-MIB), (928,39) Index item "t11FcSpSaTransIndex" must be defined with syntax that includes a range bw: same story for those above 2 error messages. E: f(T11-FC-SP-SA-MIB), (1069,42) Index item "t11FcSpSaTSelDrByPrecedence" must be defined with syntax that includes a range bw: would be easy to fix in TC module: T11FcSpPrecedence ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The precedence of a Traffic Selector. If a frame matches with two or more Traffic Selectors, then the match which takes precedence is the one with the Traffic Selector having the numerically smallest precedence value. Note that precedence values are not necessarily contiguous." SYNTAX Unsigned32 -- the default range: (0..4294967295) Why not just specify that range. It makes sense (I guess) that a value of zero in this case is valid, and so would also be a valid/acceptable INDEX value. We betetr make that explicit (or so I think). E: f(T11-FC-SP-SA-MIB), (1259,38) Index item "t11FcSpSaPairInboundSpi" must be defined with syntax that includes a range bw: same as above. E: f(T11-FC-SP-SA-MIB), (1457,38) Index item "t11FcSpSaTSelNegInIndex" must be defined with syntax that includes a range bw: SO is zero a valid/acceptable index? If so we better explicitly include that. If not, then we must exclude it. E: f(T11-FC-SP-SA-MIB), (1624,38) Index item "t11FcSpSaTSelNegOutPrecedence" must be defined with syntax that includes a range bw: see comment above on the use of T11FcSpPrecedence TC E: f(T11-FC-SP-SA-MIB), (1774,14) Index item "t11FcSpSaTSelSpiInboundSpi" must be defined with syntax that includes a range bw: see above E: f(T11-FC-SP-SA-MIB), (1774,42) Index item "t11FcSpSaTSelSpiTrafSelIndex" must be defined with syntax that includes a range bw: Is zero a valid/acceptable value. It seems to me that in this case we prefer NOT to allow for zero. So make that explicit. W: f(T11-FC-SP-SA-MIB), (1257,32) Row "t11FcSpSaPairEntry" does not have a consistent indexing scheme - index items from current table must come after index items from other tables W: f(T11-FC-SP-SA-MIB), (1456,32) Row "t11FcSpSaTSelNegInEntry" does not have a consistent indexing scheme - cannot specify an index item from additional "base row" t11FcSpSaPairEntry, since can have only one "base row" which is t11FcSpSaIfEntry W: f(T11-FC-SP-SA-MIB), (1623,32) Row "t11FcSpSaTSelNegOutEntry" does not have a consistent indexing scheme - cannot specify an index item from additional "base row" t11FcSpSaPairEntry, since can have only one "base row" which is t11FcSpSaIfEntry W: f(T11-FC-SP-SA-MIB), (1772,32) Row "t11FcSpSaTSelSpiEntry" does not have a consistent indexing scheme - cannot specify an index item from additional "base row" t11FcSpSaPairEntry, since can have only one "base row" which is t11FcSpSaIfEntry The "non-consistent indexing scheme" issue is possibly just a warning. In these cases I always ask the author: Pls check that what you did is what you intended. If so, then I think the above 4 are fine. I must say that the indexing certainly is not immediately obvious. I will need to go look in detail to convince myself. *** 12 errors and 4 warnings in parsing C:\bwijnen\smicng\imss>smilint -l 6 -m -s ./T11-FC-SP-ZONING-MIB .. OK 4. T11-FC-SP-POLICY-MIB C:\bwijnen\smicng\imss>smicng T11-FC-SP-POLICY-MIB.inc E: f(T11-FC-SP-POLICY-MIB), (1528,14) Index item "t11FcSpPoAuthProtIdentifier" must be defined with syntax that includes a range bw: Assuming that http://www.t11.org/ftp/t11/pub/fc/sp/06-157v3.pdf=20 is the proper document to look at, for table 11. From that table one could conclude that value zero is part of the "all others", but at the other hand, I would have put value zero as reserved at the top of the table if value zero is valid.=20 =20 So... is it valid? In any event, I would make the range (0-4billion) or 1-4billion) explicit I think. E: f(T11-FC-SP-POLICY-MIB), (3443,14) Index item "t11FcSpPoNaAuthProtIdentifier" must be defined with syntax that includes a range bw: same story. *** 2 errors and 0 warnings in parsing C:\bwijnen\smicng\imss>smilint -l 6 -m -s ./T11-FC-SP-POLICY-MIB .. OK 5. T11-FC-SP-CERTS-MIB C:\bwijnen\smicng\imss>smicng T11-FC-SP-CERTS-MIB.inc E: f(T11-FC-SP-CERTS-MIB), (90,38) Index item "t11FcSpCertIndex" must be defined with syntax that includes a range bw: seems (to me) that we would want to exlude zero as an acceptable value. *** 1 error and 0 warnings in parsing C:\bwijnen\smicng\imss>smilint -l 6 -m -s ./T11-FC-SP-CERTS-MIB .. OK 6. T11-FC-SP-AUTHENTICATION-MIB C:\bwijnen\smicng\imss>smicng T11-FC-SP-AUTHENTICATION-MIB.inc Successful parsing C:\bwijnen\smicng\imss>smilint -l 6 -m -s ./T11-FC-SP-AUTHENTICATION-MIB .. OK Bert=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Nov 26 10:01:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfTA-00030s-Hh; Mon, 26 Nov 2007 10:01:56 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IwfT9-00030m-Nk for imss-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 10:01:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfT9-00030e-Bi for imss@ietf.org; Mon, 26 Nov 2007 10:01:55 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwfT8-0002TX-Bq for imss@ietf.org; Mon, 26 Nov 2007 10:01:55 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lAQF1HCB004074; Mon, 26 Nov 2007 09:01:28 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 09:01:05 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 16:00:52 +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] imss WG Last Call: FC-SP MIB Date: Mon, 26 Nov 2007 16:00:47 +0100 Message-ID: In-Reply-To: <200710151854.LAA02590@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [imss] imss WG Last Call: FC-SP MIB Thread-Index: AcgPXRO5h3Kzqqb5SCuOiJkT514reQg3opdQ References: from "WIJNEN, Bert \(Bert\)" at Oct 15, 2007 11:58:52 AM <200710151854.LAA02590@cisco.com> From: "WIJNEN, Bert \(Bert\)" To: "Keith McCloghrie" X-OriginalArrivalTime: 26 Nov 2007 15:00:52.0379 (UTC) FILETIME=[23523EB0:01C8303D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 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 W.r.t. > > One thing I do see that may need some action is the fact that this=20 > > document has normative dependencies on these 2 documents: > >=20 > > [IPSP-IKE-ACTION] > > Baer, M., Charlet, R., Hardaker, W., Story, R., and C. Wang, "IPsec > > Security Policy IKE Action MIB", draft-ietf-ipsp-ikeaction-mib- > > nn.txt, work-in-progress, 19 October 2006. > >=20 > > [IPSP-IPSEC-ACTION] > > Baer, M., Charlet, R., Hardaker, W., Story, R., and C. Wang, "IPsec > > Security Policy IPsec Action MIB", draft-ietf-ipsp-ipsecaction-mib- > > nn.txt, work-in-progress, 19 October 2006. > >=20 > >=20 > > However, I do not see that any IMPORT is done for those 2 IPSP MIB=20 > > modules, so maybe the dependency is not really normative? >=20 > I agree that such a "dependency" is a little risky, because I=20 > too submitted some comments on those MIBs. The reason that=20 > I'm using quotes around "dependency" is because it is not the=20 > definitions in this MIB which depend on any definitions in=20 > those MIBs, but rather the explanation of why this MIB has=20 > the set of (certificate-related) objects that it does. =20 > Without such explanations, the definitions in this MIB would=20 > appear incomplete, and it seems to me that making it complete=20 > requires either: >=20 > 1. the reference to the IPSP MIB modules that it currently=20 > has, or 2. definition of new MIB objects which=20 > duplicate/overlap with the IPSP MIB modules. >=20 > Given that the IPSP MIB modules are still expected to get=20 > approved (in the future), then I'd say #2 is at least=20 > undesirable, and probably unacceptable. >=20 yep... that sounds unacceptable. At the other hand, you may end up having you approved I-D in the RFC-Editor queue for many years to come waiting for the dependent IPSP MIB module documents to come through (sorry... even though there was a message about the status of IPSP MIB modules in August this year, I have seen no activity since. I keep being very pessimistic about a reasonable result in this space). Maybe one of the ADs (possibly security ADs) can say something about this issue or about the "dependency". As long as the docs are listed as normative references, your doc will get block at the RFC-Editor gates till those normative docs are ready to become an RFC as well. > So, if you can provide guidance on how to reference the IPSP=20 > MIB modules in a way which avoids creating normative=20 > dependencies, then please do. >=20 If I read your section 4.6, then it seems that the=20 ipsaCredentialTable, the ipsaCredentialSegmentTable and the ipiaCredMngCRLTable are needed to manage CAs and CRLs. So that to me seems quite a dependency. Are you guys aware of how your implementations will/might run without those tables? Have they currently been implemented in prorpietary ways? Or have pre-RFC implementations been fielded?=20 >From sect 4.6, it seems that your MODULE-COMPLIANCE ought to state that those tables from IPSP MIB modules have to be supported in order to let your MIB modules/security-features work, no? Bert > Keith. >=20 >=20 > > I will find out when > > I read the whole FC-SP MIB document. Sofar I did notice: > >=20 > > - 4.8.6. The T11-FC-SP-CERTS-MIB Module > >=20 > > This MIB module specifies extensions to IPSP MIBs=20 > [IPSP-IPSEC-ACTION] > > and [IPSP-IKE-ACTION] which are specific to Fibre Channel. In > > particular, it specifies one table, t11FcSpCertsTable,=20 > with a row per > > certificate indicating how that certificate is being used, and > > containing the "name" of the certificate. This "name"=20 > can be used to > > obtain information, which is independent of FC-SP, about the > > certificate from the ipsaCredentialTable (and from the > > ipsaCredentialSegmentTable if the certificate is longer than 1024 > > bytes). > >=20 > > - In the T11-FC-SP-CERTS-MIB (page 230/231: > >=20 > > Since FC-SP leverages a subset of IPsec and=20 > IKEv2 (see RFC > > 4595), a subset of the management information defined for > > the use of certificates with IPsec/IKEv2 is also=20 > applicable > > to FC-SP. Thus, this MIB module leverages RFC wwww and > > RFC xxxx for the management of certificates, CAs=20 > and CRLs. > > -- RFC Editor: replace wwww with actual RFC number for > > -- [IPSP-IPSEC-ACTION], and replace xxxx with actual RFC=20 > number for > > -- [IPSP-IKE-ACTION] & remove this note > >=20 > > Specifically, the information defined in this MIB module > > consists of a pointer into the IPsec/IKEv2 MIB modules, > > plus minimal additional item(s) of information which are > > considered to be important in a Fibre Channel=20 > environment. > >=20 > > So it does sound normative. So I have a warning: > >=20 > > I have been reviewing those 2 IPSP documents a few times=20 > over the last=20 > > (mmmm probably) 2-3 or 2-4 years, and I must warn you that=20 > the cycle=20 > > times on those documents are EXTREMELY slow. The current revisions=20 > > are: > >=20 > > draft-ietf-ipsp-ikeaction-mib-02.txt > > draft-ietf-ipsp-ipsecaction-mib-02.txt > >=20 > > which showed up as I-D on 10 Nov 2006, and both are still=20 > in Revised=20 > > ID needed. Those MIB documents are also pretty complex, and=20 > so if/when=20 > > a new revision will eventually show up (if at all), then=20 > whoever needs=20 > > to re-review will need a serious block of time to actually do so. > > My personal experience is pretty bad/sad with those 2=20 > documents, and I=20 > > must admit that I am completely de- or un-motivated at this=20 > point in=20 > > time to re-review them a again if/when they do show up. But=20 > possibly=20 > > Dan can convince me otherwise at that time. > >=20 > > Anyway, I just wanted the authors/editors/wg-chair and WG=20 > members to=20 > > be aware of this risky normative dependency. > >=20 > > Bert Wijnen > >=20 > > > -----Original Message----- > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > Sent: Wednesday, October 10, 2007 2:18 AM > > > To: imss@ietf.org > > > Cc: dromasca@avaya.com; Black_David@emc.com > > > Subject: [imss] imss WG Last Call: FC-SP MIB > > > Importance: High > > >=20 > > > This is to announce an imss WG Last Call on the following=20 > MIB draft: > > >=20 > > > MIB for Fibre-Channel Security Protocols (FC-SP) > > > draft-ietf-imss-fc-fcsp-mib-00.txt > > >=20 > > > This WG Last Call will run through 12 midnight Eastern Time on=20 > > > Friday, October 26, 2007 (your WG chair hopes to deal=20 > with Last Call=20 > > > results during the week of October 29th and hopes that=20 > any revisions=20 > > > can be completed prior to the November 19th Internet Draft=20 > > > submission cutoff for the Vancouver meeting). > > >=20 > > > Technical comments *must* be sent to the imss mailing list. > > > Editorial comments may be sent directly to the draft editor (but=20 > > > please cc: me): > > >=20 > > > Keith McCloghrie [kzm@cisco.com] > > >=20 > > > In order to try to set a good example, I have completed=20 > my WG chair=20 > > > review of the MIB prior to announcing this Last Call. > > >=20 > > > I found two technical concerns: > > > (1) The MIB defines precedence values for traffic selectors > > > as opposed to implicitly presenting them in order of > > > precedence. I guess this is ok, but Section 4.7 should > > > explain why this approach was chosen. > > > (2) Section 4.9 defines rate control for Authentication > > > failures on a per-fabric granularity. That strikes > > > me as overly coarse, and I wonder if per-SA would > > > be a more appropriate/useful granularity. > > >=20 > > > I also found a number of editorial concerns: > > >=20 > > > Section 1, 2nd paragraph. Remove the sentence starting=20 > with "This=20 > > > latest draft" or insert an instruction to the RFC Editor=20 > to remove=20 > > > it before publication as an RFC. > > >=20 > > > Section 3.1 - Delete "The" at the start of the first paragraph. > > >=20 > > > Should Section 3.5 and subsequent subsections of Section 3 all be=20 > > > subsections of Section 3.4 Security? > > >=20 > > > Section 3.10 - "To provide better scaling, the Switch Connectivity > > > Objects are not Fabric-wide information such that they are > > > distributed only to where they are needed." > > >=20 > > > "information such that they are" -> information, but are" > > >=20 > > > Section 3.10 introduces "Active Zone Set" but does not=20 > explain what=20 > > > this term means. > > >=20 > > > T11FcSpPolicyNameType - the DESCRIPTION needs to explain=20 > the concept=20 > > > of "restricted" - how does a "restricted" entity differ from the=20 > > > corresponding unrestricted entity? > > >=20 > > > 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 > > > ---------------------------------------------------- > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > imss mailing list > > > imss@ietf.org > > > https://www1.ietf.org/mailman/listinfo/imss > > >=20 > >=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 Mon Nov 26 12:09:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhSZ-0001Ny-KZ; Mon, 26 Nov 2007 12:09:27 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IwhSZ-0001Ne-1K for imss-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 12:09:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhSY-0001NN-MG; Mon, 26 Nov 2007 12:09:26 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwhSY-0006ca-6j; Mon, 26 Nov 2007 12:09:26 -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 lAQH8kYg004790; Mon, 26 Nov 2007 11:09:18 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 11:08:59 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 18:08:55 +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: Mon, 26 Nov 2007 18:08:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIB doctor review part 2 (T11-FC-SP-TC-MIB): draft-ietf-imss-fc-fcsp-mib-00.txt Thread-Index: AcgK0vLbbD32Q+kDSKqF52DDcvyXNQR1sm7QACzkDYACxRH+oAAEOUpwAevc29AABgTmMA== From: "WIJNEN, Bert \(Bert\)" To: X-OriginalArrivalTime: 26 Nov 2007 17:08:55.0986 (UTC) FILETIME=[071BA120:01C8304F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [imss] MIB doctor review part 2 (T11-FC-SP-TC-MIB): draft-ietf-imss-fc-fcsp-mib-00.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 [bcc to MIB doctors] Here are my comments/questions on the T11-FC-SP-TC-MIB module 1. I find it somewhat weird to see: t11FcTcMIB MODULE-IDENTITY LAST-UPDATED "200708130000Z" ORGANIZATION "For the initial versions, T11. For later versions, the IETF's IMSS Working Group." The one version that gets formally published is the one in the upcoming RFC. At that time there are basically no "initial" versions other than the one in the RFC.=20 2. looking at T11FcSpPolicyHashFormat and T11FcSpPolicyHashValue I wonder if/how often the TCS will need to be updated? And when that is done, a. do we then want to create a new RFC or b. should this become an iana maintained module?=20 If we need to create a new MIB module ourselves (option a), then we could be more specific this time by making the SYNTAX for T11FcSpPolicyHashValue as follows: SYNTAX OCTET STRING (SIZE (20 | 32)) because there are no other lengths possible given the currently specified/valid formats. 3. I am not sure if (how) it is wise to merge values from 3 different tables in the FC-SP spec (tables 17/18, 48 and 52) into one Textual Convention for the code and one for CodeExp. =20 T11FcSpAuthRejectReasonCode T11FcSpAuthRejReasonCodeExp In some cases, not all values are valid, are they? The set of reasons and Reason Explanations is different for the 3 types of messages listed in the DESCRIPTION clause. Maybe it is OK, but I am somewhat worried. 4. T11FcSpPolicyNameType I find it very unfriendly that Internationalized names are not defined/allowed. But I do see that the base spec [FC-SP] does not allow it, so I guess we can only model the spec that T11 has approved (or will approve). 5. Personal and subjective preference: I would rename T11FcSpAlphaNumNameOrNull into T11FcSpAlphaNumNameOrNone The "Null" often makes people think of 0 (zero). 6. As reported by the SYNTAX checkers, I would change the underlying SYNTAX for T11FcSpiIndex and T11FcSpPrecedence to be=20 SYNTAX Unsigned32 (0..4294967295) instead of: SYNTAX Unsigned32 -- the default range: (0..4294967295) 7. I wonder if it would be good (I think it would be) to add a REFERENCE clause to each of the Encryption and Authentication algorithms specified by the OBKECT-IDENTITIES. Bert _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Nov 26 12:23:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwhfv-0001X8-Tl; Mon, 26 Nov 2007 12:23:15 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1Iwhfu-0001Wy-Kr for imss-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 12:23:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwhfu-0001Wq-8c for imss@ietf.org; Mon, 26 Nov 2007 12:23:14 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwhfs-0007VQ-RT for imss@ietf.org; Mon, 26 Nov 2007 12:23:14 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Nov 2007 09:23:12 -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 lAQHNBco010727; Mon, 26 Nov 2007 09:23:12 -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 lAQHNBAx017262; Mon, 26 Nov 2007 17:23:11 GMT Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA27433; Mon, 26 Nov 2007 09:21:28 -0800 (PST) From: Keith McCloghrie Message-Id: <200711261721.JAA27433@cisco.com> Subject: Re: [imss] imss WG Last Call: FC-SP MIB To: bwijnen@alcatel-lucent.com Date: Mon, 26 Nov 2007 09:21:28 -0800 (PST) In-Reply-To: from "WIJNEN, Bert \(Bert\)" at Nov 26, 2007 04:00:47 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=11800; t=1196097792; x=1196961792; 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=20[imss]=20imss=20WG=20Last=20Call=3A=20FC-SP=20MIB |Sender:=20; bh=9dldSm4YspjYpURCi8KhWWaFrCPJL40uRIsGwl4ytuY=; b=uKFjuMyw1mh0WPp+AykDHkAb5As1mBhpsXJsOyBSEbuAyFqw3/tWYY5DWKtybMP5l7b8Bthf T2B88SUQtkO1P5tpc0asGaSzdqzdsG/4rRP3VX9aP0YIzWkxZAT1hXt65qsExszq/55XwPpQHI z41ppyZEyOAdwaUwr80htLDco=; 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: f60fbf3dbcaca652b6d10036f0630412 Cc: imss@ietf.org, dromasca@avaya.com, Keith McCloghrie , Black_David@emc.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 are three alternatives for what we could do: 1. Continue with the "dependency" as-is, but with the additional note on compliance that you suggest. 2. Generalize the "dependency" so that it doesn't actually refer to [IPSP-IKE-ACTION] or [IPSP-IPSEC-ACTION], but instead says something like: Prior to the definition of the T11-FC-SP-CERTS-MIB, work had started in the IETF to specify a set of MIBs for managing IPsec/IKEv2. The work was far enough along for the definition of FC-SP MIBs to leverage them as prior work, and to define a small extension of importance in the Fibre Channel environment. However, the approval process for the IPsec/IKEv2 MIBs was delayed such that the definition of FC-SP MIBs caught-up with and was expected to overtake those for IPsec/IKEv2. In order not to create a dependency, this document defines only the extension, and it does so in a generic manner so that the extension can be applied to any MIB for IPsec/IKEv2, either the completion of the previously-begun work or any alternative which might begin in the future. I think a simple technical change is all that is required to make the definitions (in T11-FC-SP-CERTS-MIB) generic. Specifcially, I suggest we change syntax of t11FcSpCertPointer to be an OID, such that it can point to any table, i.e., not only into the ipsaCredentialTable, but also into any other MIB's table. I think the above would allow the references to be Informational. 3. Decide that the value of the one extra piece of information (t11FcSpCertUsage) is not important enough for this MIB to have any sort of dependency, and to decide not to define the T11-FC-SP-CERTS-MIB at the present time. Keith. > W.r.t. > > > One thing I do see that may need some action is the fact that this > > > document has normative dependencies on these 2 documents: > > > > > > [IPSP-IKE-ACTION] > > > Baer, M., Charlet, R., Hardaker, W., Story, R., and C. Wang, > "IPsec > > > Security Policy IKE Action MIB", draft-ietf-ipsp-ikeaction-mib- > > > nn.txt, work-in-progress, 19 October 2006. > > > > > > [IPSP-IPSEC-ACTION] > > > Baer, M., Charlet, R., Hardaker, W., Story, R., and C. Wang, > "IPsec > > > Security Policy IPsec Action MIB", > draft-ietf-ipsp-ipsecaction-mib- > > > nn.txt, work-in-progress, 19 October 2006. > > > > > > > > > However, I do not see that any IMPORT is done for those 2 IPSP MIB > > > modules, so maybe the dependency is not really normative? > > > > I agree that such a "dependency" is a little risky, because I > > too submitted some comments on those MIBs. The reason that > > I'm using quotes around "dependency" is because it is not the > > definitions in this MIB which depend on any definitions in > > those MIBs, but rather the explanation of why this MIB has > > the set of (certificate-related) objects that it does. > > Without such explanations, the definitions in this MIB would > > appear incomplete, and it seems to me that making it complete > > requires either: > > > > 1. the reference to the IPSP MIB modules that it currently > > has, or 2. definition of new MIB objects which > > duplicate/overlap with the IPSP MIB modules. > > > > Given that the IPSP MIB modules are still expected to get > > approved (in the future), then I'd say #2 is at least > > undesirable, and probably unacceptable. > > > > yep... that sounds unacceptable. At the other hand, you may > end up having you approved I-D in the RFC-Editor queue for > many years to come waiting for the dependent IPSP MIB module > documents to come through (sorry... even though there > was a message about the status of IPSP MIB modules in August > this year, I have seen no activity since. I keep being > very pessimistic about a reasonable result in this space). > > Maybe one of the ADs (possibly security ADs) can say something > about this issue or about the "dependency". As long as the > docs are listed as normative references, your doc will get > block at the RFC-Editor gates till those normative docs are > ready to become an RFC as well. > > > > So, if you can provide guidance on how to reference the IPSP > > MIB modules in a way which avoids creating normative > > dependencies, then please do. > > > > If I read your section 4.6, then it seems that the > ipsaCredentialTable, the ipsaCredentialSegmentTable and the > ipiaCredMngCRLTable are needed to manage CAs and CRLs. > So that to me seems quite a dependency. Are you guys aware > of how your implementations will/might run without those > tables? Have they currently been implemented in prorpietary ways? > Or have pre-RFC implementations been fielded? > > >From sect 4.6, it seems that your MODULE-COMPLIANCE ought to state > that those tables from IPSP MIB modules have to be supported in > order to let your MIB modules/security-features work, no? > > Bert > > Keith. > > > > > > > I will find out when > > > I read the whole FC-SP MIB document. Sofar I did notice: > > > > > > - 4.8.6. The T11-FC-SP-CERTS-MIB Module > > > > > > This MIB module specifies extensions to IPSP MIBs > > [IPSP-IPSEC-ACTION] > > > and [IPSP-IKE-ACTION] which are specific to Fibre Channel. In > > > particular, it specifies one table, t11FcSpCertsTable, > > with a row per > > > certificate indicating how that certificate is being used, and > > > containing the "name" of the certificate. This "name" > > can be used to > > > obtain information, which is independent of FC-SP, about the > > > certificate from the ipsaCredentialTable (and from the > > > ipsaCredentialSegmentTable if the certificate is longer than 1024 > > > bytes). > > > > > > - In the T11-FC-SP-CERTS-MIB (page 230/231: > > > > > > Since FC-SP leverages a subset of IPsec and > > IKEv2 (see RFC > > > 4595), a subset of the management information defined for > > > the use of certificates with IPsec/IKEv2 is also > > applicable > > > to FC-SP. Thus, this MIB module leverages RFC wwww and > > > RFC xxxx for the management of certificates, CAs > > and CRLs. > > > -- RFC Editor: replace wwww with actual RFC number for > > > -- [IPSP-IPSEC-ACTION], and replace xxxx with actual RFC > > number for > > > -- [IPSP-IKE-ACTION] & remove this note > > > > > > Specifically, the information defined in this MIB module > > > consists of a pointer into the IPsec/IKEv2 MIB modules, > > > plus minimal additional item(s) of information which are > > > considered to be important in a Fibre Channel > > environment. > > > > > > So it does sound normative. So I have a warning: > > > > > > I have been reviewing those 2 IPSP documents a few times > > over the last > > > (mmmm probably) 2-3 or 2-4 years, and I must warn you that > > the cycle > > > times on those documents are EXTREMELY slow. The current revisions > > > are: > > > > > > draft-ietf-ipsp-ikeaction-mib-02.txt > > > draft-ietf-ipsp-ipsecaction-mib-02.txt > > > > > > which showed up as I-D on 10 Nov 2006, and both are still > > in Revised > > > ID needed. Those MIB documents are also pretty complex, and > > so if/when > > > a new revision will eventually show up (if at all), then > > whoever needs > > > to re-review will need a serious block of time to actually do so. > > > My personal experience is pretty bad/sad with those 2 > > documents, and I > > > must admit that I am completely de- or un-motivated at this > > point in > > > time to re-review them a again if/when they do show up. But > > possibly > > > Dan can convince me otherwise at that time. > > > > > > Anyway, I just wanted the authors/editors/wg-chair and WG > > members to > > > be aware of this risky normative dependency. > > > > > > Bert Wijnen > > > > > > > -----Original Message----- > > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > > Sent: Wednesday, October 10, 2007 2:18 AM > > > > To: imss@ietf.org > > > > Cc: dromasca@avaya.com; Black_David@emc.com > > > > Subject: [imss] imss WG Last Call: FC-SP MIB > > > > Importance: High > > > > > > > > This is to announce an imss WG Last Call on the following > > MIB draft: > > > > > > > > MIB for Fibre-Channel Security Protocols (FC-SP) > > > > draft-ietf-imss-fc-fcsp-mib-00.txt > > > > > > > > This WG Last Call will run through 12 midnight Eastern Time on > > > > Friday, October 26, 2007 (your WG chair hopes to deal > > with Last Call > > > > results during the week of October 29th and hopes that > > any revisions > > > > can be completed prior to the November 19th Internet Draft > > > > submission cutoff for the Vancouver meeting). > > > > > > > > Technical comments *must* be sent to the imss mailing list. > > > > Editorial comments may be sent directly to the draft editor (but > > > > please cc: me): > > > > > > > > Keith McCloghrie [kzm@cisco.com] > > > > > > > > In order to try to set a good example, I have completed > > my WG chair > > > > review of the MIB prior to announcing this Last Call. > > > > > > > > I found two technical concerns: > > > > (1) The MIB defines precedence values for traffic selectors > > > > as opposed to implicitly presenting them in order of > > > > precedence. I guess this is ok, but Section 4.7 should > > > > explain why this approach was chosen. > > > > (2) Section 4.9 defines rate control for Authentication > > > > failures on a per-fabric granularity. That strikes > > > > me as overly coarse, and I wonder if per-SA would > > > > be a more appropriate/useful granularity. > > > > > > > > I also found a number of editorial concerns: > > > > > > > > Section 1, 2nd paragraph. Remove the sentence starting > > with "This > > > > latest draft" or insert an instruction to the RFC Editor > > to remove > > > > it before publication as an RFC. > > > > > > > > Section 3.1 - Delete "The" at the start of the first paragraph. > > > > > > > > Should Section 3.5 and subsequent subsections of Section 3 all be > > > > subsections of Section 3.4 Security? > > > > > > > > Section 3.10 - "To provide better scaling, the Switch Connectivity > > > > Objects are not Fabric-wide information such that they are > > > > distributed only to where they are needed." > > > > > > > > "information such that they are" -> information, but are" > > > > > > > > Section 3.10 introduces "Active Zone Set" but does not > > explain what > > > > this term means. > > > > > > > > T11FcSpPolicyNameType - the DESCRIPTION needs to explain > > the concept > > > > of "restricted" - how does a "restricted" entity differ from the > > > > corresponding unrestricted entity? > > > > > > > > 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 > > > > > > > > > > > > > _______________________________________________ > > > 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 Mon Nov 26 20:40:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwpQx-0003l3-6R; Mon, 26 Nov 2007 20:40:19 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IwpQv-0003XP-1Q for imss-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 20:40:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwpQu-0003UW-JA for imss@ietf.org; Mon, 26 Nov 2007 20:40:16 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwpQr-0005L0-8j for imss@ietf.org; Mon, 26 Nov 2007 20:40:16 -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 lAR1e9Vo000035; Mon, 26 Nov 2007 20:40:09 -0500 (EST) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Mon, 26 Nov 2007 20:40:09 -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 lAR1dqqw010253; Mon, 26 Nov 2007 20:40:04 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 20:39:45 -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] imss WG Last Call: FC-SP MIB Date: Mon, 26 Nov 2007 20:39:45 -0500 Message-ID: In-Reply-To: <200711261721.JAA27433@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [imss] imss WG Last Call: FC-SP MIB Thread-index: AcgwUQl06oxBArtvTn2uq6dyRgSd9AARCKiw References: from "WIJNEN, Bert \(Bert\)" at Nov 26, 2007 04:00:47 PM <200711261721.JAA27433@cisco.com> To: , X-OriginalArrivalTime: 27 Nov 2007 01:39:45.0419 (UTC) FILETIME=[6397F5B0:01C83096] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 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: d8921dd2ebcb07edebf7bfaf4808c2ad 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, At this juncture, I favor approach 3: > 3. Decide that the value of the one extra piece of information > (t11FcSpCertUsage) is not important enough for this MIB to have any sort > of dependency, and to decide not to define the T11-FC-SP-CERTS-MIB at > the present time. The extra information classifies a certificate as authentication (entity has private key) vs. trust anchor (used to verify certificates presented by other entities) and indicates which of the certificates is the default. Both of these are generic to certificates (i.e., there's nothing special to FC that requires them), and hence arguably belong in a certificate MIB somewhere as opposed to an FC MIB. In addition, I expect that the PKIX folks will probably have things to say about how to do certificate usage "right" which won't have much resemblance to what's in the MIB ;-). Finally, starting work on trust anchor management is on the PKIX agenda for Vancouver, and hence staying out of that entire area is probably a prudent step towards getting this MIB done in the nearer future. Unless there's objection from anyone else on the mailing list, I think we should just drop the CERTS-MIB. 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 ---------------------------------------------------- > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com]=20 > Sent: Monday, November 26, 2007 12:21 PM > To: bwijnen@alcatel-lucent.com > Cc: Keith McCloghrie; Black, David; imss@ietf.org; dromasca@avaya.com > Subject: Re: [imss] imss WG Last Call: FC-SP MIB >=20 >=20 > Here are three alternatives for what we could do: >=20 > 1. Continue with the "dependency" as-is, but with the additional > note on compliance that you suggest. >=20 > 2. Generalize the "dependency" so that it doesn't actually refer to > [IPSP-IKE-ACTION] or [IPSP-IPSEC-ACTION], but instead says something > like: >=20 > Prior to the definition of the T11-FC-SP-CERTS-MIB, work had started > in the IETF to specify a set of MIBs for managing IPsec/IKEv2. The > work was far enough along for the definition of FC-SP MIBs to > leverage them as prior work, and to define a small extension of > importance in the Fibre Channel environment. However, the approval > process for the IPsec/IKEv2 MIBs was delayed such that the=20 > definition > of FC-SP MIBs caught-up with and was expected to overtake those for > IPsec/IKEv2. In order not to create a dependency, this document > defines only the extension, and it does so in a generic manner so > that the extension can be applied to any MIB for IPsec/IKEv2, either > the completion of the previously-begun work or any alternative which > might begin in the future. >=20 > I think a simple technical change is all that is required to make the > definitions (in T11-FC-SP-CERTS-MIB) generic. Specifcially, I suggest > we change syntax of t11FcSpCertPointer to be an OID, such that it can > point to any table, i.e., not only into the ipsaCredentialTable, but > also into any other MIB's table. >=20 > I think the above would allow the references to be Informational. >=20 > 3. Decide that the value of the one extra piece of information > (t11FcSpCertUsage) is not important enough for this MIB to=20 > have any sort > of dependency, and to decide not to define the T11-FC-SP-CERTS-MIB at > the present time. >=20 > Keith. >=20 > =20 > > W.r.t. > > > > One thing I do see that may need some action is the=20 > fact that this=20 > > > > document has normative dependencies on these 2 documents: > > > >=20 > > > > [IPSP-IKE-ACTION] > > > > Baer, M., Charlet, R., Hardaker, W., Story, R.,=20 > and C. Wang, > > "IPsec > > > > Security Policy IKE Action MIB",=20 > draft-ietf-ipsp-ikeaction-mib- > > > > nn.txt, work-in-progress, 19 October 2006. > > > >=20 > > > > [IPSP-IPSEC-ACTION] > > > > Baer, M., Charlet, R., Hardaker, W., Story, R.,=20 > and C. Wang, > > "IPsec > > > > Security Policy IPsec Action MIB", > > draft-ietf-ipsp-ipsecaction-mib- > > > > nn.txt, work-in-progress, 19 October 2006. > > > >=20 > > > >=20 > > > > However, I do not see that any IMPORT is done for those=20 > 2 IPSP MIB=20 > > > > modules, so maybe the dependency is not really normative? > > >=20 > > > I agree that such a "dependency" is a little risky, because I=20 > > > too submitted some comments on those MIBs. The reason that=20 > > > I'm using quotes around "dependency" is because it is not the=20 > > > definitions in this MIB which depend on any definitions in=20 > > > those MIBs, but rather the explanation of why this MIB has=20 > > > the set of (certificate-related) objects that it does. =20 > > > Without such explanations, the definitions in this MIB would=20 > > > appear incomplete, and it seems to me that making it complete=20 > > > requires either: > > >=20 > > > 1. the reference to the IPSP MIB modules that it currently=20 > > > has, or 2. definition of new MIB objects which=20 > > > duplicate/overlap with the IPSP MIB modules. > > >=20 > > > Given that the IPSP MIB modules are still expected to get=20 > > > approved (in the future), then I'd say #2 is at least=20 > > > undesirable, and probably unacceptable. > > >=20 > >=20 > > yep... that sounds unacceptable. At the other hand, you may > > end up having you approved I-D in the RFC-Editor queue for > > many years to come waiting for the dependent IPSP MIB module > > documents to come through (sorry... even though there > > was a message about the status of IPSP MIB modules in August > > this year, I have seen no activity since. I keep being > > very pessimistic about a reasonable result in this space). > >=20 > > Maybe one of the ADs (possibly security ADs) can say something > > about this issue or about the "dependency". As long as the > > docs are listed as normative references, your doc will get > > block at the RFC-Editor gates till those normative docs are > > ready to become an RFC as well. > >=20 > >=20 > > > So, if you can provide guidance on how to reference the IPSP=20 > > > MIB modules in a way which avoids creating normative=20 > > > dependencies, then please do. > > >=20 > >=20 > > If I read your section 4.6, then it seems that the=20 > > ipsaCredentialTable, the ipsaCredentialSegmentTable and the > > ipiaCredMngCRLTable are needed to manage CAs and CRLs. > > So that to me seems quite a dependency. Are you guys aware > > of how your implementations will/might run without those > > tables? Have they currently been implemented in prorpietary ways? > > Or have pre-RFC implementations been fielded?=20 > >=20 > > >From sect 4.6, it seems that your MODULE-COMPLIANCE ought to state > > that those tables from IPSP MIB modules have to be supported in > > order to let your MIB modules/security-features work, no? > >=20 > > Bert > > > Keith. > > >=20 > > >=20 > > > > I will find out when > > > > I read the whole FC-SP MIB document. Sofar I did notice: > > > >=20 > > > > - 4.8.6. The T11-FC-SP-CERTS-MIB Module > > > >=20 > > > > This MIB module specifies extensions to IPSP MIBs=20 > > > [IPSP-IPSEC-ACTION] > > > > and [IPSP-IKE-ACTION] which are specific to Fibre=20 > Channel. In > > > > particular, it specifies one table, t11FcSpCertsTable,=20 > > > with a row per > > > > certificate indicating how that certificate is being=20 > used, and > > > > containing the "name" of the certificate. This "name"=20 > > > can be used to > > > > obtain information, which is independent of FC-SP, about the > > > > certificate from the ipsaCredentialTable (and from the > > > > ipsaCredentialSegmentTable if the certificate is=20 > longer than 1024 > > > > bytes). > > > >=20 > > > > - In the T11-FC-SP-CERTS-MIB (page 230/231: > > > >=20 > > > > Since FC-SP leverages a subset of IPsec and=20 > > > IKEv2 (see RFC > > > > 4595), a subset of the management=20 > information defined for > > > > the use of certificates with IPsec/IKEv2 is also=20 > > > applicable > > > > to FC-SP. Thus, this MIB module leverages=20 > RFC wwww and > > > > RFC xxxx for the management of certificates, CAs=20 > > > and CRLs. > > > > -- RFC Editor: replace wwww with actual RFC number for > > > > -- [IPSP-IPSEC-ACTION], and replace xxxx with actual RFC=20 > > > number for > > > > -- [IPSP-IKE-ACTION] & remove this note > > > >=20 > > > > Specifically, the information defined in=20 > this MIB module > > > > consists of a pointer into the IPsec/IKEv2=20 > MIB modules, > > > > plus minimal additional item(s) of=20 > information which are > > > > considered to be important in a Fibre Channel=20 > > > environment. > > > >=20 > > > > So it does sound normative. So I have a warning: > > > >=20 > > > > I have been reviewing those 2 IPSP documents a few times=20 > > > over the last=20 > > > > (mmmm probably) 2-3 or 2-4 years, and I must warn you that=20 > > > the cycle=20 > > > > times on those documents are EXTREMELY slow. The=20 > current revisions=20 > > > > are: > > > >=20 > > > > draft-ietf-ipsp-ikeaction-mib-02.txt > > > > draft-ietf-ipsp-ipsecaction-mib-02.txt > > > >=20 > > > > which showed up as I-D on 10 Nov 2006, and both are still=20 > > > in Revised=20 > > > > ID needed. Those MIB documents are also pretty complex, and=20 > > > so if/when=20 > > > > a new revision will eventually show up (if at all), then=20 > > > whoever needs=20 > > > > to re-review will need a serious block of time to=20 > actually do so. > > > > My personal experience is pretty bad/sad with those 2=20 > > > documents, and I=20 > > > > must admit that I am completely de- or un-motivated at this=20 > > > point in=20 > > > > time to re-review them a again if/when they do show up. But=20 > > > possibly=20 > > > > Dan can convince me otherwise at that time. > > > >=20 > > > > Anyway, I just wanted the authors/editors/wg-chair and WG=20 > > > members to=20 > > > > be aware of this risky normative dependency. > > > >=20 > > > > Bert Wijnen > > > >=20 > > > > > -----Original Message----- > > > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > > > Sent: Wednesday, October 10, 2007 2:18 AM > > > > > To: imss@ietf.org > > > > > Cc: dromasca@avaya.com; Black_David@emc.com > > > > > Subject: [imss] imss WG Last Call: FC-SP MIB > > > > > Importance: High > > > > >=20 > > > > > This is to announce an imss WG Last Call on the following=20 > > > MIB draft: > > > > >=20 > > > > > MIB for Fibre-Channel Security Protocols (FC-SP) > > > > > draft-ietf-imss-fc-fcsp-mib-00.txt > > > > >=20 > > > > > This WG Last Call will run through 12 midnight=20 > Eastern Time on=20 > > > > > Friday, October 26, 2007 (your WG chair hopes to deal=20 > > > with Last Call=20 > > > > > results during the week of October 29th and hopes that=20 > > > any revisions=20 > > > > > can be completed prior to the November 19th Internet Draft=20 > > > > > submission cutoff for the Vancouver meeting). > > > > >=20 > > > > > Technical comments *must* be sent to the imss mailing list. > > > > > Editorial comments may be sent directly to the draft=20 > editor (but=20 > > > > > please cc: me): > > > > >=20 > > > > > Keith McCloghrie [kzm@cisco.com] > > > > >=20 > > > > > In order to try to set a good example, I have completed=20 > > > my WG chair=20 > > > > > review of the MIB prior to announcing this Last Call. > > > > >=20 > > > > > I found two technical concerns: > > > > > (1) The MIB defines precedence values for traffic selectors > > > > > as opposed to implicitly presenting them in order of > > > > > precedence. I guess this is ok, but Section 4.7 should > > > > > explain why this approach was chosen. > > > > > (2) Section 4.9 defines rate control for Authentication > > > > > failures on a per-fabric granularity. That strikes > > > > > me as overly coarse, and I wonder if per-SA would > > > > > be a more appropriate/useful granularity. > > > > >=20 > > > > > I also found a number of editorial concerns: > > > > >=20 > > > > > Section 1, 2nd paragraph. Remove the sentence starting=20 > > > with "This=20 > > > > > latest draft" or insert an instruction to the RFC Editor=20 > > > to remove=20 > > > > > it before publication as an RFC. > > > > >=20 > > > > > Section 3.1 - Delete "The" at the start of the first=20 > paragraph. > > > > >=20 > > > > > Should Section 3.5 and subsequent subsections of=20 > Section 3 all be=20 > > > > > subsections of Section 3.4 Security? > > > > >=20 > > > > > Section 3.10 - "To provide better scaling, the Switch=20 > Connectivity > > > > > Objects are not Fabric-wide information such that they are > > > > > distributed only to where they are needed." > > > > >=20 > > > > > "information such that they are" -> information, but are" > > > > >=20 > > > > > Section 3.10 introduces "Active Zone Set" but does not=20 > > > explain what=20 > > > > > this term means. > > > > >=20 > > > > > T11FcSpPolicyNameType - the DESCRIPTION needs to explain=20 > > > the concept=20 > > > > > of "restricted" - how does a "restricted" entity=20 > differ from the=20 > > > > > corresponding unrestricted entity? > > > > >=20 > > > > > 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 > > > > > ---------------------------------------------------- > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > imss mailing list > > > > > imss@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/imss > > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > imss mailing list > > > > imss@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/imss > > > >=20 > > >=20 > >=20 >=20 >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Nov 26 21:01:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwplM-0002i2-0O; Mon, 26 Nov 2007 21:01:24 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IwplK-0002hq-FO for imss-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 21:01:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwplK-0002hi-2y for imss@ietf.org; Mon, 26 Nov 2007 21:01:22 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwplI-00005j-EQ for imss@ietf.org; Mon, 26 Nov 2007 21:01:22 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Nov 2007 18:01:19 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAR21JlH000390; Mon, 26 Nov 2007 18:01:19 -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 lAR21JAx020774; Tue, 27 Nov 2007 02:01:19 GMT Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA16389; Mon, 26 Nov 2007 17:59:36 -0800 (PST) From: Keith McCloghrie Message-Id: <200711270159.RAA16389@cisco.com> Subject: Re: [imss] imss WG Last Call: FC-SP MIB To: Black_David@emc.com Date: Mon, 26 Nov 2007 17:59:36 -0800 (PST) In-Reply-To: from "Black_David@emc.com" at Nov 26, 2007 08:39:45 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=15347; t=1196128879; x=1196992879; c=relaxed/simple; s=sjdkim3002; 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]=20imss=20WG=20Last=20Call=3A=20FC-SP=20MIB |Sender:=20; bh=kJT1V9FLeo8bE6p+kquoYRgqjs7StgJihFCLsp+y1A8=; b=AN8UmsQRVZcJ4IDfl524mJD5prW5K/D03tfrjX71qh2JPrthOvS2nucbLMroTZMcmwd80ASZ GtfToJtQOlY9zdQohbauuD6K2ojN5IJ/nmtCVEy9UZr7Iw4K1jAQ/9Mj; Authentication-Results: sj-dkim-3; header.From=kzm@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: imss@ietf.org, kzm@cisco.com, bwijnen@alcatel-lucent.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 I agree. Bert, that's one less MIB module for you to review, and there will be a number of editorial changes associated with removing T11-FC-SP-CERTS-MIB -- is it worth me making those editorial changes before you continue your review, so that your review will check that I found all the ones in the parts that you haven't yet reviewed ? Keith. > Keith, > > At this juncture, I favor approach 3: > > > 3. Decide that the value of the one extra piece of information > > (t11FcSpCertUsage) is not important enough for this MIB to have any > sort > > of dependency, and to decide not to define the T11-FC-SP-CERTS-MIB at > > the present time. > > The extra information classifies a certificate as authentication > (entity has private key) vs. trust anchor (used to verify certificates > presented by other entities) and indicates which of the certificates > is the default. Both of these are generic to certificates (i.e., > there's nothing special to FC that requires them), and hence > arguably belong in a certificate MIB somewhere as opposed to an FC > MIB. In addition, I expect that the PKIX folks will probably have > things to say about how to do certificate usage "right" which won't > have much resemblance to what's in the MIB ;-). Finally, starting > work on trust anchor management is on the PKIX agenda for Vancouver, > and hence staying out of that entire area is probably a prudent step > towards getting this MIB done in the nearer future. > > Unless there's objection from anyone else on the mailing list, I > think we should just drop the CERTS-MIB. > > 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 > ---------------------------------------------------- > > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > Sent: Monday, November 26, 2007 12:21 PM > > To: bwijnen@alcatel-lucent.com > > Cc: Keith McCloghrie; Black, David; imss@ietf.org; dromasca@avaya.com > > Subject: Re: [imss] imss WG Last Call: FC-SP MIB > > > > > > Here are three alternatives for what we could do: > > > > 1. Continue with the "dependency" as-is, but with the additional > > note on compliance that you suggest. > > > > 2. Generalize the "dependency" so that it doesn't actually refer to > > [IPSP-IKE-ACTION] or [IPSP-IPSEC-ACTION], but instead says something > > like: > > > > Prior to the definition of the T11-FC-SP-CERTS-MIB, work had started > > in the IETF to specify a set of MIBs for managing IPsec/IKEv2. The > > work was far enough along for the definition of FC-SP MIBs to > > leverage them as prior work, and to define a small extension of > > importance in the Fibre Channel environment. However, the approval > > process for the IPsec/IKEv2 MIBs was delayed such that the > > definition > > of FC-SP MIBs caught-up with and was expected to overtake those for > > IPsec/IKEv2. In order not to create a dependency, this document > > defines only the extension, and it does so in a generic manner so > > that the extension can be applied to any MIB for IPsec/IKEv2, either > > the completion of the previously-begun work or any alternative which > > might begin in the future. > > > > I think a simple technical change is all that is required to make the > > definitions (in T11-FC-SP-CERTS-MIB) generic. Specifcially, I suggest > > we change syntax of t11FcSpCertPointer to be an OID, such that it can > > point to any table, i.e., not only into the ipsaCredentialTable, but > > also into any other MIB's table. > > > > I think the above would allow the references to be Informational. > > > > 3. Decide that the value of the one extra piece of information > > (t11FcSpCertUsage) is not important enough for this MIB to > > have any sort > > of dependency, and to decide not to define the T11-FC-SP-CERTS-MIB at > > the present time. > > > > Keith. > > > > > > > W.r.t. > > > > > One thing I do see that may need some action is the > > fact that this > > > > > document has normative dependencies on these 2 documents: > > > > > > > > > > [IPSP-IKE-ACTION] > > > > > Baer, M., Charlet, R., Hardaker, W., Story, R., > > and C. Wang, > > > "IPsec > > > > > Security Policy IKE Action MIB", > > draft-ietf-ipsp-ikeaction-mib- > > > > > nn.txt, work-in-progress, 19 October 2006. > > > > > > > > > > [IPSP-IPSEC-ACTION] > > > > > Baer, M., Charlet, R., Hardaker, W., Story, R., > > and C. Wang, > > > "IPsec > > > > > Security Policy IPsec Action MIB", > > > draft-ietf-ipsp-ipsecaction-mib- > > > > > nn.txt, work-in-progress, 19 October 2006. > > > > > > > > > > > > > > > However, I do not see that any IMPORT is done for those > > 2 IPSP MIB > > > > > modules, so maybe the dependency is not really normative? > > > > > > > > I agree that such a "dependency" is a little risky, because I > > > > too submitted some comments on those MIBs. The reason that > > > > I'm using quotes around "dependency" is because it is not the > > > > definitions in this MIB which depend on any definitions in > > > > those MIBs, but rather the explanation of why this MIB has > > > > the set of (certificate-related) objects that it does. > > > > Without such explanations, the definitions in this MIB would > > > > appear incomplete, and it seems to me that making it complete > > > > requires either: > > > > > > > > 1. the reference to the IPSP MIB modules that it currently > > > > has, or 2. definition of new MIB objects which > > > > duplicate/overlap with the IPSP MIB modules. > > > > > > > > Given that the IPSP MIB modules are still expected to get > > > > approved (in the future), then I'd say #2 is at least > > > > undesirable, and probably unacceptable. > > > > > > > > > > yep... that sounds unacceptable. At the other hand, you may > > > end up having you approved I-D in the RFC-Editor queue for > > > many years to come waiting for the dependent IPSP MIB module > > > documents to come through (sorry... even though there > > > was a message about the status of IPSP MIB modules in August > > > this year, I have seen no activity since. I keep being > > > very pessimistic about a reasonable result in this space). > > > > > > Maybe one of the ADs (possibly security ADs) can say something > > > about this issue or about the "dependency". As long as the > > > docs are listed as normative references, your doc will get > > > block at the RFC-Editor gates till those normative docs are > > > ready to become an RFC as well. > > > > > > > > > > So, if you can provide guidance on how to reference the IPSP > > > > MIB modules in a way which avoids creating normative > > > > dependencies, then please do. > > > > > > > > > > If I read your section 4.6, then it seems that the > > > ipsaCredentialTable, the ipsaCredentialSegmentTable and the > > > ipiaCredMngCRLTable are needed to manage CAs and CRLs. > > > So that to me seems quite a dependency. Are you guys aware > > > of how your implementations will/might run without those > > > tables? Have they currently been implemented in prorpietary ways? > > > Or have pre-RFC implementations been fielded? > > > > > > >From sect 4.6, it seems that your MODULE-COMPLIANCE ought to state > > > that those tables from IPSP MIB modules have to be supported in > > > order to let your MIB modules/security-features work, no? > > > > > > Bert > > > > Keith. > > > > > > > > > > > > > I will find out when > > > > > I read the whole FC-SP MIB document. Sofar I did notice: > > > > > > > > > > - 4.8.6. The T11-FC-SP-CERTS-MIB Module > > > > > > > > > > This MIB module specifies extensions to IPSP MIBs > > > > [IPSP-IPSEC-ACTION] > > > > > and [IPSP-IKE-ACTION] which are specific to Fibre > > Channel. In > > > > > particular, it specifies one table, t11FcSpCertsTable, > > > > with a row per > > > > > certificate indicating how that certificate is being > > used, and > > > > > containing the "name" of the certificate. This "name" > > > > can be used to > > > > > obtain information, which is independent of FC-SP, about the > > > > > certificate from the ipsaCredentialTable (and from the > > > > > ipsaCredentialSegmentTable if the certificate is > > longer than 1024 > > > > > bytes). > > > > > > > > > > - In the T11-FC-SP-CERTS-MIB (page 230/231: > > > > > > > > > > Since FC-SP leverages a subset of IPsec and > > > > IKEv2 (see RFC > > > > > 4595), a subset of the management > > information defined for > > > > > the use of certificates with IPsec/IKEv2 is also > > > > applicable > > > > > to FC-SP. Thus, this MIB module leverages > > RFC wwww and > > > > > RFC xxxx for the management of certificates, CAs > > > > and CRLs. > > > > > -- RFC Editor: replace wwww with actual RFC number for > > > > > -- [IPSP-IPSEC-ACTION], and replace xxxx with actual RFC > > > > number for > > > > > -- [IPSP-IKE-ACTION] & remove this note > > > > > > > > > > Specifically, the information defined in > > this MIB module > > > > > consists of a pointer into the IPsec/IKEv2 > > MIB modules, > > > > > plus minimal additional item(s) of > > information which are > > > > > considered to be important in a Fibre Channel > > > > environment. > > > > > > > > > > So it does sound normative. So I have a warning: > > > > > > > > > > I have been reviewing those 2 IPSP documents a few times > > > > over the last > > > > > (mmmm probably) 2-3 or 2-4 years, and I must warn you that > > > > the cycle > > > > > times on those documents are EXTREMELY slow. The > > current revisions > > > > > are: > > > > > > > > > > draft-ietf-ipsp-ikeaction-mib-02.txt > > > > > draft-ietf-ipsp-ipsecaction-mib-02.txt > > > > > > > > > > which showed up as I-D on 10 Nov 2006, and both are still > > > > in Revised > > > > > ID needed. Those MIB documents are also pretty complex, and > > > > so if/when > > > > > a new revision will eventually show up (if at all), then > > > > whoever needs > > > > > to re-review will need a serious block of time to > > actually do so. > > > > > My personal experience is pretty bad/sad with those 2 > > > > documents, and I > > > > > must admit that I am completely de- or un-motivated at this > > > > point in > > > > > time to re-review them a again if/when they do show up. But > > > > possibly > > > > > Dan can convince me otherwise at that time. > > > > > > > > > > Anyway, I just wanted the authors/editors/wg-chair and WG > > > > members to > > > > > be aware of this risky normative dependency. > > > > > > > > > > Bert Wijnen > > > > > > > > > > > -----Original Message----- > > > > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > > > > Sent: Wednesday, October 10, 2007 2:18 AM > > > > > > To: imss@ietf.org > > > > > > Cc: dromasca@avaya.com; Black_David@emc.com > > > > > > Subject: [imss] imss WG Last Call: FC-SP MIB > > > > > > Importance: High > > > > > > > > > > > > This is to announce an imss WG Last Call on the following > > > > MIB draft: > > > > > > > > > > > > MIB for Fibre-Channel Security Protocols (FC-SP) > > > > > > draft-ietf-imss-fc-fcsp-mib-00.txt > > > > > > > > > > > > This WG Last Call will run through 12 midnight > > Eastern Time on > > > > > > Friday, October 26, 2007 (your WG chair hopes to deal > > > > with Last Call > > > > > > results during the week of October 29th and hopes that > > > > any revisions > > > > > > can be completed prior to the November 19th Internet Draft > > > > > > submission cutoff for the Vancouver meeting). > > > > > > > > > > > > Technical comments *must* be sent to the imss mailing list. > > > > > > Editorial comments may be sent directly to the draft > > editor (but > > > > > > please cc: me): > > > > > > > > > > > > Keith McCloghrie [kzm@cisco.com] > > > > > > > > > > > > In order to try to set a good example, I have completed > > > > my WG chair > > > > > > review of the MIB prior to announcing this Last Call. > > > > > > > > > > > > I found two technical concerns: > > > > > > (1) The MIB defines precedence values for traffic selectors > > > > > > as opposed to implicitly presenting them in order of > > > > > > precedence. I guess this is ok, but Section 4.7 should > > > > > > explain why this approach was chosen. > > > > > > (2) Section 4.9 defines rate control for Authentication > > > > > > failures on a per-fabric granularity. That strikes > > > > > > me as overly coarse, and I wonder if per-SA would > > > > > > be a more appropriate/useful granularity. > > > > > > > > > > > > I also found a number of editorial concerns: > > > > > > > > > > > > Section 1, 2nd paragraph. Remove the sentence starting > > > > with "This > > > > > > latest draft" or insert an instruction to the RFC Editor > > > > to remove > > > > > > it before publication as an RFC. > > > > > > > > > > > > Section 3.1 - Delete "The" at the start of the first > > paragraph. > > > > > > > > > > > > Should Section 3.5 and subsequent subsections of > > Section 3 all be > > > > > > subsections of Section 3.4 Security? > > > > > > > > > > > > Section 3.10 - "To provide better scaling, the Switch > > Connectivity > > > > > > Objects are not Fabric-wide information such that they are > > > > > > distributed only to where they are needed." > > > > > > > > > > > > "information such that they are" -> information, but are" > > > > > > > > > > > > Section 3.10 introduces "Active Zone Set" but does not > > > > explain what > > > > > > this term means. > > > > > > > > > > > > T11FcSpPolicyNameType - the DESCRIPTION needs to explain > > > > the concept > > > > > > of "restricted" - how does a "restricted" entity > > differ from the > > > > > > corresponding unrestricted entity? > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 Nov 27 04:36:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwrL-0006h0-60; Tue, 27 Nov 2007 04:36:03 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IwwrK-0006gs-Bn for imss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 04:36:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwrJ-0006gZ-VI for imss@ietf.org; Tue, 27 Nov 2007 04:36:02 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwwrI-0002sv-NT for imss@ietf.org; Tue, 27 Nov 2007 04:36:01 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lAR9ZnSu019783; Tue, 27 Nov 2007 03:35:50 -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, 27 Nov 2007 03:35:49 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.26]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 10:35:47 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [imss] imss WG Last Call: FC-SP MIB Date: Tue, 27 Nov 2007 10:35:47 +0100 Message-ID: In-Reply-To: <200711261721.JAA27433@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [imss] imss WG Last Call: FC-SP MIB Thread-Index: AcgwURVvISRzbv2fS4iUe/moWbBAGwAgohJw References: from "WIJNEN, Bert \(Bert\)" at Nov 26, 2007 04:00:47 PM <200711261721.JAA27433@cisco.com> From: "WIJNEN, Bert \(Bert\)" To: "Keith McCloghrie" X-OriginalArrivalTime: 27 Nov 2007 09:35:47.0658 (UTC) FILETIME=[E403C2A0:01C830D8] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf 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 Works for me. And if you still need/want to reference those two documents,=20 you can then move them to the informational section. But if=20 references are not absolutely needed, you might be better=20 off to leave them out in this case. Bert Wijnen =20 > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com]=20 > Sent: Monday, November 26, 2007 6:21 PM > To: WIJNEN, Bert (Bert) > Cc: Keith McCloghrie; Black_David@emc.com; imss@ietf.org;=20 > dromasca@avaya.com > Subject: Re: [imss] imss WG Last Call: FC-SP MIB >=20 >=20 > Here are three alternatives for what we could do: >=20 > 1. Continue with the "dependency" as-is, but with the=20 > additional note on compliance that you suggest. >=20 > 2. Generalize the "dependency" so that it doesn't actually=20 > refer to [IPSP-IKE-ACTION] or [IPSP-IPSEC-ACTION], but=20 > instead says something > like: >=20 > Prior to the definition of the T11-FC-SP-CERTS-MIB, work had started > in the IETF to specify a set of MIBs for managing IPsec/IKEv2. The > work was far enough along for the definition of FC-SP MIBs to > leverage them as prior work, and to define a small extension of > importance in the Fibre Channel environment. However, the approval > process for the IPsec/IKEv2 MIBs was delayed such that the=20 > definition > of FC-SP MIBs caught-up with and was expected to overtake those for > IPsec/IKEv2. In order not to create a dependency, this document > defines only the extension, and it does so in a generic manner so > that the extension can be applied to any MIB for IPsec/IKEv2, either > the completion of the previously-begun work or any alternative which > might begin in the future. >=20 > I think a simple technical change is all that is required to=20 > make the definitions (in T11-FC-SP-CERTS-MIB) generic. =20 > Specifcially, I suggest we change syntax of=20 > t11FcSpCertPointer to be an OID, such that it can point to=20 > any table, i.e., not only into the ipsaCredentialTable, but=20 > also into any other MIB's table. >=20 > I think the above would allow the references to be Informational. >=20 > 3. Decide that the value of the one extra piece of information > (t11FcSpCertUsage) is not important enough for this MIB to=20 > have any sort of dependency, and to decide not to define the=20 > T11-FC-SP-CERTS-MIB at the present time. >=20 > Keith. >=20 > =20 > > W.r.t. > > > > One thing I do see that may need some action is the=20 > fact that this=20 > > > > document has normative dependencies on these 2 documents: > > > >=20 > > > > [IPSP-IKE-ACTION] > > > > Baer, M., Charlet, R., Hardaker, W., Story, R.,=20 > and C. Wang, > > "IPsec > > > > Security Policy IKE Action MIB",=20 > draft-ietf-ipsp-ikeaction-mib- > > > > nn.txt, work-in-progress, 19 October 2006. > > > >=20 > > > > [IPSP-IPSEC-ACTION] > > > > Baer, M., Charlet, R., Hardaker, W., Story, R.,=20 > and C. Wang, > > "IPsec > > > > Security Policy IPsec Action MIB", > > draft-ietf-ipsp-ipsecaction-mib- > > > > nn.txt, work-in-progress, 19 October 2006. > > > >=20 > > > >=20 > > > > However, I do not see that any IMPORT is done for those=20 > 2 IPSP MIB=20 > > > > modules, so maybe the dependency is not really normative? > > >=20 > > > I agree that such a "dependency" is a little risky, because I too=20 > > > submitted some comments on those MIBs. The reason that I'm using=20 > > > quotes around "dependency" is because it is not the=20 > definitions in=20 > > > this MIB which depend on any definitions in those MIBs,=20 > but rather=20 > > > the explanation of why this MIB has the set of=20 > (certificate-related)=20 > > > objects that it does. > > > Without such explanations, the definitions in this MIB=20 > would appear=20 > > > incomplete, and it seems to me that making it complete requires=20 > > > either: > > >=20 > > > 1. the reference to the IPSP MIB modules that it=20 > currently has, or=20 > > > 2. definition of new MIB objects which duplicate/overlap with the=20 > > > IPSP MIB modules. > > >=20 > > > Given that the IPSP MIB modules are still expected to get=20 > approved=20 > > > (in the future), then I'd say #2 is at least undesirable, and=20 > > > probably unacceptable. > > >=20 > >=20 > > yep... that sounds unacceptable. At the other hand, you may end up=20 > > having you approved I-D in the RFC-Editor queue for many=20 > years to come=20 > > waiting for the dependent IPSP MIB module documents to come through=20 > > (sorry... even though there was a message about the status=20 > of IPSP MIB=20 > > modules in August this year, I have seen no activity since. I keep=20 > > being very pessimistic about a reasonable result in this space). > >=20 > > Maybe one of the ADs (possibly security ADs) can say=20 > something about=20 > > this issue or about the "dependency". As long as the docs=20 > are listed=20 > > as normative references, your doc will get block at the RFC-Editor=20 > > gates till those normative docs are ready to become an RFC as well. > >=20 > >=20 > > > So, if you can provide guidance on how to reference the IPSP MIB=20 > > > modules in a way which avoids creating normative=20 > dependencies, then=20 > > > please do. > > >=20 > >=20 > > If I read your section 4.6, then it seems that the=20 > > ipsaCredentialTable, the ipsaCredentialSegmentTable and the=20 > > ipiaCredMngCRLTable are needed to manage CAs and CRLs. > > So that to me seems quite a dependency. Are you guys aware=20 > of how your=20 > > implementations will/might run without those tables? Have they=20 > > currently been implemented in prorpietary ways? > > Or have pre-RFC implementations been fielded?=20 > >=20 > > >From sect 4.6, it seems that your MODULE-COMPLIANCE ought to state > > that those tables from IPSP MIB modules have to be=20 > supported in order=20 > > to let your MIB modules/security-features work, no? > >=20 > > Bert > > > Keith. > > >=20 > > >=20 > > > > I will find out when > > > > I read the whole FC-SP MIB document. Sofar I did notice: > > > >=20 > > > > - 4.8.6. The T11-FC-SP-CERTS-MIB Module > > > >=20 > > > > This MIB module specifies extensions to IPSP MIBs > > > [IPSP-IPSEC-ACTION] > > > > and [IPSP-IKE-ACTION] which are specific to Fibre=20 > Channel. In > > > > particular, it specifies one table, t11FcSpCertsTable, > > > with a row per > > > > certificate indicating how that certificate is being=20 > used, and > > > > containing the "name" of the certificate. This "name"=20 > > > can be used to > > > > obtain information, which is independent of FC-SP, about the > > > > certificate from the ipsaCredentialTable (and from the > > > > ipsaCredentialSegmentTable if the certificate is=20 > longer than 1024 > > > > bytes). > > > >=20 > > > > - In the T11-FC-SP-CERTS-MIB (page 230/231: > > > >=20 > > > > Since FC-SP leverages a subset of IPsec and > > > IKEv2 (see RFC > > > > 4595), a subset of the management=20 > information defined for > > > > the use of certificates with IPsec/IKEv2 is also > > > applicable > > > > to FC-SP. Thus, this MIB module leverages=20 > RFC wwww and > > > > RFC xxxx for the management of certificates, CAs > > > and CRLs. > > > > -- RFC Editor: replace wwww with actual RFC number for > > > > -- [IPSP-IPSEC-ACTION], and replace xxxx with actual RFC > > > number for > > > > -- [IPSP-IKE-ACTION] & remove this note > > > >=20 > > > > Specifically, the information defined in=20 > this MIB module > > > > consists of a pointer into the IPsec/IKEv2=20 > MIB modules, > > > > plus minimal additional item(s) of=20 > information which are > > > > considered to be important in a Fibre Channel > > > environment. > > > >=20 > > > > So it does sound normative. So I have a warning: > > > >=20 > > > > I have been reviewing those 2 IPSP documents a few times > > > over the last > > > > (mmmm probably) 2-3 or 2-4 years, and I must warn you that > > > the cycle > > > > times on those documents are EXTREMELY slow. The=20 > current revisions > > > > are: > > > >=20 > > > > draft-ietf-ipsp-ikeaction-mib-02.txt > > > > draft-ietf-ipsp-ipsecaction-mib-02.txt > > > >=20 > > > > which showed up as I-D on 10 Nov 2006, and both are still > > > in Revised > > > > ID needed. Those MIB documents are also pretty complex, and > > > so if/when > > > > a new revision will eventually show up (if at all), then > > > whoever needs > > > > to re-review will need a serious block of time to=20 > actually do so. > > > > My personal experience is pretty bad/sad with those 2 > > > documents, and I > > > > must admit that I am completely de- or un-motivated at this > > > point in > > > > time to re-review them a again if/when they do show up. But > > > possibly > > > > Dan can convince me otherwise at that time. > > > >=20 > > > > Anyway, I just wanted the authors/editors/wg-chair and WG > > > members to > > > > be aware of this risky normative dependency. > > > >=20 > > > > Bert Wijnen > > > >=20 > > > > > -----Original Message----- > > > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > > > Sent: Wednesday, October 10, 2007 2:18 AM > > > > > To: imss@ietf.org > > > > > Cc: dromasca@avaya.com; Black_David@emc.com > > > > > Subject: [imss] imss WG Last Call: FC-SP MIB > > > > > Importance: High > > > > >=20 > > > > > This is to announce an imss WG Last Call on the following > > > MIB draft: > > > > >=20 > > > > > MIB for Fibre-Channel Security Protocols (FC-SP) > > > > > draft-ietf-imss-fc-fcsp-mib-00.txt > > > > >=20 > > > > > This WG Last Call will run through 12 midnight=20 > Eastern Time on=20 > > > > > Friday, October 26, 2007 (your WG chair hopes to deal > > > with Last Call > > > > > results during the week of October 29th and hopes that > > > any revisions > > > > > can be completed prior to the November 19th Internet Draft=20 > > > > > submission cutoff for the Vancouver meeting). > > > > >=20 > > > > > Technical comments *must* be sent to the imss mailing list. > > > > > Editorial comments may be sent directly to the draft=20 > editor (but=20 > > > > > please cc: me): > > > > >=20 > > > > > Keith McCloghrie [kzm@cisco.com] > > > > >=20 > > > > > In order to try to set a good example, I have completed > > > my WG chair > > > > > review of the MIB prior to announcing this Last Call. > > > > >=20 > > > > > I found two technical concerns: > > > > > (1) The MIB defines precedence values for traffic selectors > > > > > as opposed to implicitly presenting them in order of > > > > > precedence. I guess this is ok, but Section 4.7 should > > > > > explain why this approach was chosen. > > > > > (2) Section 4.9 defines rate control for Authentication > > > > > failures on a per-fabric granularity. That strikes > > > > > me as overly coarse, and I wonder if per-SA would > > > > > be a more appropriate/useful granularity. > > > > >=20 > > > > > I also found a number of editorial concerns: > > > > >=20 > > > > > Section 1, 2nd paragraph. Remove the sentence starting > > > with "This > > > > > latest draft" or insert an instruction to the RFC Editor > > > to remove > > > > > it before publication as an RFC. > > > > >=20 > > > > > Section 3.1 - Delete "The" at the start of the first=20 > paragraph. > > > > >=20 > > > > > Should Section 3.5 and subsequent subsections of=20 > Section 3 all=20 > > > > > be subsections of Section 3.4 Security? > > > > >=20 > > > > > Section 3.10 - "To provide better scaling, the Switch=20 > Connectivity > > > > > Objects are not Fabric-wide information such that they are > > > > > distributed only to where they are needed." > > > > >=20 > > > > > "information such that they are" -> information, but are" > > > > >=20 > > > > > Section 3.10 introduces "Active Zone Set" but does not > > > explain what > > > > > this term means. > > > > >=20 > > > > > T11FcSpPolicyNameType - the DESCRIPTION needs to explain > > > the concept > > > > > of "restricted" - how does a "restricted" entity=20 > differ from the=20 > > > > > corresponding unrestricted entity? > > > > >=20 > > > > > Thanks, > > > > > --David > > > > > ---------------------------------------------------- > > > > > David L. Black, Senior Technologist EMC Corporation,=20 > 176 South=20 > > > > > St., Hopkinton, MA 01748 > > > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > > > ---------------------------------------------------- > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > imss mailing list > > > > > imss@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/imss > > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > imss mailing list > > > > imss@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/imss > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Tue Nov 27 04:36:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwrP-0006ie-AE; Tue, 27 Nov 2007 04:36:07 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IwwrO-0006iS-EU for imss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 04:36:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwrO-0006iK-4p for imss@ietf.org; Tue, 27 Nov 2007 04:36:06 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwwrJ-0008PG-Il for imss@ietf.org; Tue, 27 Nov 2007 04:36:06 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lAR9ZotG019805; Tue, 27 Nov 2007 03:35:51 -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, 27 Nov 2007 03:35:50 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.26]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 10:35:48 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [imss] imss WG Last Call: FC-SP MIB Date: Tue, 27 Nov 2007 10:35:47 +0100 Message-ID: In-Reply-To: <200711270159.RAA16389@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [imss] imss WG Last Call: FC-SP MIB Thread-Index: AcgwmWl8BSHfdSkaQveGWQ8g41vdAgAOzOsQ References: from "Black_David@emc.com" at Nov 26, 2007 08:39:45 PM <200711270159.RAA16389@cisco.com> From: "WIJNEN, Bert \(Bert\)" To: "Keith McCloghrie" , X-OriginalArrivalTime: 27 Nov 2007 09:35:48.0048 (UTC) FILETIME=[E43F4500:01C830D8] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d 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 Sure. Pls go ahead and make the changes (I am used for you doing that pretty quick normally). Bert Wijnen =20 > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com]=20 > Sent: Tuesday, November 27, 2007 3:00 AM > To: Black_David@emc.com > Cc: kzm@cisco.com; WIJNEN, Bert (Bert); imss@ietf.org;=20 > dromasca@avaya.com > Subject: Re: [imss] imss WG Last Call: FC-SP MIB >=20 > I agree. >=20 > Bert, that's one less MIB module for you to review, and there=20 > will be a number of editorial changes associated with=20 > removing T11-FC-SP-CERTS-MIB > -- is it worth me making those editorial changes before you=20 > continue your review, so that your review will check that I=20 > found all the ones in the parts that you haven't yet reviewed ? >=20 > Keith. > =20 > > Keith, > >=20 > > At this juncture, I favor approach 3: > >=20 > > > 3. Decide that the value of the one extra piece of information > > > (t11FcSpCertUsage) is not important enough for this MIB=20 > to have any > > sort > > > of dependency, and to decide not to define the=20 > T11-FC-SP-CERTS-MIB=20 > > > at the present time. > >=20 > > The extra information classifies a certificate as authentication=20 > > (entity has private key) vs. trust anchor (used to verify=20 > certificates=20 > > presented by other entities) and indicates which of the=20 > certificates=20 > > is the default. Both of these are generic to certificates (i.e.,=20 > > there's nothing special to FC that requires them), and=20 > hence arguably=20 > > belong in a certificate MIB somewhere as opposed to an FC MIB. In=20 > > addition, I expect that the PKIX folks will probably have things to=20 > > say about how to do certificate usage "right" which won't have much=20 > > resemblance to what's in the MIB ;-). Finally, starting=20 > work on trust=20 > > anchor management is on the PKIX agenda for Vancouver, and hence=20 > > staying out of that entire area is probably a prudent step towards=20 > > getting this MIB done in the nearer future. > >=20 > > Unless there's objection from anyone else on the mailing=20 > list, I think=20 > > we should just drop the CERTS-MIB. > >=20 > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer EMC Corporation, 176=20 > South St.,=20 > > Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > >=20 > > > -----Original Message----- > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > Sent: Monday, November 26, 2007 12:21 PM > > > To: bwijnen@alcatel-lucent.com > > > Cc: Keith McCloghrie; Black, David; imss@ietf.org;=20 > > > dromasca@avaya.com > > > Subject: Re: [imss] imss WG Last Call: FC-SP MIB > > >=20 > > >=20 > > > Here are three alternatives for what we could do: > > >=20 > > > 1. Continue with the "dependency" as-is, but with the additional=20 > > > note on compliance that you suggest. > > >=20 > > > 2. Generalize the "dependency" so that it doesn't=20 > actually refer to=20 > > > [IPSP-IKE-ACTION] or [IPSP-IPSEC-ACTION], but instead=20 > says something > > > like: > > >=20 > > > Prior to the definition of the T11-FC-SP-CERTS-MIB,=20 > work had started > > > in the IETF to specify a set of MIBs for managing=20 > IPsec/IKEv2. The > > > work was far enough along for the definition of FC-SP MIBs to > > > leverage them as prior work, and to define a small extension of > > > importance in the Fibre Channel environment. However,=20 > the approval > > > process for the IPsec/IKEv2 MIBs was delayed such that the=20 > > > definition > > > of FC-SP MIBs caught-up with and was expected to=20 > overtake those for > > > IPsec/IKEv2. In order not to create a dependency, this document > > > defines only the extension, and it does so in a generic=20 > manner so > > > that the extension can be applied to any MIB for=20 > IPsec/IKEv2, either > > > the completion of the previously-begun work or any=20 > alternative which > > > might begin in the future. > > >=20 > > > I think a simple technical change is all that is required to make=20 > > > the definitions (in T11-FC-SP-CERTS-MIB) generic. =20 > Specifcially, I=20 > > > suggest we change syntax of t11FcSpCertPointer to be an OID, such=20 > > > that it can point to any table, i.e., not only into the=20 > > > ipsaCredentialTable, but also into any other MIB's table. > > >=20 > > > I think the above would allow the references to be Informational. > > >=20 > > > 3. Decide that the value of the one extra piece of information > > > (t11FcSpCertUsage) is not important enough for this MIB=20 > to have any=20 > > > sort of dependency, and to decide not to define the=20 > > > T11-FC-SP-CERTS-MIB at the present time. > > >=20 > > > Keith. > > >=20 > > > =20 > > > > W.r.t. > > > > > > One thing I do see that may need some action is the > > > fact that this > > > > > > document has normative dependencies on these 2 documents: > > > > > >=20 > > > > > > [IPSP-IKE-ACTION] > > > > > > Baer, M., Charlet, R., Hardaker, W., Story, R., > > > and C. Wang, > > > > "IPsec > > > > > > Security Policy IKE Action MIB", > > > draft-ietf-ipsp-ikeaction-mib- > > > > > > nn.txt, work-in-progress, 19 October 2006. > > > > > >=20 > > > > > > [IPSP-IPSEC-ACTION] > > > > > > Baer, M., Charlet, R., Hardaker, W., Story, R., > > > and C. Wang, > > > > "IPsec > > > > > > Security Policy IPsec Action MIB", > > > > draft-ietf-ipsp-ipsecaction-mib- > > > > > > nn.txt, work-in-progress, 19 October 2006. > > > > > >=20 > > > > > >=20 > > > > > > However, I do not see that any IMPORT is done for those > > > 2 IPSP MIB > > > > > > modules, so maybe the dependency is not really normative? > > > > >=20 > > > > > I agree that such a "dependency" is a little risky, because I=20 > > > > > too submitted some comments on those MIBs. The=20 > reason that I'm=20 > > > > > using quotes around "dependency" is because it is not the=20 > > > > > definitions in this MIB which depend on any=20 > definitions in those=20 > > > > > MIBs, but rather the explanation of why this MIB has=20 > the set of=20 > > > > > (certificate-related) objects that it does. > > > > > Without such explanations, the definitions in this MIB would=20 > > > > > appear incomplete, and it seems to me that making it complete=20 > > > > > requires either: > > > > >=20 > > > > > 1. the reference to the IPSP MIB modules that it=20 > currently has,=20 > > > > > or 2. definition of new MIB objects which=20 > duplicate/overlap with=20 > > > > > the IPSP MIB modules. > > > > >=20 > > > > > Given that the IPSP MIB modules are still expected to get=20 > > > > > approved (in the future), then I'd say #2 is at least=20 > > > > > undesirable, and probably unacceptable. > > > > >=20 > > > >=20 > > > > yep... that sounds unacceptable. At the other hand, you=20 > may end up=20 > > > > having you approved I-D in the RFC-Editor queue for=20 > many years to=20 > > > > come waiting for the dependent IPSP MIB module=20 > documents to come=20 > > > > through (sorry... even though there was a message about=20 > the status=20 > > > > of IPSP MIB modules in August this year, I have seen no=20 > activity=20 > > > > since. I keep being very pessimistic about a reasonable=20 > result in=20 > > > > this space). > > > >=20 > > > > Maybe one of the ADs (possibly security ADs) can say something=20 > > > > about this issue or about the "dependency". As long as the docs=20 > > > > are listed as normative references, your doc will get=20 > block at the=20 > > > > RFC-Editor gates till those normative docs are ready to=20 > become an=20 > > > > RFC as well. > > > >=20 > > > >=20 > > > > > So, if you can provide guidance on how to reference=20 > the IPSP MIB=20 > > > > > modules in a way which avoids creating normative=20 > dependencies,=20 > > > > > then please do. > > > > >=20 > > > >=20 > > > > If I read your section 4.6, then it seems that the=20 > > > > ipsaCredentialTable, the ipsaCredentialSegmentTable and the=20 > > > > ipiaCredMngCRLTable are needed to manage CAs and CRLs. > > > > So that to me seems quite a dependency. Are you guys=20 > aware of how=20 > > > > your implementations will/might run without those tables? Have=20 > > > > they currently been implemented in prorpietary ways? > > > > Or have pre-RFC implementations been fielded?=20 > > > >=20 > > > > >From sect 4.6, it seems that your MODULE-COMPLIANCE ought to=20 > > > > >state > > > > that those tables from IPSP MIB modules have to be supported in=20 > > > > order to let your MIB modules/security-features work, no? > > > >=20 > > > > Bert > > > > > Keith. > > > > >=20 > > > > >=20 > > > > > > I will find out when > > > > > > I read the whole FC-SP MIB document. Sofar I did notice: > > > > > >=20 > > > > > > - 4.8.6. The T11-FC-SP-CERTS-MIB Module > > > > > >=20 > > > > > > This MIB module specifies extensions to IPSP MIBs > > > > > [IPSP-IPSEC-ACTION] > > > > > > and [IPSP-IKE-ACTION] which are specific to Fibre > > > Channel. In > > > > > > particular, it specifies one table, t11FcSpCertsTable, > > > > > with a row per > > > > > > certificate indicating how that certificate is being > > > used, and > > > > > > containing the "name" of the certificate. This "name"=20 > > > > > can be used to > > > > > > obtain information, which is independent of=20 > FC-SP, about the > > > > > > certificate from the ipsaCredentialTable (and from the > > > > > > ipsaCredentialSegmentTable if the certificate is > > > longer than 1024 > > > > > > bytes). > > > > > >=20 > > > > > > - In the T11-FC-SP-CERTS-MIB (page 230/231: > > > > > >=20 > > > > > > Since FC-SP leverages a subset of IPsec and > > > > > IKEv2 (see RFC > > > > > > 4595), a subset of the management > > > information defined for > > > > > > the use of certificates with IPsec/IKEv2 is also > > > > > applicable > > > > > > to FC-SP. Thus, this MIB module leverages > > > RFC wwww and > > > > > > RFC xxxx for the management of certificates, CAs > > > > > and CRLs. > > > > > > -- RFC Editor: replace wwww with actual RFC number for > > > > > > -- [IPSP-IPSEC-ACTION], and replace xxxx with actual RFC > > > > > number for > > > > > > -- [IPSP-IKE-ACTION] & remove this note > > > > > >=20 > > > > > > Specifically, the information defined in > > > this MIB module > > > > > > consists of a pointer into the IPsec/IKEv2 > > > MIB modules, > > > > > > plus minimal additional item(s) of > > > information which are > > > > > > considered to be important in a Fibre Channel > > > > > environment. > > > > > >=20 > > > > > > So it does sound normative. So I have a warning: > > > > > >=20 > > > > > > I have been reviewing those 2 IPSP documents a few times > > > > > over the last > > > > > > (mmmm probably) 2-3 or 2-4 years, and I must warn you that > > > > > the cycle > > > > > > times on those documents are EXTREMELY slow. The > > > current revisions > > > > > > are: > > > > > >=20 > > > > > > draft-ietf-ipsp-ikeaction-mib-02.txt > > > > > > draft-ietf-ipsp-ipsecaction-mib-02.txt > > > > > >=20 > > > > > > which showed up as I-D on 10 Nov 2006, and both are still > > > > > in Revised > > > > > > ID needed. Those MIB documents are also pretty complex, and > > > > > so if/when > > > > > > a new revision will eventually show up (if at all), then > > > > > whoever needs > > > > > > to re-review will need a serious block of time to > > > actually do so. > > > > > > My personal experience is pretty bad/sad with those 2 > > > > > documents, and I > > > > > > must admit that I am completely de- or un-motivated at this > > > > > point in > > > > > > time to re-review them a again if/when they do show up. But > > > > > possibly > > > > > > Dan can convince me otherwise at that time. > > > > > >=20 > > > > > > Anyway, I just wanted the authors/editors/wg-chair and WG > > > > > members to > > > > > > be aware of this risky normative dependency. > > > > > >=20 > > > > > > Bert Wijnen > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > > > > > Sent: Wednesday, October 10, 2007 2:18 AM > > > > > > > To: imss@ietf.org > > > > > > > Cc: dromasca@avaya.com; Black_David@emc.com > > > > > > > Subject: [imss] imss WG Last Call: FC-SP MIB > > > > > > > Importance: High > > > > > > >=20 > > > > > > > This is to announce an imss WG Last Call on the following > > > > > MIB draft: > > > > > > >=20 > > > > > > > MIB for Fibre-Channel Security=20 > Protocols (FC-SP) > > > > > > > draft-ietf-imss-fc-fcsp-mib-00.txt > > > > > > >=20 > > > > > > > This WG Last Call will run through 12 midnight > > > Eastern Time on > > > > > > > Friday, October 26, 2007 (your WG chair hopes to deal > > > > > with Last Call > > > > > > > results during the week of October 29th and hopes that > > > > > any revisions > > > > > > > can be completed prior to the November 19th=20 > Internet Draft=20 > > > > > > > submission cutoff for the Vancouver meeting). > > > > > > >=20 > > > > > > > Technical comments *must* be sent to the imss=20 > mailing list. > > > > > > > Editorial comments may be sent directly to the draft > > > editor (but > > > > > > > please cc: me): > > > > > > >=20 > > > > > > > Keith McCloghrie [kzm@cisco.com] > > > > > > >=20 > > > > > > > In order to try to set a good example, I have completed > > > > > my WG chair > > > > > > > review of the MIB prior to announcing this Last Call. > > > > > > >=20 > > > > > > > I found two technical concerns: > > > > > > > (1) The MIB defines precedence values for traffic=20 > selectors > > > > > > > as opposed to implicitly presenting them in order of > > > > > > > precedence. I guess this is ok, but Section 4.7 should > > > > > > > explain why this approach was chosen. > > > > > > > (2) Section 4.9 defines rate control for Authentication > > > > > > > failures on a per-fabric granularity. That strikes > > > > > > > me as overly coarse, and I wonder if per-SA would > > > > > > > be a more appropriate/useful granularity. > > > > > > >=20 > > > > > > > I also found a number of editorial concerns: > > > > > > >=20 > > > > > > > Section 1, 2nd paragraph. Remove the sentence starting > > > > > with "This > > > > > > > latest draft" or insert an instruction to the RFC Editor > > > > > to remove > > > > > > > it before publication as an RFC. > > > > > > >=20 > > > > > > > Section 3.1 - Delete "The" at the start of the first > > > paragraph. > > > > > > >=20 > > > > > > > Should Section 3.5 and subsequent subsections of > > > Section 3 all be > > > > > > > subsections of Section 3.4 Security? > > > > > > >=20 > > > > > > > Section 3.10 - "To provide better scaling, the Switch > > > Connectivity > > > > > > > Objects are not Fabric-wide information such=20 > that they are > > > > > > > distributed only to where they are needed." > > > > > > >=20 > > > > > > > "information such that they are" -> information, but are" > > > > > > >=20 > > > > > > > Section 3.10 introduces "Active Zone Set" but does not > > > > > explain what > > > > > > > this term means. > > > > > > >=20 > > > > > > > T11FcSpPolicyNameType - the DESCRIPTION needs to explain > > > > > the concept > > > > > > > of "restricted" - how does a "restricted" entity > > > differ from the > > > > > > > corresponding unrestricted entity? > > > > > > >=20 > > > > > > > Thanks, > > > > > > > --David > > > > > > > ---------------------------------------------------- > > > > > > > David L. Black, Senior Technologist EMC Corporation, 176=20 > > > > > > > South St., Hopkinton, MA 01748 > > > > > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > > > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > > > > > ---------------------------------------------------- > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > imss mailing list > > > > > > > imss@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/imss > > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > imss mailing list > > > > > > imss@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/imss > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Wed Nov 28 13:35:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxRlE-0001bn-Rg; Wed, 28 Nov 2007 13:35:48 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IxRlD-0001bV-4w for imss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 13:35:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxRlC-0001bN-RF for imss@ietf.org; Wed, 28 Nov 2007 13:35:46 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxRlA-0000KX-Pm for imss@ietf.org; Wed, 28 Nov 2007 13:35:46 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 28 Nov 2007 10:35:44 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lASIZi24021593; Wed, 28 Nov 2007 10:35:44 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lASIZi75004658; Wed, 28 Nov 2007 18:35:44 GMT Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA14355; Wed, 28 Nov 2007 10:34:00 -0800 (PST) From: Keith McCloghrie Message-Id: <200711281834.KAA14355@cisco.com> Subject: Re: [imss] imss WG Last Call: FC-SP MIB To: bwijnen@alcatel-lucent.com Date: Wed, 28 Nov 2007 10:34:00 -0800 (PST) In-Reply-To: from "WIJNEN, Bert \(Bert\)" at Nov 27, 2007 10:35:47 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=18171; t=1196274944; x=1197138944; 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]=20imss=20WG=20Last=20Call=3A=20FC-SP=20MIB |Sender:=20; bh=y/MovaftuBlttIZsCcizZeVcImluQYZ9Oo0gnPBO7/0=; b=hVj1YNiD/UovdKlTOwuWVQLjk9DmzA3blei7sbGPJNXd2ufRn65MRQPkObHnzW5Q+8Pvmgk2 3kVHOWBKTs+6uwFIIVzIsP8jVeTiMTpwmi83jv+bwCvqpbHdprAPPcnK; 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: 17589c7043b24a47064a4b7516f59671 Cc: imss@ietf.org, dromasca@avaya.com, Keith McCloghrie , Black_David@emc.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 Bert, There's an updated version at: ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-fcsp-mib-01.txt I included (see the Change Log) updates based on several of the emails in which you have already sent comments. (I'll reply to those emails in another message after this one, re: chnages that I haven't made.) I can't submit it as an updated I-D because new submissions are suspended until after (the beginning? of) the IETF next week. If and when there are more changes that need to be made before the submission, the submitted version will be different to this version. Thus, on page 1, I list the filename as: "(preliminary) draft-ietf-imss-fc-fcsp-mib-01.txt" Keith. > Sure. Pls go ahead and make the changes (I am used for > you doing that pretty quick normally). > > Bert Wijnen > > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > Sent: Tuesday, November 27, 2007 3:00 AM > > To: Black_David@emc.com > > Cc: kzm@cisco.com; WIJNEN, Bert (Bert); imss@ietf.org; > > dromasca@avaya.com > > Subject: Re: [imss] imss WG Last Call: FC-SP MIB > > > > I agree. > > > > Bert, that's one less MIB module for you to review, and there > > will be a number of editorial changes associated with > > removing T11-FC-SP-CERTS-MIB > > -- is it worth me making those editorial changes before you > > continue your review, so that your review will check that I > > found all the ones in the parts that you haven't yet reviewed ? > > > > Keith. > > > > > Keith, > > > > > > At this juncture, I favor approach 3: > > > > > > > 3. Decide that the value of the one extra piece of information > > > > (t11FcSpCertUsage) is not important enough for this MIB > > to have any > > > sort > > > > of dependency, and to decide not to define the > > T11-FC-SP-CERTS-MIB > > > > at the present time. > > > > > > The extra information classifies a certificate as authentication > > > (entity has private key) vs. trust anchor (used to verify > > certificates > > > presented by other entities) and indicates which of the > > certificates > > > is the default. Both of these are generic to certificates (i.e., > > > there's nothing special to FC that requires them), and > > hence arguably > > > belong in a certificate MIB somewhere as opposed to an FC MIB. In > > > addition, I expect that the PKIX folks will probably have things to > > > say about how to do certificate usage "right" which won't have much > > > resemblance to what's in the MIB ;-). Finally, starting > > work on trust > > > anchor management is on the PKIX agenda for Vancouver, and hence > > > staying out of that entire area is probably a prudent step towards > > > getting this MIB done in the nearer future. > > > > > > Unless there's objection from anyone else on the mailing > > list, I think > > > we should just drop the CERTS-MIB. > > > > > > 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 > > > ---------------------------------------------------- > > > > > > > -----Original Message----- > > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > > Sent: Monday, November 26, 2007 12:21 PM > > > > To: bwijnen@alcatel-lucent.com > > > > Cc: Keith McCloghrie; Black, David; imss@ietf.org; > > > > dromasca@avaya.com > > > > Subject: Re: [imss] imss WG Last Call: FC-SP MIB > > > > > > > > > > > > Here are three alternatives for what we could do: > > > > > > > > 1. Continue with the "dependency" as-is, but with the additional > > > > note on compliance that you suggest. > > > > > > > > 2. Generalize the "dependency" so that it doesn't > > actually refer to > > > > [IPSP-IKE-ACTION] or [IPSP-IPSEC-ACTION], but instead > > says something > > > > like: > > > > > > > > Prior to the definition of the T11-FC-SP-CERTS-MIB, > > work had started > > > > in the IETF to specify a set of MIBs for managing > > IPsec/IKEv2. The > > > > work was far enough along for the definition of FC-SP MIBs to > > > > leverage them as prior work, and to define a small extension of > > > > importance in the Fibre Channel environment. However, > > the approval > > > > process for the IPsec/IKEv2 MIBs was delayed such that the > > > > definition > > > > of FC-SP MIBs caught-up with and was expected to > > overtake those for > > > > IPsec/IKEv2. In order not to create a dependency, this document > > > > defines only the extension, and it does so in a generic > > manner so > > > > that the extension can be applied to any MIB for > > IPsec/IKEv2, either > > > > the completion of the previously-begun work or any > > alternative which > > > > might begin in the future. > > > > > > > > I think a simple technical change is all that is required to make > > > > the definitions (in T11-FC-SP-CERTS-MIB) generic. > > Specifcially, I > > > > suggest we change syntax of t11FcSpCertPointer to be an OID, such > > > > that it can point to any table, i.e., not only into the > > > > ipsaCredentialTable, but also into any other MIB's table. > > > > > > > > I think the above would allow the references to be Informational. > > > > > > > > 3. Decide that the value of the one extra piece of information > > > > (t11FcSpCertUsage) is not important enough for this MIB > > to have any > > > > sort of dependency, and to decide not to define the > > > > T11-FC-SP-CERTS-MIB at the present time. > > > > > > > > Keith. > > > > > > > > > > > > > W.r.t. > > > > > > > One thing I do see that may need some action is the > > > > fact that this > > > > > > > document has normative dependencies on these 2 documents: > > > > > > > > > > > > > > [IPSP-IKE-ACTION] > > > > > > > Baer, M., Charlet, R., Hardaker, W., Story, R., > > > > and C. Wang, > > > > > "IPsec > > > > > > > Security Policy IKE Action MIB", > > > > draft-ietf-ipsp-ikeaction-mib- > > > > > > > nn.txt, work-in-progress, 19 October 2006. > > > > > > > > > > > > > > [IPSP-IPSEC-ACTION] > > > > > > > Baer, M., Charlet, R., Hardaker, W., Story, R., > > > > and C. Wang, > > > > > "IPsec > > > > > > > Security Policy IPsec Action MIB", > > > > > draft-ietf-ipsp-ipsecaction-mib- > > > > > > > nn.txt, work-in-progress, 19 October 2006. > > > > > > > > > > > > > > > > > > > > > However, I do not see that any IMPORT is done for those > > > > 2 IPSP MIB > > > > > > > modules, so maybe the dependency is not really normative? > > > > > > > > > > > > I agree that such a "dependency" is a little risky, because I > > > > > > too submitted some comments on those MIBs. The > > reason that I'm > > > > > > using quotes around "dependency" is because it is not the > > > > > > definitions in this MIB which depend on any > > definitions in those > > > > > > MIBs, but rather the explanation of why this MIB has > > the set of > > > > > > (certificate-related) objects that it does. > > > > > > Without such explanations, the definitions in this MIB would > > > > > > appear incomplete, and it seems to me that making it complete > > > > > > requires either: > > > > > > > > > > > > 1. the reference to the IPSP MIB modules that it > > currently has, > > > > > > or 2. definition of new MIB objects which > > duplicate/overlap with > > > > > > the IPSP MIB modules. > > > > > > > > > > > > Given that the IPSP MIB modules are still expected to get > > > > > > approved (in the future), then I'd say #2 is at least > > > > > > undesirable, and probably unacceptable. > > > > > > > > > > > > > > > > yep... that sounds unacceptable. At the other hand, you > > may end up > > > > > having you approved I-D in the RFC-Editor queue for > > many years to > > > > > come waiting for the dependent IPSP MIB module > > documents to come > > > > > through (sorry... even though there was a message about > > the status > > > > > of IPSP MIB modules in August this year, I have seen no > > activity > > > > > since. I keep being very pessimistic about a reasonable > > result in > > > > > this space). > > > > > > > > > > Maybe one of the ADs (possibly security ADs) can say something > > > > > about this issue or about the "dependency". As long as the docs > > > > > are listed as normative references, your doc will get > > block at the > > > > > RFC-Editor gates till those normative docs are ready to > > become an > > > > > RFC as well. > > > > > > > > > > > > > > > > So, if you can provide guidance on how to reference > > the IPSP MIB > > > > > > modules in a way which avoids creating normative > > dependencies, > > > > > > then please do. > > > > > > > > > > > > > > > > If I read your section 4.6, then it seems that the > > > > > ipsaCredentialTable, the ipsaCredentialSegmentTable and the > > > > > ipiaCredMngCRLTable are needed to manage CAs and CRLs. > > > > > So that to me seems quite a dependency. Are you guys > > aware of how > > > > > your implementations will/might run without those tables? Have > > > > > they currently been implemented in prorpietary ways? > > > > > Or have pre-RFC implementations been fielded? > > > > > > > > > > >From sect 4.6, it seems that your MODULE-COMPLIANCE ought to > > > > > >state > > > > > that those tables from IPSP MIB modules have to be supported in > > > > > order to let your MIB modules/security-features work, no? > > > > > > > > > > Bert > > > > > > Keith. > > > > > > > > > > > > > > > > > > > I will find out when > > > > > > > I read the whole FC-SP MIB document. Sofar I did notice: > > > > > > > > > > > > > > - 4.8.6. The T11-FC-SP-CERTS-MIB Module > > > > > > > > > > > > > > This MIB module specifies extensions to IPSP MIBs > > > > > > [IPSP-IPSEC-ACTION] > > > > > > > and [IPSP-IKE-ACTION] which are specific to Fibre > > > > Channel. In > > > > > > > particular, it specifies one table, t11FcSpCertsTable, > > > > > > with a row per > > > > > > > certificate indicating how that certificate is being > > > > used, and > > > > > > > containing the "name" of the certificate. This "name" > > > > > > can be used to > > > > > > > obtain information, which is independent of > > FC-SP, about the > > > > > > > certificate from the ipsaCredentialTable (and from the > > > > > > > ipsaCredentialSegmentTable if the certificate is > > > > longer than 1024 > > > > > > > bytes). > > > > > > > > > > > > > > - In the T11-FC-SP-CERTS-MIB (page 230/231: > > > > > > > > > > > > > > Since FC-SP leverages a subset of IPsec and > > > > > > IKEv2 (see RFC > > > > > > > 4595), a subset of the management > > > > information defined for > > > > > > > the use of certificates with IPsec/IKEv2 is also > > > > > > applicable > > > > > > > to FC-SP. Thus, this MIB module leverages > > > > RFC wwww and > > > > > > > RFC xxxx for the management of certificates, CAs > > > > > > and CRLs. > > > > > > > -- RFC Editor: replace wwww with actual RFC number for > > > > > > > -- [IPSP-IPSEC-ACTION], and replace xxxx with actual RFC > > > > > > number for > > > > > > > -- [IPSP-IKE-ACTION] & remove this note > > > > > > > > > > > > > > Specifically, the information defined in > > > > this MIB module > > > > > > > consists of a pointer into the IPsec/IKEv2 > > > > MIB modules, > > > > > > > plus minimal additional item(s) of > > > > information which are > > > > > > > considered to be important in a Fibre Channel > > > > > > environment. > > > > > > > > > > > > > > So it does sound normative. So I have a warning: > > > > > > > > > > > > > > I have been reviewing those 2 IPSP documents a few times > > > > > > over the last > > > > > > > (mmmm probably) 2-3 or 2-4 years, and I must warn you that > > > > > > the cycle > > > > > > > times on those documents are EXTREMELY slow. The > > > > current revisions > > > > > > > are: > > > > > > > > > > > > > > draft-ietf-ipsp-ikeaction-mib-02.txt > > > > > > > draft-ietf-ipsp-ipsecaction-mib-02.txt > > > > > > > > > > > > > > which showed up as I-D on 10 Nov 2006, and both are still > > > > > > in Revised > > > > > > > ID needed. Those MIB documents are also pretty complex, and > > > > > > so if/when > > > > > > > a new revision will eventually show up (if at all), then > > > > > > whoever needs > > > > > > > to re-review will need a serious block of time to > > > > actually do so. > > > > > > > My personal experience is pretty bad/sad with those 2 > > > > > > documents, and I > > > > > > > must admit that I am completely de- or un-motivated at this > > > > > > point in > > > > > > > time to re-review them a again if/when they do show up. But > > > > > > possibly > > > > > > > Dan can convince me otherwise at that time. > > > > > > > > > > > > > > Anyway, I just wanted the authors/editors/wg-chair and WG > > > > > > members to > > > > > > > be aware of this risky normative dependency. > > > > > > > > > > > > > > Bert Wijnen > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > > > > > > Sent: Wednesday, October 10, 2007 2:18 AM > > > > > > > > To: imss@ietf.org > > > > > > > > Cc: dromasca@avaya.com; Black_David@emc.com > > > > > > > > Subject: [imss] imss WG Last Call: FC-SP MIB > > > > > > > > Importance: High > > > > > > > > > > > > > > > > This is to announce an imss WG Last Call on the following > > > > > > MIB draft: > > > > > > > > > > > > > > > > MIB for Fibre-Channel Security > > Protocols (FC-SP) > > > > > > > > draft-ietf-imss-fc-fcsp-mib-00.txt > > > > > > > > > > > > > > > > This WG Last Call will run through 12 midnight > > > > Eastern Time on > > > > > > > > Friday, October 26, 2007 (your WG chair hopes to deal > > > > > > with Last Call > > > > > > > > results during the week of October 29th and hopes that > > > > > > any revisions > > > > > > > > can be completed prior to the November 19th > > Internet Draft > > > > > > > > submission cutoff for the Vancouver meeting). > > > > > > > > > > > > > > > > Technical comments *must* be sent to the imss > > mailing list. > > > > > > > > Editorial comments may be sent directly to the draft > > > > editor (but > > > > > > > > please cc: me): > > > > > > > > > > > > > > > > Keith McCloghrie [kzm@cisco.com] > > > > > > > > > > > > > > > > In order to try to set a good example, I have completed > > > > > > my WG chair > > > > > > > > review of the MIB prior to announcing this Last Call. > > > > > > > > > > > > > > > > I found two technical concerns: > > > > > > > > (1) The MIB defines precedence values for traffic > > selectors > > > > > > > > as opposed to implicitly presenting them in order of > > > > > > > > precedence. I guess this is ok, but Section 4.7 should > > > > > > > > explain why this approach was chosen. > > > > > > > > (2) Section 4.9 defines rate control for Authentication > > > > > > > > failures on a per-fabric granularity. That strikes > > > > > > > > me as overly coarse, and I wonder if per-SA would > > > > > > > > be a more appropriate/useful granularity. > > > > > > > > > > > > > > > > I also found a number of editorial concerns: > > > > > > > > > > > > > > > > Section 1, 2nd paragraph. Remove the sentence starting > > > > > > with "This > > > > > > > > latest draft" or insert an instruction to the RFC Editor > > > > > > to remove > > > > > > > > it before publication as an RFC. > > > > > > > > > > > > > > > > Section 3.1 - Delete "The" at the start of the first > > > > paragraph. > > > > > > > > > > > > > > > > Should Section 3.5 and subsequent subsections of > > > > Section 3 all be > > > > > > > > subsections of Section 3.4 Security? > > > > > > > > > > > > > > > > Section 3.10 - "To provide better scaling, the Switch > > > > Connectivity > > > > > > > > Objects are not Fabric-wide information such > > that they are > > > > > > > > distributed only to where they are needed." > > > > > > > > > > > > > > > > "information such that they are" -> information, but are" > > > > > > > > > > > > > > > > Section 3.10 introduces "Active Zone Set" but does not > > > > > > explain what > > > > > > > > this term means. > > > > > > > > > > > > > > > > T11FcSpPolicyNameType - the DESCRIPTION needs to explain > > > > > > the concept > > > > > > > > of "restricted" - how does a "restricted" entity > > > > differ from the > > > > > > > > corresponding unrestricted entity? > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 Nov 29 11:21:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixm8o-0004DL-8h; Thu, 29 Nov 2007 11:21:30 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1Ixm8m-0003h3-C5 for imss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:21:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixm8l-0003Wn-ND for imss@ietf.org; Thu, 29 Nov 2007 11:21:27 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixm8k-00013G-HZ for imss@ietf.org; Thu, 29 Nov 2007 11:21:27 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 29 Nov 2007 08:21:25 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lATGLQkW003058; Thu, 29 Nov 2007 08:21:26 -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 lATGLPgK007341; Thu, 29 Nov 2007 16:21:25 GMT Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA17904; Thu, 29 Nov 2007 08:19:42 -0800 (PST) From: Keith McCloghrie Message-Id: <200711291619.IAA17904@cisco.com> Subject: Re: [imss] MIB doctor review part 1 (SYNTAX Checks): To: bwijnen@alcatel-lucent.com Date: Thu, 29 Nov 2007 08:19:42 -0800 (PST) In-Reply-To: from "WIJNEN, Bert \(Bert\)" at Nov 26, 2007 03:46:51 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=9333; t=1196353286; x=1197217286; 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=20[imss]=20MIB=20doctor=20review=20part=201=20(SYNTAX=2 0Checks)=3A |Sender:=20; bh=IpcWHjKnZOoBdCtrwKrx8Jd7V32VKZIm53Tb7DbdmOI=; b=ua32IRnjFC2DPZqrhWFSxNH+5Sn4/ZTLZizOnVivcfnGajq0HON3EZYYh7+IxVPvf7RelapO 3ulMMAP/IeVcPr9mCeZ4SKDe9FMt6BeQUwTgQ4VJYTLz/xv0hI5ogqhNsddID8MMtbug6QRSQB 8U94vH3af5T5HHDLECJXdkyx8=; Authentication-Results: sj-dkim-1; header.From=kzm@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: imss@ietf.org, Black_David@emc.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 Bert, I checked the "consistent indexing scheme" items below and concluded that the indexing is fine as-is. So, in ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-fcsp-mib-01.txt (which I cited in my message yesterday), I included all the fixes that you requested below (including explicitly specifying ranges which are the same as the implicit default range:-). Keith. > 1. T11-FC-SP-TC-MIB > > C:\bwijnen\smicng\imss>smicng T11-FC-SP-TC-MIB.inc > W: f(T11-FC-SP-TC-MIB), (40,15) The first revision should match > the last update for MODULE-IDENTITY t11FcTcMIB > *** 0 errors and 1 warning in parsing > > C:\bwijnen\smicng\imss>smilint ./T11-FC-SP-TC-MIB > ./T11-FC-SP-TC-MIB:44: revision for last update is missing > > I think it would be good to to get the REVISION and LAST-UPDATED > timestamps in sync. No big deal though. > > 2. T11-FC-SP-ZONING-MIB > > C:\bwijnen\smicng\imss>smicng T11-FC-SP-ZONING-MIB.inc > W: f(T11-FC-SP-ZONING-MIB), (404,20) Variable "ifIndex" in > notification > "t11FcSpZsFabricJoinSuccessNotify" is an index for a table > W: f(T11-FC-SP-ZONING-MIB), (420,20) Variable "ifIndex" in > notification > "t11FcSpZsFabricJoinFailureNotify" is an index for a table > > *** 0 errors and 2 warnings in parsing > > C:\bwijnen\smicng\imss>smilint -l 6 -m -s ./T11-FC-SP-ZONING-MIB > .. OK > > I think this is OK in this situation. > > 3. T11-FC-SP-SA-MIB > > C:\bwijnen\smicng\imss>smicng T11-FC-SP-SA-MIB.inc > E: f(T11-FC-SP-SA-MIB), (1781,36) Item "t11FcSpSaTSelSpiDirection" in > sequence "T11FcSpSaTSelSpiEntry" has conflicting syntax specified > > bw: caused by INTEGER and T11FcSaDirection TC (which has underlying > SYNTAX of INTEGER (enumerated). So I am not sure it is a real > error. At the other hand, the/a fix is easy, namely change > > T11FcSpSaTSelSpiEntry ::= SEQUENCE { > t11FcSpSaTSelSpiInboundSpi T11FcSpiIndex, > t11FcSpSaTSelSpiTrafSelIndex Unsigned32, > t11FcSpSaTSelSpiDirection INTEGER, > t11FcSpSaTSelSpiTrafSelPtr Unsigned32 > } > > into: > > T11FcSpSaTSelSpiEntry ::= SEQUENCE { > t11FcSpSaTSelSpiInboundSpi T11FcSpiIndex, > t11FcSpSaTSelSpiTrafSelIndex Unsigned32, > t11FcSpSaTSelSpiDirection T11FcSaDirection, > t11FcSpSaTSelSpiTrafSelPtr Unsigned32 > } > > It would also make it more consistent with other places where you > have used T11FcSaDirection TC. > > E: f(T11-FC-SP-SA-MIB), (512,14) Index item "t11FcSpSaPropIndex" must > be defined with syntax that includes a range > > bw: I tend to agree with that. For example I wonder of zero is a > valid > index value. If it is, then we better explicitly include it (and > add > text to the DESCRIPTION clause what that means). If it is not, > then we better exclude it. > > E: f(T11-FC-SP-SA-MIB), (684,14) Index item > "t11FcSpSaTSelPropListIndex" > must be defined with syntax that includes a range > E: f(T11-FC-SP-SA-MIB), (684,42) Index item "t11FcSpSaTSelPropIndex" > must be defined with syntax that includes a range > > bw: same story for those above 2 error messages. > > E: f(T11-FC-SP-SA-MIB), (928,14) Index item "t11FcSpSaTransListIndex" > must be defined with syntax that includes a range > E: f(T11-FC-SP-SA-MIB), (928,39) Index item "t11FcSpSaTransIndex" > must > be defined with syntax that includes a range > > bw: same story for those above 2 error messages. > > E: f(T11-FC-SP-SA-MIB), (1069,42) Index item > "t11FcSpSaTSelDrByPrecedence" > must be defined with syntax that includes a range > > bw: would be easy to fix in TC module: > > T11FcSpPrecedence ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "The precedence of a Traffic Selector. If a frame > matches with two or more Traffic Selectors, then the match > which takes precedence is the one with the Traffic Selector > having the numerically smallest precedence value. Note that > precedence values are not necessarily contiguous." > SYNTAX Unsigned32 -- the default range: (0..4294967295) > > > Why not just specify that range. It makes sense (I guess) that > a value of zero in this case is valid, and so would also be > a valid/acceptable INDEX value. We betetr make that explicit > (or so I think). > > E: f(T11-FC-SP-SA-MIB), (1259,38) Index item > "t11FcSpSaPairInboundSpi" > must be defined with syntax that includes a range > > bw: same as above. > > E: f(T11-FC-SP-SA-MIB), (1457,38) Index item > "t11FcSpSaTSelNegInIndex" > must be defined with syntax that includes a range > > bw: SO is zero a valid/acceptable index? If so we better explicitly > include that. If not, then we must exclude it. > > E: f(T11-FC-SP-SA-MIB), (1624,38) Index item > "t11FcSpSaTSelNegOutPrecedence" > must be defined with syntax that includes a range > > bw: see comment above on the use of T11FcSpPrecedence TC > > E: f(T11-FC-SP-SA-MIB), (1774,14) Index item > "t11FcSpSaTSelSpiInboundSpi" > must be defined with syntax that includes a range > > bw: see above > > E: f(T11-FC-SP-SA-MIB), (1774,42) Index item > "t11FcSpSaTSelSpiTrafSelIndex" > must be defined with syntax that includes a range > > bw: Is zero a valid/acceptable value. It seems to me that in this > case > we prefer NOT to allow for zero. So make that explicit. > > W: f(T11-FC-SP-SA-MIB), (1257,32) Row "t11FcSpSaPairEntry" does not > have > a consistent indexing scheme - index items from current table must > come > after index items from other tables > W: f(T11-FC-SP-SA-MIB), (1456,32) Row "t11FcSpSaTSelNegInEntry" does > not > have a consistent indexing scheme - cannot specify an index item > from > additional "base row" t11FcSpSaPairEntry, since can have only one > "base row" which is t11FcSpSaIfEntry > W: f(T11-FC-SP-SA-MIB), (1623,32) Row "t11FcSpSaTSelNegOutEntry" does > not > have a consistent indexing scheme - cannot specify an index item > from > additional "base row" t11FcSpSaPairEntry, since can have only one > "base row" which is t11FcSpSaIfEntry > W: f(T11-FC-SP-SA-MIB), (1772,32) Row "t11FcSpSaTSelSpiEntry" does > not > have a consistent indexing scheme - cannot specify an index item > from additional "base row" t11FcSpSaPairEntry, since can have only > one "base row" which is t11FcSpSaIfEntry > > The "non-consistent indexing scheme" issue is possibly just a > warning. > In these cases I always ask the author: Pls check that what you did > is what you intended. If so, then I think the above 4 are fine. > I must say that the indexing certainly is not immediately obvious. > I will need to go look in detail to convince myself. > > *** 12 errors and 4 warnings in parsing > > > C:\bwijnen\smicng\imss>smilint -l 6 -m -s ./T11-FC-SP-ZONING-MIB > .. OK > > 4. T11-FC-SP-POLICY-MIB > > C:\bwijnen\smicng\imss>smicng T11-FC-SP-POLICY-MIB.inc > E: f(T11-FC-SP-POLICY-MIB), (1528,14) Index item > "t11FcSpPoAuthProtIdentifier" must be defined with syntax > that includes a range > > bw: Assuming that http://www.t11.org/ftp/t11/pub/fc/sp/06-157v3.pdf > is the proper document to look at, for table 11. > From that table one could conclude that value zero is part > of the "all others", but at the other hand, I would have put > value zero as reserved at the top of the table if value > zero is valid. > > So... is it valid? In any event, I would make the range (0-4billion) > or 1-4billion) explicit I think. > > E: f(T11-FC-SP-POLICY-MIB), (3443,14) Index item > "t11FcSpPoNaAuthProtIdentifier" must be defined with syntax > that includes a range > > bw: same story. > > *** 2 errors and 0 warnings in parsing > > > C:\bwijnen\smicng\imss>smilint -l 6 -m -s ./T11-FC-SP-POLICY-MIB > .. OK > > 5. T11-FC-SP-CERTS-MIB > > C:\bwijnen\smicng\imss>smicng T11-FC-SP-CERTS-MIB.inc > E: f(T11-FC-SP-CERTS-MIB), (90,38) Index item "t11FcSpCertIndex" > must be defined with syntax that includes a range > > bw: seems (to me) that we would want to exlude zero as an > acceptable value. > > *** 1 error and 0 warnings in parsing > > C:\bwijnen\smicng\imss>smilint -l 6 -m -s ./T11-FC-SP-CERTS-MIB > .. OK > > 6. T11-FC-SP-AUTHENTICATION-MIB > > C:\bwijnen\smicng\imss>smicng T11-FC-SP-AUTHENTICATION-MIB.inc > Successful parsing > > C:\bwijnen\smicng\imss>smilint -l 6 -m -s > ./T11-FC-SP-AUTHENTICATION-MIB > .. OK > > > 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 Thu Nov 29 13:06:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixnmm-0000gB-Kz; Thu, 29 Nov 2007 13:06:52 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1Ixnml-0000fm-MR for imss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 13:06:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixnml-0000fV-AO for imss@ietf.org; Thu, 29 Nov 2007 13:06:51 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixnmk-0001L5-DI for imss@ietf.org; Thu, 29 Nov 2007 13:06:51 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 29 Nov 2007 10:06:49 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lATI6niu026007; Thu, 29 Nov 2007 10:06:49 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lATI6nqZ019342; Thu, 29 Nov 2007 18:06:49 GMT Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA07634; Thu, 29 Nov 2007 10:05:06 -0800 (PST) From: Keith McCloghrie Message-Id: <200711291805.KAA07634@cisco.com> Subject: Re: [imss] MIB doctor review part 2 (T11-FC-SP-TC-MIB): To: bwijnen@alcatel-lucent.com Date: Thu, 29 Nov 2007 10:05:06 -0800 (PST) In-Reply-To: from "WIJNEN, Bert \(Bert\)" at Nov 26, 2007 06:08:52 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=5745; t=1196359609; x=1197223609; 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=20[imss]=20MIB=20doctor=20review=20part=202=20(T11-FC-S P-TC-MIB)=3A |Sender:=20; bh=I1M27COPosSwsK1QI7NUaxS8l4xYinyispw4HC3c0FM=; b=WJ/5z4n6ae65dxcIRF63xL4atjWWh0KsJkwlJxXrUIrdrrdyK0Qg9vPWn4ToOKxefNRfN4rr IwbjG7PCuOrkxAJ7PSLgUi7u24vskeV9sFsfC5VOqdkh3iC9bV1kCb78OZiqngDApnb1GyPcB6 xlhZKImuvwGFvPBcWvQK7JXPU=; 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: 8f374d0786b25a451ef87d82c076f593 Cc: imss@ietf.org 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 Thanks for your first (of many, I'm sure!!) sets of comments on the document. > Here are my comments/questions on the T11-FC-SP-TC-MIB module > > 1. I find it somewhat weird to see: > > t11FcTcMIB MODULE-IDENTITY > LAST-UPDATED "200708130000Z" > ORGANIZATION "For the initial versions, T11. > For later versions, the IETF's IMSS Working > Group." > > The one version that gets formally published is the one in the > upcoming RFC. At that time there are basically no "initial" versions > other than the one in the RFC. First, I feel it's valuable to acknowledge T11 in the MIB module itself, not just in the RFC, because: a) they deserve the acknowledgement, and b) it indicates that this MIB benefitted from their Fibre Channel expertise. Second, RFC 2578 says: The ORGANIZATION clause, which must be present, contains a textual description of the organization under whose auspices this information module was developed. and there were two such organizations: an initial one and a later one. So, we could change the word "version" to something else if you like, but otherwise, I think it's kosher. Would you prefer it to say something like: ORGANIZATION "This MIB module was a coordinated development of two organizations: T11 began the development and the IETF's IMSS Working Group finished it." > 2. looking at T11FcSpPolicyHashFormat and T11FcSpPolicyHashValue I > wonder > if/how often the TCS will need to be updated? And when that is done, > a. do we then want to create a new RFC or > b. should this become an iana maintained module? The definition is intentionally designed such that the answers to your questions are: never, no, and no. That is, the TC provides a REFERENCE to the location in FC-SP where values are defined, the syntax of both objects is based on the field sizes, not on assigned values, and the DESCRIPTION lists the "first two" assignments, but only as an FYI, not as the definitive specification. In other words, the TCs are written so that they do not have to be updated when new assignments are made, which avoids the work of creating a new RFC and avoids creating extra work for IANA. > If we need to create a new MIB module ourselves (option a), then > we could be more specific this time by making the SYNTAX for > T11FcSpPolicyHashValue as follows: > > SYNTAX OCTET STRING (SIZE (20 | 32)) > > because there are no other lengths possible given the currently > specified/valid formats. See above -- the syantax is based on the field size, not on the currently assigned values. That is, it is based on Table 106, not on Table 107, of FC-SP (06-157v3) > 3. I am not sure if (how) it is wise to merge values from > 3 different tables in the FC-SP spec (tables 17/18, 48 and 52) > into one Textual Convention for the code and one for CodeExp. > > T11FcSpAuthRejectReasonCode > T11FcSpAuthRejReasonCodeExp > > In some cases, not all values are valid, are they? The set of > reasons and Reason Explanations is different for the 3 > types of messages listed in the DESCRIPTION clause. > > Maybe it is OK, but I am somewhat worried. If they were three unrelated values, then I would share your concern. However, all three types are potential values of a reason code (or reason code explanation). In effect, the merge here is the same as woudl be done by using a C-language "union" construct, but the SMIv2 doesn't have one. The merge is possible in this case because the combined set of potential values can all be included uniquely by assigning a unique named-number enumeration for each one. > 4. T11FcSpPolicyNameType > I find it very unfriendly that Internationalized names are not > defined/allowed. But I do see that the base spec [FC-SP] does > not allow it, so I guess we can only model the spec that T11 > has approved (or will approve). Perhaps, Claudio and David can take this comment back to T11 for consideration in FC-SP2. > 5. Personal and subjective preference: I would rename > > T11FcSpAlphaNumNameOrNull > > into > > T11FcSpAlphaNumNameOrNone > > The "Null" often makes people think of 0 (zero). I checked existing RFCs, and I found one xxOrNull and four xxOrNone TCs, two of which (VlanIdOrNone and VlanIdOrAnyOrNone) are integer-valued with "None" representing zero !! So, the precedent is not that clear (except for the one you defined yourself:-). Perhaps the greatest clarity would be: T11FcSpAlphaNumNameOrAbsent ?? > 6. As reported by the SYNTAX checkers, I would change the underlying > SYNTAX for T11FcSpiIndex and T11FcSpPrecedence to be > > SYNTAX Unsigned32 (0..4294967295) > > instead of: > > SYNTAX Unsigned32 -- the default range: (0..4294967295) I did change them, but please note that RFC 2578 defines it as: Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) so the change is unquestionably redundant. > 7. I wonder if it would be good (I think it would be) to add a > REFERENCE clause to each of the Encryption and Authentication > algorithms specified by the OBKECT-IDENTITIES. It will be somewhat repetitious because all of the ENCR_xxx are in Table 70, and all of the AUTH_xxx are in Table 71, but if you're concerned that the macros could be extracted and displayed individually rather than as part of the MIB, then yes, there is a circumstance where it would be advantageous. Thanks, Keith. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss