From Frederick.Knight@netapp.com Tue Mar 31 12:17:40 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760D328C199 for ; Tue, 31 Mar 2009 12:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2+OWnnN+rFy for ; Tue, 31 Mar 2009 12:17:39 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 8C3353A6DCC for ; Tue, 31 Mar 2009 12:17:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,303,1235980800"; d="scan'208";a="148385170" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 31 Mar 2009 12:18:39 -0700 Received: from sacrsexc1-prd.hq.netapp.com (sacrsexc1-prd.hq.netapp.com [10.99.115.27]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id n2VJIaSr024480; Tue, 31 Mar 2009 12:18:38 -0700 (PDT) Received: from rtprsexc1-prd.hq.netapp.com ([10.100.161.114]) by sacrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 12:18:37 -0700 Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 15:18:32 -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, 31 Mar 2009 15:17:35 -0400 Message-ID: In-Reply-To: <18898.26477.64898.577194@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] iSCSI-specific unit attention conditions Thread-Index: AcmyMnYPeHHqZjA+QBCYa8sO8ECKJQAAPBNQ From: "Knight, Frederick" To: "Paul Koning" , X-OriginalArrivalTime: 31 Mar 2009 19:18:32.0203 (UTC) FILETIME=[7AEB6DB0:01C9B235] X-Mailman-Approved-At: Wed, 01 Apr 2009 08:01:43 -0700 Cc: ips@ietf.org Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 19:17:40 -0000 My interpretation of the "update" part of the agenda was that SAM-4 was an example (and that we should also include SAM-3 and SAM-5 as part of the update list). Therefore, to add SPC to the update list is (in my opinion) within the scope for the SCSI Update portion of this project. Yes, it should be included in the charter (either specifically, or by making clear the broader interpretation of the "update"). There is no person advocating these ASC/Q codes. These are ALREADY APPROVED ASC/Q codes, and the person that caused them to become approved is no longer part of T10, nor is that company a part of T10 at this time, so it will be hard to find them and get them to do anything. In my opinion, we should define their use, and let the e-mail reviews make sure we get it right (or as good as we can). Partly because, contrary to the statement below, the causes of all unit attention conditions are not "clearly defined". Fred Knight -----Original Message----- From: Paul Koning [mailto:Paul_Koning@dell.com]=20 Sent: Tuesday, March 31, 2009 2:57 PM To: Black_David@emc.com Cc: ips@ietf.org Subject: Re: [Ips] iSCSI-specific unit attention conditions >>>>> "Black" =3D=3D Black David writes: Black> Here's another piece of "housekeeping" for the new STORM Black> WG-to-be - I've been informed by a knowledgeable T10 Black> participant that: >> T10 proposal 05-406 (from Bill Galloway, Pivot3) added 3 >> iSCSI-specific unit attention condition additional sense codes in >> SPC-4: - 3Fh/12h iSCSI IP ADDRESS ADDED - 3Fh/13h iSCSI IP ADDRESS >> REMOVED - 3Fh/14h iSCSI IP ADDRESS CHANGED >>=20 >> r0 used a more generic "DEVICE PORT ADDRESS" phrase, but r1 >> changed that to "iSCSI IP ADDRESS" upon recommendation by the >> [T10] CAP WG. >>=20 >> However, there is no mention in any standard of when these are >> used (unlike all the other unit attention conditions, whose causes >> are clearly defined). With the accepted names, that belongs in >> iSCSI itself. =20 Black> FWIW, these ASC/Q value pairs appear to have been added to Black> SPC-4 without any cross-checking with the IETF, which would Black> serve to explain why there is no documentation anywhere about Black> when or how to use them. Since these ASC/Qs are Black> iSCSI-specific, that task falls to the iSCSI specification(s), Black> unless these ASC/Qs are removed or have their names changed to Black> no longer be iSCSI-specific. Black> Hence: - the "new features" STORM draft should explain how to Black> use these ASC/Qs --- AND/OR --- - discussion here and in the Black> to-be-formed storm WG should generate a proposal to T10 about Black> what should change and why. I would suggest the following. 1. The person advocating these ASC/Q codes should propose a new work item for STORM to add this new feature. It first needs to be added to the charter, then a new I-D needs to be generated to describe it. It doesn't belong in the other work items because it's neither cleanup nor (as far as I can tell) SAM-4 support. 2. If #1 isn't done or the proposal doesn't receive WG consensus, STORM should generate a liaison request to T10 asking for these ASC/Q codes to be removed, or deprecated, or otherwise relabeled=20 to make it clear that they are not defined by the iSCSI standard. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From dcuddihy@attotech.com Wed Apr 1 08:41:15 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6966A3A67F4 for ; Wed, 1 Apr 2009 08:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-J24Hd3muop for ; Wed, 1 Apr 2009 08:41:14 -0700 (PDT) Received: from NOTESERV1.attotech.com (noteserv1.attotech.com [208.69.85.41]) by core3.amsl.com (Postfix) with ESMTP id BD74F3A63EB for ; Wed, 1 Apr 2009 08:41:13 -0700 (PDT) In-Reply-To: To: "Knight, Frederick" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: dcuddihy@attotech.com Date: Wed, 1 Apr 2009 11:42:12 -0400 X-MIMETrack: Serialize by Router on NOTESERV1/SERV/ATTO(Release 7.0.3FP1|February 24, 2008) at 04/01/2009 11:42:14 AM, Serialize complete at 04/01/2009 11:42:14 AM Content-Type: multipart/alternative; boundary="=_alternative 005642F08525758B_=" Cc: ips@ietf.org Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 15:41:15 -0000 This is a multipart message in MIME format. --=_alternative 005642F08525758B_= Content-Type: text/plain; charset="US-ASCII" It seems to me that the more important question is how useful these unit attention codes are. (For example, ATTO's Xtend San initiator doesn't make use of them.) If initiators don't care about this information, precisely defining these unit attention codes (instead of depricating them) will be a change for the worse. regards, david For every action there is an equal and opposite malfunction... David J Cuddihy Principal Engineer ATTO Technology, Inc. (716) 691-1999 x157 www.attotech.com Power Behind the Storage "Knight, Frederick" Sent by: ips-bounces@ietf.org 03/31/2009 05:39 PM To , cc ips@ietf.org, Black_David@emc.com Subject Re: [Ips] iSCSI-specific unit attention conditions "No commands are affected." The command which receives this response is NOT executed, and must be reissued by the initiator. True, no command other than the one that receives this response is affected. My guess from reading 05-406 is that the target is simply telling the initiator that it is time to reissue a SendTargets (redo discovery). My guess is that all 3 ASC/Qs would be handled by the host in the same way - something change (ala RSCN), so go find out what. I can't tell from the proposal why there needs to be 3 different reports (add/remove/change); it seems that "change" is really all that might be needed. So, it's possible my guess about the original intent is missing something. Fred -----Original Message----- From: brown_David1@emc.com [mailto:brown_David1@emc.com] Sent: Tuesday, March 31, 2009 4:12 PM To: Paul_Koning@dell.com; Knight, Frederick Cc: ips@ietf.org; Black_David@emc.com Subject: RE: [Ips] iSCSI-specific unit attention conditions Maybe this is obvious to the T10 folks in the audience, but . . . Since these unit attentions use an ASC of 3F, they indicate a change to the operating state of the device. No commands are affected. From the concise wording of the 05-406 proposal, it's hard to be sure what the author intended, but it sounds to me like the target is telling the initiator about a change in the membership of the portal group. Might be caused by a configuration change, possibly by hot-plugging another network interface card into the target system. DJ Brown -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Paul Koning Sent: Tuesday, March 31, 2009 3:32 PM To: Frederick.Knight@netapp.com Cc: ips@ietf.org; Black, David Subject: Re: [Ips] iSCSI-specific unit attention conditions >>>>> "Frederick" == Frederick Knight writes: Frederick> My interpretation of the "update" part of the agenda was Frederick> that SAM-4 was an example (and that we should also include Frederick> SAM-3 and SAM-5 as part of the update list). Therefore, Frederick> to add SPC to the update list is (in my opinion) within Frederick> the scope for the SCSI Update portion of this project. Frederick> Yes, it should be included in the charter (either Frederick> specifically, or by making clear the broader Frederick> interpretation of the "update"). Ok, that sounds good. Frederick> There is no person advocating these ASC/Q codes. These Frederick> are ALREADY APPROVED ASC/Q codes, and the person that Frederick> caused them to become approved is no longer part of T10, Frederick> nor is that company a part of T10 at this time, so it will Frederick> be hard to find them and get them to do anything. Frederick> In my opinion, we should define their use, and let the Frederick> e-mail reviews make sure we get it right (or as good as we Frederick> can). Partly because, contrary to the statement below, Frederick> the causes of all unit attention conditions are not Frederick> "clearly defined". I was assuming the person doing the advocating would be the appropriate one to do the defining. If that person isn't around but someone else wants to do the defining, that is fine, too. Part of what bothers me is that I can't fathom what these codes are intended for, or what the scenarios are when they might be generated, or what conclusion an initiator is supposed to draw when it sees one. The names vaguely suggest that they have something to do with asynchronous logout, but that is already fully covered in the iSCSI spec. Itdoesn't require any unit attentions in the first place, certainly not any iSCSI specific ones. I would rather see these things go away, unless there is a good argument made that there is something missing in iSCSI that needs to be added, and these codes are part of the solution. The fact that T10 already approved them isn't a reason to add them to iSCSI. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --=_alternative 005642F08525758B_= Content-Type: text/html; charset="US-ASCII"
It seems to me that the more important question is how useful these unit attention codes are.  (For example, ATTO's Xtend San initiator doesn't make use of them.)  If initiators don't care about this information, precisely defining these unit attention codes (instead of depricating them) will be a change for the worse.

