From imss-bounces@ietf.org Tue Oct 09 20:18:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfPHU-0004FN-5j; Tue, 09 Oct 2007 20:18:32 -0400 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IfPHT-0004FE-7D for imss-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 20:18:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfPHS-00049I-SS for imss@ietf.org; Tue, 09 Oct 2007 20:18:30 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfPHE-0001SU-NM for imss@ietf.org; Tue, 09 Oct 2007 20:18:22 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9A0Hsig006779; Tue, 9 Oct 2007 20:17:54 -0400 (EDT) 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 l9A0Hg0b013137; Tue, 9 Oct 2007 20:17:53 -0400 (EDT) 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); Tue, 9 Oct 2007 20:17:46 -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: Tue, 9 Oct 2007 20:17:33 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: imss WG Last Call: FC-SP MIB thread-index: AcgK0vLbbD32Q+kDSKqF52DDcvyXNQ== X-Priority: 1 Priority: Urgent Importance: high To: X-OriginalArrivalTime: 10 Oct 2007 00:17:46.0741 (UTC) FILETIME=[FC014250:01C80AD2] 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, PRIORITY_NO_NAME 0.716, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_PRIORITY 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: dromasca@avaya.com, Black_David@emc.com Subject: [imss] 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 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 From imss-bounces@ietf.org Wed Oct 10 17:39:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfjH8-0005Xd-4P; Wed, 10 Oct 2007 17:39:30 -0400 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IfjH6-0005Uc-Se for imss-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 17:39:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfjH6-0005PZ-DD for imss@ietf.org; Wed, 10 Oct 2007 17:39:28 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfjH5-0003Qn-GH for imss@ietf.org; Wed, 10 Oct 2007 17:39:28 -0400 X-IronPort-AV: E=Sophos;i="4.21,256,1188802800"; d="scan'208";a="234308479" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 10 Oct 2007 14:39:27 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9ALdQpe011277; Wed, 10 Oct 2007 14:39:26 -0700 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 l9ALdQlD015977; Wed, 10 Oct 2007 21:39:26 GMT Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA11681; Wed, 10 Oct 2007 14:38:02 -0700 (PDT) From: Keith McCloghrie Message-Id: <200710102138.OAA11681@cisco.com> Subject: Re: [imss] imss WG Last Call: FC-SP MIB To: Black_David@emc.com Date: Wed, 10 Oct 2007 14:38:02 -0700 (PDT) In-Reply-To: from "Black_David@emc.com" at Oct 09, 2007 08:17:33 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=5754; t=1192052366; x=1192916366; 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=4EDC5OcuVOWr66nE82D2TVza7jp5xTS2JYRTYz39n2M=; b=yT8tiX012ZsHjsw2VsrXnz+tDDpIE0qGCN2h/diftjbw5DHyoSrmnmHFbrwJlPra2382VumW UvTKvZyzXDzm8lRJarpa/239/jM+6TGK1FtUpeASp3wo5NDFH8WSWVL/; Authentication-Results: sj-dkim-2; header.From=kzm@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 David, > 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. Thanks for your review. > 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. This point has a bearing on two issues related to the use of Precedence objects in an INDEX clause. First, the question of whether an object containing a Precedence value should be in an INDEX clause or not. There are pros and cons: pro: having a Precedence object in a table's INDEX clause allows the table's rows to be retrieved (by SNMP getNext/getBulk) in order of Precedence. con: in a read-write/create table, objects which are not in the INDEX clause can be modified with a single PDU (SNMP setRequest), but an object in an INDEX clause can only be changed by deleting its row(s) and creating new row(s); this is not only two SNMP PDUs, but also there is a "gap", a time-period between the two, and for a Security MIB during such a gap, there is either too much or too little security, where "too little" is likely a security hole. Note that the "con" applies only to read-write/create tables, and so having t11FcSpSaTSelNegOutPrecedence in the INDEX clause of the (read-only) t11FcSpSaTSelNegOutTable table is justified by the pro. There are two other xxxPrecedence objects, t11FcSpSaTSelDrByPrecedence and t11FcSpSaTSelPropPrecedence, which are both in read-write/create tables, but one of them is in an INDEX clause and the other is not. As far as I can remember, this difference was created inadvertently, and I'm unable (at present) to think of any reason to justify the inconsistency. The second issue is that, when a Precedence object is used in an INDEX clause, its value serves not only as an indication of precedence, but also to distinguish one traffic selector from another. In other words, Precedence values in INDEX clauses in this MIB have two functions: "Traffic Selector index" and "Precedence vaue". So, the choice of whether such an object is called a "Precedence" or a "TrafSelectorIndex" is a terminology issue, not a structural issue. Its use in the INDEX clauses clearly indicates its purpose as an index, without it being so named explicitly. Thus, I think a greater increase in clarity is achieved by naming it as xxxPrecedence. So, I think the document should be changed in two ways: 1. t11FcSpSaTSelDrByPrecedence and t11FcSpSaTSelPropPrecedence should be made consistent, either have both in their respective table's INDEX clause, or, neither in their respective table's INDEX clause. Further, I'll make a suggestion based on my expectation of the likely usage of this MIB; specifically, that the majority of the expected usage of this MIB will be for read-only monitoring, with its capability for read-write configuration rarely implemented, and even more rarely used. Thus, I recommend that we optimize for reading, not for writing. Thus, I recommend we combine the semantics of t11FcSpSaTSelPropPrecedence and t11FcSpSaTSelPropIndex with the former taking the latter's place in the INDESX clause of the t11FcSpSaTSelPropTable table. 2. that I add words (a subset of the above) to section 4.7 so as to provide an explanation of the use of Precedence values in INDEX clauses. > (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 think the question here is whether it's likely that authentication failures will occur on many SA's at the same time -- if it is likely, then per-Fabric rate control allows for plenty of notifications in isolated cases without getting overloaded when many SA's have the problem. But, if there's no correlation between occurrences on different SA's, then the odds of many SA's having the problem at the same time is presumably negligible, and I agree that per-SA would be better. (Aside: MIB objects which are powerful enough to slow down the rate of Authentication failures is, unfortunately, wishful thinking :-). > I also found a number of editorial concerns: I'll make all of your editorial suggestions. Keith. > 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 From imss-bounces@ietf.org Thu Oct 11 01:23:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfqWT-00074S-Pw; Thu, 11 Oct 2007 01:23:49 -0400 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IfqWT-00074F-Cs for imss-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 01:23:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfqWS-0006yI-UJ for imss@ietf.org; Thu, 11 Oct 2007 01:23:49 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfqWK-00037f-13 for imss@ietf.org; Thu, 11 Oct 2007 01:23:40 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9B5Na4q023015; Thu, 11 Oct 2007 01:23:36 -0400 (EDT) Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9B5Mg4G013039; Thu, 11 Oct 2007 01:23:33 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 01:23:09 -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 Subject: RE: [imss] imss WG Last Call: FC-SP MIB Date: Thu, 11 Oct 2007 01:23:09 -0400 Message-ID: In-Reply-To: <200710102138.OAA11681@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [imss] imss WG Last Call: FC-SP MIB thread-index: AcgLhgQjZKQfVGZiQvmYzrvy+0myVAAO3K3w References: from "Black_David@emc.com" at Oct 09, 2007 08:17:33 PM <200710102138.OAA11681@cisco.com> To: X-OriginalArrivalTime: 11 Oct 2007 05:23:09.0751 (UTC) FILETIME=[CFC87470:01C80BC6] 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, __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: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d 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, > > 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. >=20 > This point has a bearing on two issues related to the use of Precedence > objects in an INDEX clause. First, the question of whether an object > containing a Precedence value should be in an INDEX clause or not. > There are pros and cons: >=20 > pro: having a Precedence object in a table's INDEX clause allows the > table's rows to be retrieved (by SNMP getNext/getBulk) in order > of Precedence. > con: in a read-write/create table, objects which are not in the INDEX > clause can be modified with a single PDU (SNMP setRequest), but an > object in an INDEX clause can only be changed by deleting its row(s) > and creating new row(s); this is not only two SNMP PDUs, but also > there is a "gap", a time-period between the two, and for a Security > MIB during such a gap, there is either too much or too little > security, where "too little" is likely a security hole. >=20 > Note that the "con" applies only to read-write/create tables, and so > having t11FcSpSaTSelNegOutPrecedence in the INDEX clause of the > (read-only) t11FcSpSaTSelNegOutTable table is justified by the pro. >=20 > There are two other xxxPrecedence objects, t11FcSpSaTSelDrByPrecedence > and t11FcSpSaTSelPropPrecedence, which are both in read-write/create > tables, but one of them is in an INDEX clause and the other is not. > As far as I can remember, this difference was created inadvertently, > and I'm unable (at present) to think of any reason to justify the > inconsistency. >=20 > The second issue is that, when a Precedence object is used in an INDEX > clause, its value serves not only as an indication of precedence, but > also to distinguish one traffic selector from another. In other words, > Precedence values in INDEX clauses in this MIB have two functions: > "Traffic Selector index" and "Precedence vaue". So, the choice of > whether such an object is called a "Precedence" or a "TrafSelectorIndex" > is a terminology issue, not a structural issue. Its use in the INDEX > clauses clearly indicates its purpose as an index, without it being > so named explicitly. Thus, I think a greater increase in clarity is > achieved by naming it as xxxPrecedence. I appreciate the explanation, and agree with your line of reasoning. > So, I think the document should be changed in two ways: >=20 > 1. t11FcSpSaTSelDrByPrecedence and t11FcSpSaTSelPropPrecedence should > be made consistent, either have both in their respective table's INDEX > clause, or, neither in their respective table's INDEX clause. Further, > I'll make a suggestion based on my expectation of the likely usage of > this MIB; specifically, that the majority of the expected usage of this > MIB will be for read-only monitoring, with > its capability for read-write configuration rarely implemented, and > even more rarely used. Thus, I recommend that we optimize for reading, > not for writing. Thus, I recommend we combine the semantics of > t11FcSpSaTSelPropPrecedence and t11FcSpSaTSelPropIndex with the former > taking the latter's place in the INDEX clause of the > t11FcSpSaTSelPropTable table. > > 2. that I add words (a subset of the above) to section 4.7 so as to > provide an explanation of the use of Precedence values in=20 > INDEX clauses. I agree - both of these should be done. > > (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 think the question here is whether it's likely that authentication > failures will occur on many SA's at the same time -- if it is likely, > then per-Fabric rate control allows for plenty of notifications in > isolated cases without getting overloaded when many SA's have the > problem. But, if there's no correlation between occurrences on > different SA's, then the odds of many SA's having the problem at the > same time is presumably negligible, and I agree that per-SA would be > better. I think this also revolves around the number of SAs. I would expect FC-SP SA usage to be more akin to a site-to-site VPN (small number of SAs carrying large amounts of traffic) than a remote access VPN (large number of SAs carrying smaller amounts of traffic). That should limit the size of a one-per-SA notification burst in practice. I definitely agree with your concern about overload, as authentication failures are relatively cheap to generate (e.g., attacker need not do any crypto calculations), and hence causing a large number of such failures in a short time period could be a denial of service attack based on the work involved in generating the notifications. OTOH, this text: For t11FcSpSaNotifyAuthFailure, rate control is achieved by specifying that it is generated only for the first occurrence of an Authentication failure on a particular Fabric within a time window. strikes me as providing unwarranted help for an attacker trying to cover her tracks - she opens an SA to the victim, generates an authentication failure, thereby generating the first notification, and can then attack other SAs for the same fabric within the time window, since their notifications are suppressed. Perhaps what's appropriate is a 2-level rate limiting structure: - At most one notification per SA in the (settable) time window. - At most (new settable value) notifications per fabric in the same (settable) time window. > (Aside: MIB objects which are powerful enough to slow down the rate of > Authentication failures is, unfortunately, wishful thinking :-). That's my mistake - I meant to write "rate control for Authentication failure notifications", but nonetheless, an authentication failure rate limiting mechanism in this sort of situation involving many independent authentications seems like a fine candidate for an April 1st RFC in the tradition of the "evil bit" (RFC 3514). > > I also found a number of editorial concerns: > =20 > I'll make all of your editorial suggestions. >=20 Great. 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 From imss-bounces@ietf.org Thu Oct 11 23:53:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgBa3-0003OX-Uu; Thu, 11 Oct 2007 23:52:55 -0400 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IgBa2-0003OQ-Mu for imss-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 23:52:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgBa2-0003OI-By for imss@ietf.org; Thu, 11 Oct 2007 23:52:54 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgBa1-0002Ht-Ta for imss@ietf.org; Thu, 11 Oct 2007 23:52:54 -0400 X-IronPort-AV: E=Sophos;i="4.21,263,1188802800"; d="scan'208";a="235324336" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 11 Oct 2007 20:52:53 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9C3qrkY020674; Thu, 11 Oct 2007 20:52:53 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9C3qrZp012348; Fri, 12 Oct 2007 03:52:53 GMT Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA24389; Thu, 11 Oct 2007 20:51:28 -0700 (PDT) From: Keith McCloghrie Message-Id: <200710120351.UAA24389@cisco.com> Subject: Re: [imss] imss WG Last Call: FC-SP MIB To: Black_David@emc.com Date: Thu, 11 Oct 2007 20:51:28 -0700 (PDT) In-Reply-To: from "Black_David@emc.com" at Oct 11, 2007 01:23:09 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=2457; t=1192161173; x=1193025173; 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=1/mpNBJ+N3REipHq459A0tHNIcwRjpDY8TwLFUi36ws=; b=AvPyVLr2nJYiwsDxC6T3SKKVnTOwdc3XI93+sjkS+XW0rlX35cn6UsjBX1wW5lcdW3dPcGtO 3OCOrQ/Oxh+TSMhZWeDNcE6VnPX1Ggulkl5NxBr7n4Xzxb+qImlplxzr; 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: 8b431ad66d60be2d47c7bfeb879db82c Cc: imss@ietf.org, kzm@cisco.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 > ... > > > > (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 think the question here is whether it's likely that authentication > > failures will occur on many SA's at the same time -- if it is likely, > > then per-Fabric rate control allows for plenty of notifications in > > isolated cases without getting overloaded when many SA's have the > > problem. But, if there's no correlation between occurrences on > > different SA's, then the odds of many SA's having the problem at the > > same time is presumably negligible, and I agree that per-SA would be > > better. > > I think this also revolves around the number of SAs. I would expect > FC-SP SA usage to be more akin to a site-to-site VPN (small number of > SAs carrying large amounts of traffic) than a remote access VPN > (large number of SAs carrying smaller amounts of traffic). That > should limit the size of a one-per-SA notification burst in practice. > > I definitely agree with your concern about overload, as authentication > failures are relatively cheap to generate (e.g., attacker need not do > any crypto calculations), and hence causing a large number of such > failures in a short time period could be a denial of service attack > based on the work involved in generating the notifications. > > OTOH, this text: > > For t11FcSpSaNotifyAuthFailure, rate control is achieved by > specifying that it is generated only for the first occurrence of an > Authentication failure on a particular Fabric within a time window. > > strikes me as providing unwarranted help for an attacker trying > to cover her tracks - she opens an SA to the victim, generates > an authentication failure, thereby generating the first notification, > and can then attack other SAs for the same fabric within the time > window, since their notifications are suppressed. > > Perhaps what's appropriate is a 2-level rate limiting structure: > - At most one notification per SA in the (settable) time window. > - At most (new settable value) notifications per fabric in > the same (settable) time window. That sounds fine to me. (FYI - I'm going to keep track of the changes we agree upon, and do all the editing after the end of the Last Call.) Keith. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Oct 15 05:59:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhMja-0001Ln-73; Mon, 15 Oct 2007 05:59:38 -0400 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IhMjY-0001LF-3i for imss-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 05:59:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhMjX-0001L6-D4 for imss@ietf.org; Mon, 15 Oct 2007 05:59:35 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhMjR-0002fz-6T for imss@ietf.org; Mon, 15 Oct 2007 05:59:35 -0400 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 l9F9wucO007590; Mon, 15 Oct 2007 04:59:01 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 04:58:59 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 11:58:57 +0200 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, 15 Oct 2007 11:58:52 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [imss] imss WG Last Call: FC-SP MIB Thread-Index: AcgK0vLbbD32Q+kDSKqF52DDcvyXNQEPLtJA References: From: "WIJNEN, Bert \(Bert\)" To: , X-OriginalArrivalTime: 15 Oct 2007 09:58:57.0034 (UTC) FILETIME=[006276A0:01C80F12] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: 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 am starting to take a look at this document. Will take a while. It has 249 pages and 6 MIB modules. One thing I do see that may need some action is the fact that this document has normative dependencies=20 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 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=20 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.=20 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=20 time to re-review them a again if/when they do show up. But possibly=20 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 =20 > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > 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 Eastern Time=20 > on Friday, October 26, 2007 (your WG chair hopes to deal with=20 > Last Call results during the week of October 29th and hopes=20 > that any revisions can be completed prior to the November=20 > 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=20 > (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=20 > 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=20 > "This latest draft" or insert an instruction to the RFC=20 > 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=20 > 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=20 > explain what this term means. >=20 > T11FcSpPolicyNameType - the DESCRIPTION needs to explain the=20 > concept of "restricted" - how does a "restricted" entity=20 > 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 >=20 > _______________________________________________ > imss mailing list > imss@ietf.org > https://www1.ietf.org/mailman/listinfo/imss >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Oct 15 14:56: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 1IhV6w-0000x5-DQ; Mon, 15 Oct 2007 14:56:18 -0400 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IhV6u-0000wf-LF for imss-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 14:56:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhV6t-0000vl-FB for imss@ietf.org; Mon, 15 Oct 2007 14:56:15 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhV6s-0006x8-1m for imss@ietf.org; Mon, 15 Oct 2007 14:56:15 -0400 X-IronPort-AV: E=Sophos;i="4.21,278,1188802800"; d="scan'208";a="237456191" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Oct 2007 11:56:13 -0700 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 l9FIuDvt012389; Mon, 15 Oct 2007 11:56:13 -0700 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 l9FIuCx7015809; Mon, 15 Oct 2007 18:56:13 GMT Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA02590; Mon, 15 Oct 2007 11:54:47 -0700 (PDT) From: Keith McCloghrie Message-Id: <200710151854.LAA02590@cisco.com> Subject: Re: [imss] imss WG Last Call: FC-SP MIB To: bwijnen@alcatel-lucent.com Date: Mon, 15 Oct 2007 11:54:47 -0700 (PDT) In-Reply-To: from "WIJNEN, Bert \(Bert\)" at Oct 15, 2007 11:58:52 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=8036; t=1192474573; x=1193338573; 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=gXGDvrfOf++7PSIdn+SNOkEMtTkBGiiXdxOpNOmROK4=; b=DzgDxGHwW3SCGWFd717AhSiu6JYsurFEMKmTb8euLEVaIGOGVOZV7CRoWBYt/H/nwqdAXZmb K8p2YTVSVHx28GTvLa2xKR+IzHkCioqTeVdICud+h7NH0IFcdbfym8eD75zjcjzIMwoXCqEd9u AFqsmzv887Hy8AsOysEkq8Cxg=; 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: 43317e64100dd4d87214c51822b582d1 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 Hi Bert, > I am starting to take a look at this document. Thanks. > Will take a while. It has 249 pages and 6 MIB modules. Understood, but the hope is that it will take less time/effort than the cumulative time/effort of reviewing 6 separate documents. > 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. 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. 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