Re: [Ips] iSCSI-specific unit attention conditions

"Knight, Frederick" <Frederick.Knight@netapp.com> Wed, 01 April 2009 16:23 UTC

Return-Path: <Frederick.Knight@netapp.com>
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 <ips@core3.amsl.com>; 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 <ips@core3.amsl.com>; 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 <ips@ietf.org>; 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: <AC32D7C72530234288643DD5F1435D530445C9AB@RTPMVEXC1-PRD.hq.netapp.com>
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" <Frederick.Knight@netapp.com>
To: "Paul Koning" <Paul_Koning@Dell.com>, <dcuddihy@attotech.com>
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 <ips.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ips>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=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. 

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  <dcuddihy@attotech.com>; 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