regards,

david


For every action there is an equal and opposite malfunction...

David J Cuddihy
Principal Engineer
ATTO Technology, Inc.
(716) 691-1999 x157

www.attotech.com
Power Behind the Storage


"Knight, Frederick" <Frederick.Knight@netapp.com>
Sent by: ips-bounces@ietf.org

03/31/2009 05:39 PM

To
<brown_David1@emc.com>, <Paul_Koning@dell.com>
cc
ips@ietf.org, Black_David@emc.com
Subject
Re: [Ips] iSCSI-specific unit attention conditions





"No commands are affected."

The command which receives this response is NOT executed, and must be
reissued by the initiator.  True, no command other than the one that
receives this response is affected.

My guess from reading 05-406 is that the target is simply telling the
initiator that it is time to reissue a SendTargets (redo discovery).  My
guess is that all 3 ASC/Qs would be handled by the host in the same way
- something change (ala RSCN), so go find out what.  I can't tell from
the proposal why there needs to be 3 different reports
(add/remove/change); it seems that "change" is really all that might be
needed.  So, it's possible my guess about the original intent is missing
something.

                Fred

-----Original Message-----
From: brown_David1@emc.com [mailto:brown_David1@emc.com]
Sent: Tuesday, March 31, 2009 4:12 PM
To: Paul_Koning@dell.com; Knight, Frederick
Cc: ips@ietf.org; Black_David@emc.com
Subject: RE: [Ips] iSCSI-specific unit attention conditions

Maybe this is obvious to the T10 folks in the audience, but . . . Since
these unit attentions use an ASC of 3F, they indicate a change to the
operating state of the device.  No commands are affected.  From the
concise wording of the 05-406 proposal, it's hard to be sure what the
author intended, but it sounds to me like the target is telling the
initiator about a change in the membership of the portal group.

Might be caused by a configuration change, possibly by hot-plugging
another network interface card into the target system.

DJ Brown

-----Original Message-----
From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of
Paul Koning
Sent: Tuesday, March 31, 2009 3:32 PM
To: Frederick.Knight@netapp.com
Cc: ips@ietf.org; Black, David
Subject: Re: [Ips] iSCSI-specific unit attention conditions

>>>>> "Frederick" == Frederick Knight <Knight> writes:

Frederick> My interpretation of the "update" part of the agenda was
Frederick> that SAM-4 was an example (and that we should also include
Frederick> SAM-3 and SAM-5 as part of the update list).  Therefore,
Frederick> to add SPC to the update list is (in my opinion) within
Frederick> the scope for the SCSI Update portion of this project.

Frederick> Yes, it should be included in the charter (either
Frederick> specifically, or by making clear the broader  Frederick>
interpretation of the "update").

Ok, that sounds good.

Frederick> There is no person advocating these ASC/Q codes.  These
Frederick> are ALREADY APPROVED ASC/Q codes, and the person that
Frederick> caused them to become approved is no longer part of T10,
Frederick> nor is that company a part of T10 at this time, so it will
Frederick> be hard to find them and get them to do anything.

Frederick> In my opinion, we should define their use, and let the
Frederick> e-mail reviews make sure we get it right (or as good as we
Frederick> can).  Partly because, contrary to the statement below,
Frederick> the causes of all unit attention conditions are not
Frederick> "clearly defined".

I was assuming the person doing the advocating would be the appropriate
one to do the defining.  If that person isn't around but someone else
wants to do the defining, that is fine, too.

Part of what bothers me is that I can't fathom what these codes are
intended for, or what the scenarios are when they might be generated, or
what conclusion an initiator is supposed to draw when it sees one.

The names vaguely suggest that they have something to do with
asynchronous logout, but that is already fully covered in the iSCSI
spec.  Itdoesn't require any unit attentions in the first place,
certainly not any iSCSI specific ones.

I would rather see these things go away, unless there is a good argument
made that there is something missing in iSCSI that needs to be added,
and these codes are part of the solution.  The fact that T10 already
approved them isn't a reason to add them to iSCSI.

                paul

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www.ietf.org/mailman/listinfo/ips
--=_alternative 005642F08525758B_=-- From Paul_Koning@Dell.com Wed Apr 1 08:50:17 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA9523A67F7 for ; Wed, 1 Apr 2009 08:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.024 X-Spam-Level: X-Spam-Status: No, score=-104.024 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_RELAY=2.696, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLkJcV7benOP for ; Wed, 1 Apr 2009 08:50:16 -0700 (PDT) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id AE03D3A63EB for ; Wed, 1 Apr 2009 08:50:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235973600"; d="scan'208";a="393035242" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 01 Apr 2009 10:51:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18899.36208.525150.683459@pkoning-laptop.equallogic.com> Date: Wed, 1 Apr 2009 11:51:12 -0400 From: Paul Koning To: dcuddihy@attotech.com References: X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-OriginalArrivalTime: 01 Apr 2009 15:51:15.0308 (UTC) FILETIME=[B05D9AC0:01C9B2E1] Cc: ips@ietf.org, Frederick.Knight@netapp.com Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 15:50:18 -0000 >>>>> "dcuddihy" == dcuddihy writes: dcuddihy> It seems to me that the more important question is how dcuddihy> useful these unit attention codes are. (For example, dcuddihy> ATTO's Xtend San initiator doesn't make use of them.) If dcuddihy> initiators don't care about this information, precisely dcuddihy> defining these unit attention codes (instead of depricating dcuddihy> them) will be a change for the worse. That's one of my concerns. It seems we're just speculating what purpose these codes were intended to serve. Not only don't we know for sure what that purpose was, we also don't know if that purpose is actually achieved. The other concern is that these codes could be interpreted to impose a new requirement on targets to generate them in certain situations. Of course we don't know what those situations are, or why targets should do this, but clearly someone could argue that those numbers exist and therefore are supposed to be generated. Unless there is a solid proposal that assigns a clear meaning, and that meaning is valuable to initiators, I believe that the only correct answer is to consider what happened as a glitch in the standards process and remove, to the extent possible, the debris left behind by that glitch. I don't see anything in the recent discussion that gets us to this clear meaning and useful purpose. In particular, I see absolutely NO trace of "rough consensus and running code" to support the notion that the iSCSI standard should support these new codes. David, can we put in motion the deprecation of these codes? paul From Frederick.Knight@netapp.com Wed Apr 1 09:23:13 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E91D3A681C for ; Wed, 1 Apr 2009 09:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yA1AA1oT-zt for ; Wed, 1 Apr 2009 09:23:12 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 68E5F3A6C82 for ; Wed, 1 Apr 2009 09:23:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235980800"; d="scan'208";a="148787784" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 01 Apr 2009 09:24:13 -0700 Received: from sacrsexc1-prd.hq.netapp.com (sacrsexc1-prd.hq.netapp.com [10.99.115.27]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id n31GOCZC007749; Wed, 1 Apr 2009 09:24:12 -0700 (PDT) Received: from rtprsexc2-prd.hq.netapp.com ([10.100.161.115]) by sacrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 09:24:12 -0700 Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 12:24:10 -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: Wed, 1 Apr 2009 12:23:22 -0400 Message-ID: In-Reply-To: <18899.36208.525150.683459@pkoning-laptop.equallogic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] iSCSI-specific unit attention conditions Thread-Index: Acmy4bP4cvpmWgG5S1GjUaf5wa5pJwAAfJEA From: "Knight, Frederick" To: "Paul Koning" , X-OriginalArrivalTime: 01 Apr 2009 16:24:10.0465 (UTC) FILETIME=[49A6A510:01C9B2E6] Cc: ips@ietf.org Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:23:13 -0000 I've tracked down the people involved in the original 2005 T10 proposal, and I will try to get them involved (if I can't, I'll at least share what I discover). T10 will be reluctant to retire these values if they are in use.=20 As mentioned, the use we see for the "ADDRESS CHANGED" event is to cause a new discovery process to be initiated (to go find any changes). Fred -----Original Message----- From: Paul Koning [mailto:Paul_Koning@Dell.com]=20 Sent: Wednesday, April 01, 2009 11:51 AM To: dcuddihy@attotech.com Cc: Knight, Frederick; ips@ietf.org Subject: Re: [Ips] iSCSI-specific unit attention conditions >>>>> "dcuddihy" =3D=3D dcuddihy writes: dcuddihy> It seems to me that the more important question is how dcuddihy> useful these unit attention codes are. (For example, dcuddihy> ATTO's Xtend San initiator doesn't make use of them.) If dcuddihy> initiators don't care about this information, precisely dcuddihy> defining these unit attention codes (instead of depricating dcuddihy> them) will be a change for the worse. That's one of my concerns. It seems we're just speculating what purpose these codes were intended to serve. Not only don't we know for sure what that purpose was, we also don't know if that purpose is actually achieved. The other concern is that these codes could be interpreted to impose a new requirement on targets to generate them in certain situations. Of course we don't know what those situations are, or why targets should do this, but clearly someone could argue that those numbers exist and therefore are supposed to be generated. Unless there is a solid proposal that assigns a clear meaning, and that meaning is valuable to initiators, I believe that the only correct answer is to consider what happened as a glitch in the standards process and remove, to the extent possible, the debris left behind by that glitch. I don't see anything in the recent discussion that gets us to this clear meaning and useful purpose. In particular, I see absolutely NO trace of "rough consensus and running code" to support the notion that the iSCSI standard should support these new codes. David, can we put in motion the deprecation of these codes? paul From Kevin_Marks@Dell.com Fri Apr 3 19:09:15 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40D43A6A90 for ; Fri, 3 Apr 2009 19:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWgGvBXxIy+W for ; Fri, 3 Apr 2009 19:09:15 -0700 (PDT) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by core3.amsl.com (Postfix) with ESMTP id DAD1A3A6A6D for ; Fri, 3 Apr 2009 19:09:14 -0700 (PDT) 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, 3 Apr 2009 21:05:27 -0500 Message-ID: <1345AC4A6B8AB74BB5211396D84C746D01ADD77B@ausx3mpc109.aus.amer.dell.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] iSCSI-specific unit attention conditions Thread-Index: Acmy4bP4cvpmWgG5S1GjUaf5wa5pJwAAfJEAAHl4VdA= References: <18899.36208.525150.683459@pkoning-laptop.equallogic.com> From: To: , , X-OriginalArrivalTime: 04 Apr 2009 02:10:16.0609 (UTC) FILETIME=[7F21E110:01C9B4CA] Cc: ips@ietf.org Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 02:09:15 -0000 Fred,=20 Whether in use or not, in my ten years of doing T10, I have never seen an ASC/Q go obsolete. Kevin -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Knight, Frederick Sent: Wednesday, April 01, 2009 11:23 AM To: Koning, Paul; dcuddihy@attotech.com Cc: ips@ietf.org Subject: Re: [Ips] iSCSI-specific unit attention conditions I've tracked down the people involved in the original 2005 T10 proposal, and I will try to get them involved (if I can't, I'll at least share what I discover). T10 will be reluctant to retire these values if they are in use.=20 As mentioned, the use we see for the "ADDRESS CHANGED" event is to cause a new discovery process to be initiated (to go find any changes). Fred -----Original Message----- From: Paul Koning [mailto:Paul_Koning@Dell.com]=20 Sent: Wednesday, April 01, 2009 11:51 AM To: dcuddihy@attotech.com Cc: Knight, Frederick; ips@ietf.org Subject: Re: [Ips] iSCSI-specific unit attention conditions >>>>> "dcuddihy" =3D=3D dcuddihy writes: dcuddihy> It seems to me that the more important question is how dcuddihy> useful these unit attention codes are. (For example, dcuddihy> ATTO's Xtend San initiator doesn't make use of them.) If dcuddihy> initiators don't care about this information, precisely dcuddihy> defining these unit attention codes (instead of depricating dcuddihy> them) will be a change for the worse. That's one of my concerns. It seems we're just speculating what purpose these codes were intended to serve. Not only don't we know for sure what that purpose was, we also don't know if that purpose is actually achieved. The other concern is that these codes could be interpreted to impose a new requirement on targets to generate them in certain situations. Of course we don't know what those situations are, or why targets should do this, but clearly someone could argue that those numbers exist and therefore are supposed to be generated. Unless there is a solid proposal that assigns a clear meaning, and that meaning is valuable to initiators, I believe that the only correct answer is to consider what happened as a glitch in the standards process and remove, to the extent possible, the debris left behind by that glitch. I don't see anything in the recent discussion that gets us to this clear meaning and useful purpose. In particular, I see absolutely NO trace of "rough consensus and running code" to support the notion that the iSCSI standard should support these new codes. David, can we put in motion the deprecation of these codes? paul _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From Black_David@emc.com Fri Apr 3 20:18:44 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7ADD3A6869 for ; Fri, 3 Apr 2009 20:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrXXnoKvibCK for ; Fri, 3 Apr 2009 20:18:43 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 7DA733A6805 for ; Fri, 3 Apr 2009 20:18:43 -0700 (PDT) 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 n343Jgn9011060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 23:19:43 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Fri, 3 Apr 2009 23:19:28 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n343JR0X004479; Fri, 3 Apr 2009 23:19:27 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 23:19:27 -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: Fri, 3 Apr 2009 23:19:26 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A024FF25F@CORPUSMX80A.corp.emc.com> In-reply-to: <1345AC4A6B8AB74BB5211396D84C746D01ADD77B@ausx3mpc109.aus.amer.dell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] iSCSI-specific unit attention conditions Thread-Index: Acmy4bP4cvpmWgG5S1GjUaf5wa5pJwAAfJEAAHl4VdAAAmH+cA== References: <18899.36208.525150.683459@pkoning-laptop.equallogic.com> <1345AC4A6B8AB74BB5211396D84C746D01ADD77B@ausx3mpc109.aus.amer.dell.com> To: X-OriginalArrivalTime: 04 Apr 2009 03:19:27.0546 (UTC) FILETIME=[294899A0:01C9B4D4] X-EMM-EM: Active Cc: ips@ietf.org Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 03:18:44 -0000 If retirement is in order, renaming the to-be-retired codes as vendor-specific to protect their existing usage may suffice. I believe the original proposer of these codes will be sending a message to this list to explain what the codes were intended for and why. 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: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On=20 > Behalf Of Kevin_Marks@Dell.com > Sent: Friday, April 03, 2009 10:05 PM > To: Frederick.Knight@netapp.com; Paul_Koning@Dell.com;=20 > dcuddihy@attotech.com > Cc: ips@ietf.org > Subject: Re: [Ips] iSCSI-specific unit attention conditions >=20 > Fred,=20 >=20 > Whether in use or not, in my ten years of doing T10, I have > never seen an ASC/Q go obsolete. >=20 > Kevin >=20 >=20 > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of > Knight, Frederick > Sent: Wednesday, April 01, 2009 11:23 AM > To: Koning, Paul; dcuddihy@attotech.com > Cc: ips@ietf.org > Subject: Re: [Ips] iSCSI-specific unit attention conditions >=20 > I've tracked down the people involved in the original 2005=20 > T10 proposal, > and I will try to get them involved (if I can't, I'll at least share > what I discover). >=20 > T10 will be reluctant to retire these values if they are in use.=20 >=20 > As mentioned, the use we see for the "ADDRESS CHANGED" event=20 > is to cause > a new discovery process to be initiated (to go find any changes). >=20 > Fred >=20 > -----Original Message----- > From: Paul Koning [mailto:Paul_Koning@Dell.com]=20 > Sent: Wednesday, April 01, 2009 11:51 AM > To: dcuddihy@attotech.com > Cc: Knight, Frederick; ips@ietf.org > Subject: Re: [Ips] iSCSI-specific unit attention conditions >=20 > >>>>> "dcuddihy" =3D=3D dcuddihy writes: >=20 > dcuddihy> It seems to me that the more important question is how > dcuddihy> useful these unit attention codes are. (For example, > dcuddihy> ATTO's Xtend San initiator doesn't make use of them.) If > dcuddihy> initiators don't care about this information, precisely > dcuddihy> defining these unit attention codes (instead of depricating > dcuddihy> them) will be a change for the worse. >=20 > That's one of my concerns. >=20 > It seems we're just speculating what purpose these codes were intended > to serve. Not only don't we know for sure what that purpose was, we > also don't know if that purpose is actually achieved. >=20 > The other concern is that these codes could be interpreted to impose a > new requirement on targets to generate them in certain situations. Of > course we don't know what those situations are, or why targets should > do this, but clearly someone could argue that those numbers exist and > therefore are supposed to be generated. >=20 > Unless there is a solid proposal that assigns a clear meaning, and > that meaning is valuable to initiators, I believe that the only > correct answer is to consider what happened as a glitch in the > standards process and remove, to the extent possible, the debris left > behind by that glitch. >=20 > I don't see anything in the recent discussion that gets us to this > clear meaning and useful purpose. In particular, I see absolutely NO > trace of "rough consensus and running code" to support the notion that > the iSCSI standard should support these new codes. >=20 > David, can we put in motion the deprecation of these codes? >=20 > paul >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www.ietf.org/mailman/listinfo/ips > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www.ietf.org/mailman/listinfo/ips >=20 >=20 From BillG@breatech.com Fri Apr 3 23:28:51 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1114C3A67AA for ; Fri, 3 Apr 2009 23:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifdYSosTN3r3 for ; Fri, 3 Apr 2009 23:28:50 -0700 (PDT) Received: from outbound-mail-144.bluehost.com (outbound-mail-144.bluehost.com [67.222.38.34]) by core3.amsl.com (Postfix) with SMTP id BF3343A68D9 for ; Fri, 3 Apr 2009 23:28:02 -0700 (PDT) Received: (qmail 22657 invoked by uid 0); 4 Apr 2009 06:25:26 -0000 Received: from unknown (HELO host164.hostmonster.com) (74.220.207.164) by outboundproxy5.bluehost.com with SMTP; 4 Apr 2009 06:25:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=breatech.com; h=Received:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=G3ImgMMhTI4zWqtuje6oJtPB/b9TJDMK59EXxaENnLuoTiwi1gZEecbr7SSSbRIh1xeJSSfg9zjg16Ex75YnCBtoTL0OQW9BJHIfxPTZ64U0FCgAA91UNB24XMMdOel3; Received: from 66-101-59-48-static.dsl.oplink.net ([66.101.59.48] helo=billgsv4) by host164.hostmonster.com with esmtpa (Exim 4.69) (envelope-from ) id 1LpzNK-0000FW-04 for ips@ietf.org; Sat, 04 Apr 2009 00:29:06 -0600 From: "Bill Galloway" To: References: <18899.36208.525150.683459@pkoning-laptop.equallogic.com> <948E73819E6E494394157AD8A890E8774E3A3054@saturn.p3corpnet.pivot3.com> <948E73819E6E494394157AD8A890E877405C31C1@saturn.p3corpnet.pivot3.com> In-Reply-To: Date: Sat, 4 Apr 2009 01:29:03 -0500 Message-ID: <000001c9b4ee$a73e3da0$f5bab8e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmy4bP4cvpmWgG5S1GjUaf5wa5pJwAAfJEAAAxGCiAAX7zz0AAWpM4wAAAS9lA= Content-Language: en-us X-Identified-User: {2089:host164.hostmonster.com:thegallo:breatech.com} {sentby:smtp auth 66.101.59.48 authed with billg+breatech.com} X-Mailman-Approved-At: Sat, 04 Apr 2009 10:38:03 -0700 Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: BillG@breatech.com List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 06:30:38 -0000 This is a re-send from a different email.... I am the guilty party associated with these sense codes. I have been traveling for the last few days or I would have chimed in sooner. My original proposal was not iSCSI specific. It added three ASC/ASCQs which were DEVICE PORT ADDRESS ADDED/CHANGED/REMOVED. The original names actually explain the intent better (IMHO). We produce an iSCSI target with many "Portal Groups" and "Network Portals". Portal Groups come and go dynamically. Within a Portal Group, Network Portals come, go, or change dynamically. The intent is for the initiator to be connected to all Network Portals, on all Portal Groups, all of the time. This is usually accomplished with some combination of MCS in the initiator and a MPIO (multipath) layer above the initiator. The initiator is perfectly willing to make all of these connections but there is no way specified in any standard to accomplish this task. There is a mix of layers here that makes for a messy solution. I am certainly open to a better one. The SCSI layer could care less about Network Portals coming, going, or changing but something has to kick the initiator to do a new discovery and make the appropriate connections. This would have been better handled at the iSCSI layer but I could find nothing available. In our implementation the MPIO layer traps these UAs and kicks the initiator. The SCSI layer does have a legitimate need to know about Portal Groups coming and going. These map to SAM target ports and the SCSI layer may need to know. The initiator also needs to know so that it can make the new connections. In our implementation the MPIO layer also traps these UAs and kicks the initiator. Why three codes? No good reason. My first proposal was more generic than iSCSI and there was a hope that it would be useful to other protocols. To get the proposal passed, I agreed to change the names to be iSCSI specific. In retrospect when I made the name change, I could have dropped it to one code. In our current implementation we treat all codes the same. I hope this explains the rational for these ASC/ASCQs. I am not aware of anything in the iSCSI spec that accomplishes these goals. I am certainly willing to explain further and to work with STORM to document this better and/or come up with a better solution. Bill Galloway Pivot3, Inc. BillG[-at-]Pivot3.com From Julian_Satran@il.ibm.com Sat Apr 4 11:15:34 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E953A6A6D; Sat, 4 Apr 2009 11:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.44 X-Spam-Level: X-Spam-Status: No, score=-5.44 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sCCyM7OjRBC; Sat, 4 Apr 2009 11:15:32 -0700 (PDT) Received: from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.17.161]) by core3.amsl.com (Postfix) with ESMTP id 484DD3A6A06; Sat, 4 Apr 2009 11:15:31 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id n34IGVtI010369; Sat, 4 Apr 2009 18:16:31 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n34IGVi83076342; Sat, 4 Apr 2009 20:16:31 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n34IGVkL013433; Sat, 4 Apr 2009 20:16:31 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n34IGVqP013430; Sat, 4 Apr 2009 20:16:31 +0200 In-Reply-To: <000001c9b4ee$a73e3da0$f5bab8e0$@com> References: <18899.36208.525150.683459@pkoning-laptop.equallogic.com> <948E73819E6E494394157AD8A890E8774E3A3054@saturn.p3corpnet.pivot3.com> <948E73819E6E494394157AD8A890E877405C31C1@saturn.p3corpnet.pivot3.com> <000001c9b4ee$a73e3da0$f5bab8e0$@com> To: BillG@breatech.com MIME-Version: 1.0 X-KeepSent: 02E6844A:960EF36C-C225758E:0062068D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Julian Satran Message-ID: Date: Sat, 4 Apr 2009 21:16:29 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0.1|February 07, 2008) at 04/04/2009 21:16:30, Serialize complete at 04/04/2009 21:16:30 Content-Type: multipart/alternative; boundary="=_alternative 0064605FC225758E_=" Cc: ips@ietf.org, ips-bounces@ietf.org Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 18:15:34 -0000 This is a multipart message in MIME format. --=_alternative 0064605FC225758E_= Content-Type: text/plain; charset="US-ASCII" ips-bounces@ietf.org wrote on 04/04/2009 09:29:03: > From: > > "Bill Galloway" > > To: > > > > Date: > > 04/04/2009 20:39 > > Subject: > > Re: [Ips] iSCSI-specific unit attention conditions > > Sent by: > > ips-bounces@ietf.org > > This is a re-send from a different email.... > > I am the guilty party associated with these sense codes. I have been > traveling for the last few days or I would have chimed in sooner. My > original proposal was not iSCSI specific. It added three ASC/ASCQs which > were DEVICE PORT ADDRESS ADDED/CHANGED/REMOVED. The original names actually > explain the intent better (IMHO). > > We produce an iSCSI target with many "Portal Groups" and "Network Portals". > Portal Groups come and go dynamically. Within a Portal Group, Network > Portals come, go, or change dynamically. The intent is for the initiator to > be connected to all Network Portals, on all Portal Groups, all of the time. > This is usually accomplished with some combination of MCS in the initiator > and a MPIO (multipath) layer above the initiator. The initiator is > perfectly willing to make all of these connections but there is no way > specified in any standard to accomplish this task. There is a mix of layers > here that makes for a messy solution. I am certainly open to a better one. > > The SCSI layer could care less about Network Portals coming, going, or > changing but something has to kick the initiator to do a new discovery and > make the appropriate connections. This would have been better handled at > the iSCSI layer but I could find nothing available. In our implementation > the MPIO layer traps these UAs and kicks the initiator. > > The SCSI layer does have a legitimate need to know about Portal Groups > coming and going. These map to SAM target ports and the SCSI layer may need > to know. The initiator also needs to know so that it can make the new > connections. In our implementation the MPIO layer also traps these UAs and > kicks the initiator. > > Why three codes? No good reason. My first proposal was more generic than > iSCSI and there was a hope that it would be useful to other protocols. To > get the proposal passed, I agreed to change the names to be iSCSI specific. > In retrospect when I made the name change, I could have dropped it to one > code. In our current implementation we treat all codes the same. > > I hope this explains the rational for these ASC/ASCQs. I am not aware of > anything in the iSCSI spec that accomplishes these goals. I am certainly > willing to explain further and to work with STORM to document this better > and/or come up with a better solution. > > Bill Galloway > Pivot3, Inc. > BillG[-at-]Pivot3.com > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www.ietf.org/mailman/listinfo/ips The first reaction to your note would be probably that you are right - SCSI is probably the wrong layer to make initiators aware of the existence of a new port. On the other hand any transport than has no "permanent session" (in a generic sense) would have a hard time handling it. And even worse - if the target is connected through different transport to the same or different initiators which one of the transports should carry it (think only about a FCP target that has an iSCSI backup - a not entirely imaginary scenario)? And the ugly part about doing it with UA is that you kick in a recovery process that might be non-trivial. The cleanest solution (for iSCSI) is to relegate the discovery (and change) to an out of band mechanism (as I have advocated for a long time). The drawback is that all the available out-of-band mechanisms are heavy and quite expensive (this is not to be considered a critique - it is just a statement of fact). Alternatively we could choose to handle the iSCSI case exclusively and use a version of one of our messages to convey the change. It will not handle all the cases (as the above FCP - iSCSI mix) but will perhaps solve Bill's problem. Alternatively we might try and persuade T10 (SCSI) do adopt an "in-band" mechanism to prompt (re) discovery that should not carry the UA weight in most of the cases and then make the codes obsolete if the cease to be useful and/or extend them to other transports. The last alternative is to mandate that configuration changes of this type can be made only outside a session - that will require us to use only a change bit from session to session (or login key) to indicate a change or unknown state since last discovery. Julo Julo --=_alternative 0064605FC225758E_= Content-Type: text/html; charset="US-ASCII"
ips-bounces@ietf.org wrote on 04/04/2009 09:29:03:

> From:
>
> "Bill Galloway" <BillG@breatech.com>
>
> To:
>
> <ips@ietf.org>
>
> Date:
>
> 04/04/2009 20:39
>
> Subject:
>
> Re: [Ips] iSCSI-specific unit attention conditions
>
> Sent by:
>
> ips-bounces@ietf.org
>
> This is a re-send from a different email....
>
> I am the guilty party associated with these sense codes.  I have been
> traveling for the last few days or I would have chimed in sooner.  My
> original proposal was not iSCSI specific.  It added three ASC/ASCQs which
> were DEVICE PORT ADDRESS ADDED/CHANGED/REMOVED. The original names actually
> explain the intent better (IMHO).
>
> We produce an iSCSI target with many "Portal Groups" and "Network Portals".
> Portal Groups come and go dynamically. Within a Portal Group, Network
> Portals come, go, or change dynamically.  The intent is for the initiator to
> be connected to all Network Portals, on all Portal Groups, all of the time.
> This is usually accomplished with some combination of MCS in the initiator
> and a MPIO (multipath) layer above the initiator.  The initiator is
> perfectly willing to make all of these connections but there is no way
> specified in any standard to accomplish this task.  There is a mix of layers
> here that makes for a messy solution.  I am certainly open to a better one.
>
> The SCSI layer could care less about Network Portals coming, going, or
> changing but something has to kick the initiator to do a new discovery and
> make the appropriate connections.  This would have been better handled at
> the iSCSI layer but I could find nothing available.  In our implementation
> the MPIO layer traps these UAs and kicks the initiator.
>
> The SCSI layer does have a legitimate need to know about Portal Groups
> coming and going.  These map to SAM target ports and the SCSI layer may need
> to know. The initiator also needs to know so that it can make the new
> connections.  In our implementation the MPIO layer also traps these UAs and
> kicks the initiator.
>
> Why three codes? No good reason.  My first proposal was more generic than
> iSCSI and there was a hope that it would be useful to other protocols.  To
> get the proposal passed, I agreed to change the names to be iSCSI specific.
> In retrospect when I made the name change, I could have dropped it to one
> code.  In our current implementation we treat all codes the same.
>
> I hope this explains the rational for these ASC/ASCQs.  I am not aware of
> anything in the iSCSI spec that accomplishes these goals. I am certainly
> willing to explain further and to work with STORM to document this better
> and/or come up with a better solution.
>
> Bill Galloway
> Pivot3, Inc.
> BillG[-at-]Pivot3.com
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www.ietf.org/mailman/listinfo/ips
The first reaction to your note would be probably that you are right - SCSI is probably the wrong layer to make initiators aware of the existence of a new port.
On the other hand any transport than has no "permanent session" (in a generic sense) would have a hard time handling it.
And even worse - if the target is connected through different transport to the same or different initiators which one of the transports should carry it (think only about a FCP target that has an iSCSI backup - a not entirely imaginary scenario)?

And the ugly part about doing it with UA is that you kick in a recovery process that might be non-trivial.

The cleanest solution (for iSCSI) is to relegate the discovery (and change) to an out of band mechanism (as I have advocated for a long time). The drawback is that all the available out-of-band mechanisms are heavy and quite expensive (this is not to be considered a critique - it is just a statement of fact). Alternatively we could choose to handle the iSCSI case exclusively and use a version of one of our messages to convey the change. It will not handle all the cases (as the above FCP - iSCSI mix) but will perhaps solve Bill's problem.

Alternatively we might try and persuade T10 (SCSI) do adopt an "in-band" mechanism to prompt (re) discovery that should not carry the UA weight in most of the cases and then make the codes obsolete if the cease to be useful and/or extend them to other transports.

The last alternative is to mandate that configuration changes of this type can be made only outside a session - that will require us to use only a change bit from session to session (or login key) to indicate a change or unknown state since last discovery.

Julo

Julo

--=_alternative 0064605FC225758E_=-- From roweber@sempai.org Sat Apr 4 15:24:20 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2C723A6986 for ; Sat, 4 Apr 2009 15:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6RaBJ1lM4UY for ; Sat, 4 Apr 2009 15:24:20 -0700 (PDT) Received: from sempai.org (greenwood.sempai.org [72.249.129.2]) by core3.amsl.com (Postfix) with ESMTP id DE2723A6964 for ; Sat, 4 Apr 2009 15:24:19 -0700 (PDT) Received: from 151.sub-70-194-35.myvzw.com ([70.194.35.151] helo=[127.0.0.1]) by sempai.org with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LqEIj-0001rP-M8 for ips@ietf.org; Sat, 04 Apr 2009 17:25:23 -0500 Message-ID: <49D7DE49.4060507@ieee.org> Date: Sat, 04 Apr 2009 17:25:13 -0500 From: Ralph Weber User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ips@ietf.org References: <18899.36208.525150.683459@pkoning-laptop.equallogic.com> <1345AC4A6B8AB74BB5211396D84C746D01ADD77B@ausx3mpc109.aus.amer.dell.com> In-Reply-To: <1345AC4A6B8AB74BB5211396D84C746D01ADD77B@ausx3mpc109.aus.amer.dell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: roweber@sempai.org X-SA-Exim-Connect-IP: 70.194.35.151 X-SA-Exim-Mail-From: roweber@sempai.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on sempai.org) Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 16:21:16 -0000 Kevin, I suspect you will not see any ASC/Q codes going Obsolete (or Vendor Specific) this time either. My opinion is that the original assertion (i.e., that the definition of an ASC/Q in SPC-x somehow obliges some standard to define a usage for that value) will not pass muster with the majority of the CAP working group. I would not be surprised to find that more than 25% of the currently defined ASC/Q values have no explicit mention in any existing standard or working draft. I do not recall Bill's proposal promising any such in-standard definition. At the time Bill presented his request, the sense of CAP favored defining ASC/Q values to provide useful information (within reason, of course). Clearly, CAP felt that Bill's request had merit. As of yet, I have not heard (or read) sufficient justification for reversing that action. All the best, .Ralph Kevin_Marks@Dell.com wrote: > Fred, > > Whether in use or not, in my ten years of doing T10, I have > never seen an ASC/Q go obsolete. > > Kevin > > > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of > Knight, Frederick > Sent: Wednesday, April 01, 2009 11:23 AM > To: Koning, Paul; dcuddihy@attotech.com > Cc: ips@ietf.org > Subject: Re: [Ips] iSCSI-specific unit attention conditions > > I've tracked down the people involved in the original 2005 T10 proposal, > and I will try to get them involved (if I can't, I'll at least share > what I discover). > > T10 will be reluctant to retire these values if they are in use. > > As mentioned, the use we see for the "ADDRESS CHANGED" event is to cause > a new discovery process to be initiated (to go find any changes). > > Fred > > -----Original Message----- > From: Paul Koning [mailto:Paul_Koning@Dell.com] > Sent: Wednesday, April 01, 2009 11:51 AM > To: dcuddihy@attotech.com > Cc: Knight, Frederick; ips@ietf.org > Subject: Re: [Ips] iSCSI-specific unit attention conditions > > >>>>>> "dcuddihy" == dcuddihy writes: >>>>>> > > dcuddihy> It seems to me that the more important question is how > dcuddihy> useful these unit attention codes are. (For example, > dcuddihy> ATTO's Xtend San initiator doesn't make use of them.) If > dcuddihy> initiators don't care about this information, precisely > dcuddihy> defining these unit attention codes (instead of depricating > dcuddihy> them) will be a change for the worse. > > That's one of my concerns. > > It seems we're just speculating what purpose these codes were intended > to serve. Not only don't we know for sure what that purpose was, we > also don't know if that purpose is actually achieved. > > The other concern is that these codes could be interpreted to impose a > new requirement on targets to generate them in certain situations. Of > course we don't know what those situations are, or why targets should > do this, but clearly someone could argue that those numbers exist and > therefore are supposed to be generated. > > Unless there is a solid proposal that assigns a clear meaning, and > that meaning is valuable to initiators, I believe that the only > correct answer is to consider what happened as a glitch in the > standards process and remove, to the extent possible, the debris left > behind by that glitch. > > I don't see anything in the recent discussion that gets us to this > clear meaning and useful purpose. In particular, I see absolutely NO > trace of "rough consensus and running code" to support the notion that > the iSCSI standard should support these new codes. > > David, can we put in motion the deprecation of these codes? > > paul > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www.ietf.org/mailman/listinfo/ips > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www.ietf.org/mailman/listinfo/ips > > > > From Black_David@emc.com Tue Apr 7 06:03:05 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F863A68D1; Tue, 7 Apr 2009 06:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28O6ebaJ1O+i; Tue, 7 Apr 2009 06:03:04 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id C86C13A6D8E; Tue, 7 Apr 2009 06:03:03 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n37D481K015414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 09:04:08 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.15]) by hop04-l1d11-si03.isus.emc.com (Tablus Interceptor); Tue, 7 Apr 2009 09:03:48 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n37D3TJo024162; Tue, 7 Apr 2009 09:03:43 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 09:03:39 -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, 7 Apr 2009 09:03:38 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A025B0327@CORPUSMX80A.corp.emc.com> In-reply-to: <9FA859626025B64FBC2AF149D97C944A023A30C2@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: STORM BOF - Draft minutes Thread-Index: AcmumI819U1O0IOkRweSmVlG4nxrWwI50gvQ References: <9FA859626025B64FBC2AF149D97C944A023A30C2@CORPUSMX80A.corp.emc.com> To: , X-OriginalArrivalTime: 07 Apr 2009 13:03:39.0853 (UTC) FILETIME=[45536FD0:01C9B781] X-EMM-EM: Active Cc: imss@ietf.org, Black_David@emc.com Subject: Re: [Ips] STORM BOF - Draft minutes X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 13:03:05 -0000 Having seen no objection to (or even comment on) this on the list: > The overall conclusion of the BOF is that a new STORM > (STORage Maintenance) WG should be formed to pursue > essentially the program of work in the draft charter that > I sent to the lists earlier. There will be a new > storm@ietf.org mailing list for this WG. the conclusion of the BOF is confirmed, and I will proceed to put together an actual proposal to form a WG. The next steps will be to put the new storm@ietf.org mailing list in place and produce an actual draft charter with milestones. The draft charter will take a little while (week or two) to appear for comment, as I first want to contact potential draft authors to ensure that the milestone dates are somewhat plausible before putting them into the draft charter. Anyone interesting is being a WG co-chair (multiple co-chairs are likely) should contact our responsible Area Director, Lars Eggert [lars.eggert@nokia.com] (cc:'ing me would be appreciated, but is not necessary), as appointment of WG chairs is up to the Area Directors. I will also make minor edits to the draft minutes and submit them to the proceedings. Thanks, --David > -----Original Message----- > From: Black, David=20 > Sent: Friday, March 27, 2009 12:58 AM > To: ips@ietf.org; rddp@ietf.org > Cc: imss@ietf.org; Black, David > Subject: STORM BOF - Draft minutes >=20 > See below - these are a bit on the long side, as a lot of > ground was covered in the BOF. Many thanks to Paul Koning > for helping to take notes. >=20 > We did not actually have a jabber scribe providing running > commentary in the jabber room - the assumption/hope was that > everyone in the jabber room was listening to the audio feed. > If that was a bad assumption, please send me an email > directly, and we'll do better in the future. >=20 > The overall conclusion of the BOF is that a new STORM > (STORage Maintenance) WG should be formed to pursue > essentially the program of work in the draft charter that > I sent to the lists earlier. There will be a new > storm@ietf.org mailing list for this WG. >=20 > As all decisions in IETF meetings are confirmed on mailing > lists, now is the time to speak up if: > - anyone thinks that a WG should not be formed, or > - anyone thinks that one or more of the work items on the > draft charter (see minutes) should not be done. > I will also be contacting some people directly to try to > ensure that there is at least one Internet-Draft author > for each work item. >=20 > Please also provide any other corrections to the minutes > (either to the list or directly to me). >=20 > Thanks, > --David >=20 >=20 > Transport Area (TSV) BOF: STORM (STORage Maintenance) > THURSDAY, March 26, 2009, 0900-1130 Morning Session I > IETF San Francisco Meetings > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >=20 > BOF chair: David L. Black, EMC (black_david@emc.com) >=20 > Minutes - Initial Draft > ---------------------- >=20 > --- Administrivia ---- > - Note Well (projected) > - Blue Sheets (circulated) > - Scribes (minutes, jabber) > Jabber room was initially not functioning, but was fixed shortly > after BOF started > - Purpose of BOF: Question #1: Should an IETF WG be formed? >=20 > --- Agenda Bashing --- > Agenda was bashed to add discussion of possibly related work in T11 > (Fibre Channel Standards Organization). The T11 vice chair=20 > (and acting > chair) was present to discuss the item. >=20 > -- Draft charter: Initial presentation --- > Charter presented, no text bashed. >=20 > Discussion of possible iSCSI-related work > - Consolidated iSCSI RFC > - Whether to take iSCSI to Draft Standard status, including > implementation report > - SAM-4 feature addition >=20 > Extensive discussion indicated clear strong interest in the SAM-4 > feature addition and interest in consolidating the iSCSI RFCs into a > single document that could go to Draft Standard status. The resulting > plan is to have two drafts: > 1) An rfc3720bis draft that consolidates and prunes the > current iSCSI RFCs based on current implementations. The > intent is that this draft be suitable for Draft=20 > Standard status. > 2) A "new features" draft that adds (in a backwards compatible > fashion) minor new features, starting with the new SAM-4 > features. This draft would be intended for Proposed Standard > status, and all of its contents would be optional=20 > and negotiable > (e.g., via text keys at iSCSI login). > The "new features" draft would not be limited to SAM-4=20 > features, but all > additions would need to be minor. IETF procedures would=20 > allow everything > to be rolled into one document that could be taken to Draft Standard > status after a 6 month waiting period at Proposed Standard,=20 > but the sense > of the discussion was that the above two-document plan is the better > course of action, and that only widely implemented features in current > implementations should be considered for a Draft Standard RFC. >=20 > The BOF chair prefers that the decision as to whether to take iSCSI to > Draft Standard status be deferred, and will write charter=20 > text to allow > this, but not require it. Among the reasons for this are the=20 > amount of > work involved and potential interactions with other RFC documents that > are currently at Proposed Standard status. >=20 > It seems to make better sense to specify iSCSI support for all new > SAM-4 features (as other SCSI transports, such as FCP [SCSI over Fibre > Channel] and SAS [Serial Attach SCSI]) have done, rather than only > specify selected SAM-4 features. iSCSI could then define=20 > multiple text > keys to allow support for these features (or groups of them) to be > separately negotiated. >=20 > IETF coordination with T10 is planned to be handled informally. At > least David Black (BOF chair) and Fred Knight (one of the=20 > presenters on > the SAM-4 topic) are active T10 participants who can facilitate this > coordination. The formal IETF mechanisms for liaison with other > organizations appear unlikely to be needed. >=20 > --- FC encapsulation-related work (possible) --- > - iFCP Address Translation obsolescence > - FC(IP) IP Protocol Number >=20 > Both of these appear to be good ideas. The BOF chair is prepared to > write the Internet-Draft for the first item, and the second item is > for the WG to investigate whether IP Protocol number 133 (allocated > for Fibre Channel in 2000) is unused and should be returned to IANA > for future reassignment. >=20 > - Related T11 activity (RDDP over Ethernet) >=20 > T11 is the standards organization for Fibre Channel. A proposal has > been submitted to T11 for it to work on hosting the RDDP (aka iWARP) > protocols on Ethernet directly via IP, see T11 document 09-141v0: > http://www.t11.org/ftp/t11/admin/project_proposals/09-141v0.pdf >=20 > The design proposed in that document appears to require allocation of > an IP Protocol number. That can only be done by the IESG, and appears > unlikely, as the proposed DCRP protocol is not intended to run over > public networks like the Internet, has no congestion control and no > security. UDP encapsulation may be a more plausible way forward, but > there is a track record of protocols intended for closed networks > "escaping" into the broader Internet. >=20 > The BOF chair (David Black) is also a member of the IETF Transport > Directorate and a T11 participant - he will take these concerns to the > T11 meetings next week and express a desire for significant=20 > consultation > between T11 and the IETF before T11 moves this work moves forward. > The responsible Transport AD (Lars Eggert) concurs with and supports > this course of action. >=20 > --- RDDP-related work (possible) --- > - MPA startup change for MPI >=20 > There has been a lot of support for this relatively contained > proposed work item on the mailing list. >=20 > --- iSER-related work (possible) --- > - Clarifications arising from InfiniBand and other use of iSER >=20 > There has been support on the mailing list for this proposed work > item. >=20 > --- Any other proposed work items --- > Nothing additional proposed. >=20 > --- Draft charter: Text bashing, round 2 --- > No further bashing. >=20 > --- WG formation discussion --- > Clear interest in forming a WG, with a desire to limit travel. >=20 > Work item discussion took a bit longer. Different people are > interested in different work items. A discussion of whether any > work items should be deleted from the initial list in the charter > did not identify any to be deleted, but acknowledged the BOF chair's > preference to not have the charter commit up front to taking iSCSI > to Draft Standard status. With that change, the "rough consensus" > of the meeting (supported by some comments in the jabber room and > emails sent to the list) is that a WG should be formed to take on > essentially the plan of work in the draft charter. >=20 > Discussion about travel and meetings reflected a concern about > travel in current economic conditions and a desire to conduct as > much work as possible on the mailing list. Beyond that, face-to- > face meetings are sometimes needed to resolve issues and make > progress - in line with current IETF practice, if a meeting is > needed during an IETF meeting week, it'll be scheduled without > significant consideration of where that IETF meeting is located. > The expected default for the WG will be to not meet face-to-face > unless there are clear issues that require a meeting. >=20 > Interim meetings were suggested as a possibility, but there does > not appear to be a geographic concentration of interested people; > the BOF chair is aware of likely participants on both coasts of > the US, China, Switzerland and Israel. Iceland was half-heartedly > suggested as approximately equally inconvenient for all concerned. >=20 > --- Mailing List Usage --- >=20 > Organization of the BOF was conducted on the existing ips@ietf.org > and rddp@ietf.org mailing lists, with the imss@ietf.org list cc:'d. >=20 > After some discussion, the mailing list plan going forward is: > - Form new storm@ietf.org mailing list for new STORM WG. > - Announce this list on the IMSS, IPS and RDDP lists, inviting > people to subscribe to the new STORM list. > - No further STORM-related activity on the IMSS list after this > announcement (and perhaps a few reminders). > - Set IPS and RDDP auto-responders to indicate existence of STORM > list. > - After some period of time, close down the RDDP list, ask the > IETF secretariat to set up an auto-responder for email to > rddp@ietf.org indicating that storm@ietf.org should be used. > - Leave IPS list open with auto-responders modified as above. > - Leave IMSS list as it currently is. >=20 > --- Milestones --- > In order to have a charter that can be approved, milestones are > needed. A small amount of discussion yielded the following=20 > guidelines: > - Small stuff (e.g., MPA fix) should make it to Working=20 > Group Last Call > (WG LC) this year > - Other larger things (e.g., SAM-4) may need until latter part of next > year to reach WG LC. > - iSCSI: The consolidated iSCSI draft may be a 2 year=20 > project, but there > should be a decent draft in about 1 year. > - The charter will allow lazy evaluation of decision about whether to > take iSCSI to Draft Standard, and hence not propose any=20 > milestones > for that. >=20 > --- Next steps --- > - BOF chair to revise charter (with milestones) and send to mailing > lists for review. > - Assuming no significant objections to WG creation are raised, the > secretariat will be asked to create a storm@ietf.org=20 > mailing list. > - The actual storm WG formation request will probably go to the Area > Director (Lars) for presentation to the IESG in about a month. >=20 > 14 names on blue sheet, about 8 additional jabber room participants. >=20 From Black_David@emc.com Fri Apr 24 11:37:23 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342403A6A02; Fri, 24 Apr 2009 11:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5pewWfgRmCc; Fri, 24 Apr 2009 11:37:22 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 52C6B3A68B0; Fri, 24 Apr 2009 11:37:19 -0700 (PDT) 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 n3OIcap7025098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2009 14:38:36 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Fri, 24 Apr 2009 14:38:33 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n3OIcQOZ028603; Fri, 24 Apr 2009 14:38:32 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 14:38:32 -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: Fri, 24 Apr 2009 14:38:31 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A0282579F@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Announcement: STORM mailing list Thread-Index: AcnFC93OJm3EdBd2RciNPo496U78Jw== X-Priority: 1 Priority: Urgent Importance: high To: , X-OriginalArrivalTime: 24 Apr 2009 18:38:32.0055 (UTC) FILETIME=[DE3BE870:01C9C50B] X-EMM-EM: Active Cc: imss@ietf.org, Black_David@emc.com, storm@ietf.org Subject: [Ips] Announcement: STORM mailing list X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 18:37:23 -0000 The storm@ietf.org mailing list for the STORM (STORage Maintenance) proposed WG has now been created. To join the list please visit: https://www.ietf.org/mailman/listinfo/storm The immediate reason for joining this list is that I expect to sent out a draft STORM WG charter (with goals and milestones) for discussion sometime next week. While the draft charter will be announced to all of these lists (IPS, RDDP, IMSS, STORM), discussion of the proposed charter will *only* be on the STORM list. Also, for RDDP list subscribers only: This is the first warning that the RDDP list is expected to be closed in the next couple of months, as the STORM list is it's replacement. The IPS and IMSS mailing lists will remain open. 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 ---------------------------------------------------- From Black_David@emc.com Sun Apr 26 19:41:12 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5E033A6AF4; Sun, 26 Apr 2009 19:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42il0dnmj8AM; Sun, 26 Apr 2009 19:41:11 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 7BA763A6B19; Sun, 26 Apr 2009 19:41:10 -0700 (PDT) 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 n3R2gTn0021230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Apr 2009 22:42:29 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Sun, 26 Apr 2009 22:42:22 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n3R2gMo2032296; Sun, 26 Apr 2009 22:42:22 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Apr 2009 22:42:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9C6E1.CA2C0A6C" Date: Sun, 26 Apr 2009 22:42:20 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A028259AF@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Proposed Storm WG Charter Thread-Index: AcnG4ck/cK10DGRGSkW28KXu2KGySw== X-Priority: 1 Priority: Urgent Importance: high To: X-OriginalArrivalTime: 27 Apr 2009 02:42:21.0823 (UTC) FILETIME=[CA2678F0:01C9C6E1] X-EMM-EM: Active Cc: imss@ietf.org, ips@ietf.org, Black_David@emc.com, rddp@ietf.org Subject: [Ips] Proposed Storm WG Charter X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 02:41:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C6E1.CA2C0A6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The proposed WG charter for the Storm WG is attached. The major changes from the charter discussed at the storm BOF in San Francisco are: - Deferred decision on whether to take iSCSI to Draft Standard RFC status; the WG gets to decide (i.e., it's not an up-front commitment to seed Draft Standard RFC status). - Added some text about maintaining good informal working relationships with T10 and T11; the formal IETF Liaison process is available as a last resort, but this is not the best way to get things done. - There are a set of goals and milestones. I have expressions of interest from draft authors for all six of the work items listed on this draft charter. If you have any concerns about this charter or want to comment on it, please speak up ASAP, ... BUT ... ... the forum for discussion of this charter is the new storm@ietf.org mailing list - if you're interested, please join that list and make sure your comments go there. The list archives should be available on-line. 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 ---------------------------------------------------- ------_=_NextPart_001_01C9C6E1.CA2C0A6C Content-Type: text/plain; name="Storm WG proposed charter v4.txt" Content-Transfer-Encoding: base64 Content-Description: Storm WG proposed charter v4.txt Content-Disposition: attachment; filename="Storm WG proposed charter v4.txt" UHJvcG9zZWQgV29ya2luZyBHcm91cDogU1RPUk0gKFNUT1JhZ2UgTWFpbnRlbmFuY2UpDQoJVHJh bnNwb3J0IChUU1YpIEFyZWENClByb3Bvc2VkIENoYXJ0ZXIgKEZpbmFsIERyYWZ0KQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K Q2hhaXJzOg0KLSBEYXZpZCBMLiBCbGFjayA8YmxhY2tfZGF2aWRAZW1jLmNvbT4NCi0gVEJEDQoN ClRyYW5zcG9ydCBBcmVhIERpcmVjdG9yKHMpOg0KLSBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVz Lndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPg0KLSBMYXJzIEVnZ2VydCA8bGFycy5lZ2dlcnRAbm9r aWEuY29tPg0KDQpUcmFuc3BvcnQgQXJlYSBBZHZpc29yOg0KLSBMYXJzIEVnZ2VydCA8bGFycy5l Z2dlcnRAbm9raWEuY29tPg0KDQpNYWlsaW5nIExpc3RzOg0KR2VuZXJhbCBEaXNjdXNzaW9uOiBz dG9ybUBpZXRmLm9yZw0KVG8gU3Vic2NyaWJlOiBzdG9ybS1yZXF1ZXN0QGlldGYub3JnDQpJbiBC b2R5OiAodW4pc3Vic2NyaWJlDQpBcmNoaXZlOiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvc3Rvcm0vaW5kZXguaHRtbA0KDQpEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3Vw Og0KDQpUaGUgSUVURiBpcHMgKElQIFN0b3JhZ2UpIGFuZCByZGRwIChSZW1vdGUgRGlyZWN0IERh dGEgUGxhY2VtZW50KQ0Kd29ya2luZyBncm91cHMgaGF2ZSBwcm9kdWNlZCBhIHNpZ25pZmljYW50 IG51bWJlciBvZiBzdG9yYWdlDQpwcm90b2NvbHMgKGUuZy4sIGlTQ1NJLCBpU0VSIGFuZCBGQ0lQ KSBmb3Igd2hpY2ggdGhlcmUgaXMNCnNpZ25pZmljYW50IHVzYWdlLiAgVGhlIHRpbWUgaGFzIGNv bWUgdG8gcmVmbGVjdCBmZWVkYmFjayBmcm9tDQppbXBsZW1lbnRhdGlvbiBhbmQgdXNhZ2UgaW50 byB1cGRhdGVkIFJGQ3M7IHRoaXMgd29yayBtYXkgaW5jbHVkZToNCg0KLSBJbXBsZW1lbnRhdGlv bi1kcml2ZW4gcmV2aXNpb25zIGFuZCB1cGRhdGVzIHRvIGV4aXN0aW5nIHByb3RvY29scw0KCShp LmUuLCB1cGRhdGVkIFJGQ3MgdGhhdCBtYXRjaCB0aGUgInJ1bm5pbmcgY29kZSIpLg0KLSBJbnRl cm9wZXJhYmlsaXR5IHJlcG9ydHMgYXMgbmVlZGVkIGZvciB0aGUgcmVzdWx0aW5nIHJldmlzZWQN Cglwcm90b2NvbHMgdGhhdCBhcmUgYXBwcm9wcmlhdGUgZm9yIERyYWZ0IFN0YW5kYXJkIFJGQyBz dGF0dXMuDQotIE1pbm9yIHByb3RvY29sIGNoYW5nZXMgb3IgYWRkaXRpb25zLiAgQmFja3dhcmRz IGNvbXBhdGliaWxpdHkNCglpcyByZXF1aXJlZC4NCg0KU2lnbmlmaWNhbnQgY2hhbmdlcyB0byB0 aGUgZXhpc3RpbmcgcHJvdG9jb2wgc3RhbmRhcmRzIGFyZSBvdXQgb2YNCnNjb3BlLCBpbmNsdWRp bmcgYW55IHdvcmsgb24gdmVyc2lvbiAyIG9mIGFueSBvZiB0aGVzZSBwcm90b2NvbHMuDQoNClN0 YWJpbGl0eSBpcyBjcml0aWNhbCB0byB0aGUgdXNhZ2Ugb2YgdGhlc2UgcHJvdG9jb2xzLCBzbyBi YWNrd2FyZHMNCmNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgd2ls bCBiZSBhIHJlcXVpcmVtZW50DQppbXBvc2VkIG9uIGZvciBhbGwgcHJvdG9jb2wgY2hhbmdlcyBh bmQgYWRkaXRpb25zLiAgTm90ZSB0aGF0IHRoaXMNCmlzIGEgcmVxdWlyZW1lbnQgZm9yIGltcGxl bWVudGF0aW9uIGNvbXBhdGliaWxpdHkgLSBpZiBpdCBpcyB0aGUNCmNhc2UgdGhhdCBhbGwgaW1w bGVtZW50YXRpb25zIG9mIGEgcHJvdG9jb2wgaGF2ZSBkb25lIHNvbWV0aGluZw0KZGlmZmVyZW50 IHRoYW4gd2hhdCB0aGUgUkZDIHNwZWNpZmllcywgaXQgaXMgYXBwcm9wcmlhdGUgZm9yDQphIG5l dyBSRkMgdG8gZG9jdW1lbnQgd2hhdCB0aGUgInJ1bm5pbmcgY29kZSIgYWN0dWFsbHkgZG9lcyBh bmQNCmRlcHJlY2F0ZSB0aGUgdW51c2VkIG9yaWdpbmFsIGJlaGF2aW9yLg0KDQpJbml0aWFsIGxp c3Qgb2Ygd29yayBpdGVtczoNCigxKSBpU0NTSTogQ29tYmluZSBSRkNzIDM3MjAgKGlTQ1NJKSwg Mzk4MCAoTkFBIG5hbWVzKSwgNDg1MCAobm9kZQ0KCWFyY2hpdGVjdHVyZSBrZXkpIGFuZCA1MDQ4 IChjb3JyZWN0aW9ucy9jbGFyaWZpY2F0aW9ucykgaW50bw0KCW9uZSBkcmFmdCAoMzcyMGJpcyks IHJlbW92aW5nIGZlYXR1cmVzIHRoYXQgYXJlIG5vdCBpbXBsZW1lbnRlZA0KCWluIHByYWN0aWNl LiAgVGhpcyBkcmFmdCBzaG91bGQgYmUgcHJlcGFyZWQgc28gdGhhdCBpdCBjb3VsZA0KCWJlY29t ZSBhIERyYWZ0IFN0YW5kYXJkIFJGQywgYnV0IGl0IGlzIHVwIHRvIHRoZSB0byBkZWNpZGUNCgl3 aGV0aGVyIHRvIGFkdmFuY2UgaXQgdG8gRHJhZnQgU3RhbmRhcmQuDQooMikgaVNDU0k6IEFkZCBm ZWF0dXJlcyB0byBzdXBwb3J0IFNBTS00ICg0dGggdmVyc2lvbiBvZiB0aGUgU0NTSQ0KCWFyY2hp dGVjdHVyZSkgaW4gYSBiYWNrd2FyZHMtY29tcGF0aWJsZSBmYXNoaW9uLCBhcyBpU0NTSSBpcw0K CWN1cnJlbnRseSBiYXNlZCBvbiBTQU0tMi4gIFRoaXMgd2lsbCBiZSBhIHNlcGFyYXRlIGRyYWZ0 DQoJZnJvbSB0aGUgaVNDU0kgdXBkYXRlIGluIHRoZSBwcmV2aW91cyBidWxsZXQuICBUaGUgV29y a2luZw0KCWdyb3VwIG1heSBhZGQgYWRkaXRpb25hbCBtaW5vciB1c2VmdWwgaVNDU0kgZmVhdHVy ZXMNCgl0byB0aGlzIGRyYWZ0Lg0KKDMpIEZDSVA6IElQIFByb3RvY29sIG51bWJlciAxMzMgd2Fz IGFsbG9jYXRlZCB0byBhIHByZWN1cnNvciBvZg0KCXRoZSBGQ0lQIHByb3RvY29sIGluIDIwMDAs IGJ1dCB0aGlzIGFsbG9jYXRlZCBudW1iZXIgaXMgbm90DQoJdXNlZCBieSBGQ0lQLiAgVGhlIHdv cmtpbmcgZ3JvdXAgd2lsbCBjb25zaWRlciB3aGV0aGVyIHRoaXMNCglhbGxvY2F0ZWQgbnVtYmVy IHNob3VsZCBiZSByZXR1cm5lZCB0byBJQU5BIGZvciBmdXR1cmUNCglyZWFsbG9jYXRpb24uDQoo NCkgaUZDUDogVGhlIEFkZHJlc3MgVHJhbnNsYXRpb24gbW9kZSBvZiBpRkNQIG5lZWRzIHRvIGJl IGRlcHJlY2F0ZWQNCgkoU0hPVUxEIE5PVCBpbXBsZW1lbnQgb3IgdXNlKSwgYXMgdGhlcmUgYXJl IHNpZ25pZmljYW50DQoJdGVjaG5pY2FsIHByb2JsZW1zIHdpdGggaXRzIHNwZWNpZmljYXRpb24s IGFuZCBtb3Jlb3ZlciwNCglvbmx5IHRoZSBBZGRyZXNzIFRyYW5zcGFyZW50IG1vZGUgb2YgaUZD UCBpcyBpbiB1c2UuICBUaGlzDQoJd2lsbCBiZSBkb25lIHZpYSBhIHNob3J0IGRyYWZ0IHRoYXQg dXBkYXRlcyBSRkMgNDE3MiwgYW5kDQoJbm90IHZpYSBhIGNvbXBsZXRlIHJld3JpdGUgb2YgUkZD IDQxNzIuICBBIGNvbWJpbmVkIGRyYWZ0DQoJaXMgZXhwZWN0ZWQgdGhhdCBlbmNvbXBhc3NlcyBp dGVtcyAoMykgYW5kICg0KS4NCig1KSBSRERQIE1QQTogR29vZCBzdXBwb3J0IGZvciBNUEkgYXBw bGljYXRpb25zIHJlcXVpcmVzIGEgc21hbGwNCgl1cGRhdGUgdG8gdGhlIHN0YXJ0dXAgZnVuY3Rp b25hbGl0eSB0byBhbGxvdyBlaXRoZXIgZW5kDQoJb2YgdGhlIGNvbm5lY3Rpb24gdG8gaW5pdGlh dGUuDQooNikgaVNFUjogRXhwZXJpZW5jZSB3aXRoIEluZmluaWJhbmQgaW1wbGVtZW50YXRpb25z IHN1Z2dlc3QgYSBmZXcNCgltaW5vciB1cGRhdGVzIHRvIHJlZmxlY3Qgd2hhdCBoYXMgYmVlbiBk b25lIGluIHByYWN0aWNlLg0KDQpUaGUgd29ya2luZyBncm91cCBpcyBleHBlY3RlZCB0byBtYWlu dGFpbiBnb29kIHdvcmtpbmcgcmVsYXRpb25zaGlwcw0Kd2l0aCBJTkNJVFMgVGVjaG5pY2FsIENv bW1pdHRlZSBUMTAgKFNDU0kgc3RhbmRhcmRzKSBhbmQgSU5DSVRTDQpUZWNobmljYWwgQ29tbWl0 dGVlIFQxMSAoRmlicmUgQ2hhbm5lbCBzdGFuZGFyZHMpIHZpYSBvdmVybGFwcyBpbg0KbWVtYmVy c2hpcCBhcyBvcHBvc2VkIHRvIGFwcG9pbnRtZW50IG9mIGZvcm1hbCBsaWFpc29ucy4gIFRoZQ0K bGlhaXNvbiBwcm9jZXNzIChpbmNsdWRpbmcgSUFCIGFwcG9pbnRtZW50IG9mIGEgbGlhaXNvbiBv cg0KbGlhaXNvbnMpIHJlbWFpbnMgYXZhaWxhYmxlIGZvciB1c2UgaWYgbmVlZGVkLg0KDQpHb2Fs cyBhbmQgTWlsZXN0b25lczoNCg0KSnVuZSAyMDA5CUZpcnN0IHZlcnNpb24gb2YgRkNJUCBwcm90 b2NvbCBudW1iZXIgYW5kIGlGQ1AgQWRkcmVzcw0KCQlUcmFuc2xhdGlvbiBtb2RlIGRyYWZ0DQoN Ckp1bHkgMjAwOQlGaXJzdCB2ZXJzaW9uIG9mIGlTQ1NJIFNBTS00IChhbmQgb3RoZXIpIG5ldyBm ZWF0dXJlcw0KCQlkcmFmdC4NCg0KQXVnIDIwMDkJRmlyc3QgdmVyc2lvbiBvZiBSRERQIE1QQSBz dGFydHVwIGNoYW5nZSBkcmFmdA0KDQpTZXAgMjAwOQlXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBv biBGQ0lQIHByb3RvY29sIG51bWJlciBhbmQNCgkJaUZDUCBhZGRyZXNzIGNoYW5nZSBkcmFmdA0K DQpTZXAgMjAwOSAJRmlyc3QgdmVyc2lvbiBvZiBjb21iaW5lZCBpU0NTSSBkcmFmdCAoMzcyMGJp cykNCg0KT2N0IDIwMDkJRmlyc3QgdmVyc2lvbiBvZiBpU0VSIHVwZGF0ZSBkcmFmdA0KDQpPY3Qg MjAwOQlXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBSRERQIE1QQSBzdGFydHVwIGNoYW5nZSBk cmFmdC4NCg0KRGVjIDIwMDkJRnVuY3Rpb25hbGx5IGNvbXBsZXRlIGlTQ1NJIFNBTS00IChhbmQg b3RoZXIpIG5ldw0KCQlmZWF0dXJlcyBkcmFmdC4NCg0KRmViIDIwMTAJV29ya2luZyBHcm91cCBM YXN0IENhbGwgb24gaVNFUiB1cGRhdGUgZHJhZnQNCg0KTWFyY2ggMjAxMAlXb3JraW5nIEdyb3Vw IExhc3QgQ2FsbCBvbiBpU0NTSSBTQU0tNCAoYW5kIG90aGVyKQ0KCQluZXcgZmVhdHVyZXMgZHJh ZnQuDQoNCkFwcmlsIDIwMTAJV29ya2luZyBHcm91cCBkZWNpc2lvbiBvbiB3aGV0aGVyIHRvIHNl ZWsgRHJhZnQgU3RhbmRhcmQNCgkJUkZDIHN0YXR1cyBmb3IgdGhlIGNvbWJpbmVkIGlTQ1NJIGRy YWZ0ICgzNzIwYmlzKS4gIFtOb3RlOg0KCQlkZWNpc2lvbiBtYXkgYmUgbWFkZSBzaWduaWZpY2Fu dGx5IGJlZm9yZSB0aGlzIGRhdGUuXQ0KDQpTZXAgMjAxMAlXb3JraW5nIEdyb3VwIExhc3QgQ2Fs bCBvbiBjb21iaW5lZCBpU0NTSSBkcmFmdCAoMzcyMGJpcykNCg0K ------_=_NextPart_001_01C9C6E1.CA2C0A6C--