Re: [storm] WG Last Call comments on consolidated iSCSI draft

<david.black@emc.com> Tue, 30 August 2011 23:08 UTC

Return-Path: <david.black@emc.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A44A21F8EA7 for <storm@ietfa.amsl.com>; Tue, 30 Aug 2011 16:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.549
X-Spam-Level:
X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kljw5Q6gRUL1 for <storm@ietfa.amsl.com>; Tue, 30 Aug 2011 16:08:20 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 129A921F8EA5 for <storm@ietf.org>; Tue, 30 Aug 2011 16:08:19 -0700 (PDT)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7UN9keW021732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Aug 2011 19:09:46 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 30 Aug 2011 19:09:38 -0400
Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7UN9Zos005045; Tue, 30 Aug 2011 19:09:35 -0400
Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Tue, 30 Aug 2011 19:09:35 -0400
From: david.black@emc.com
To: cbm@chadalapaka.com, storm@ietf.org
Date: Tue, 30 Aug 2011 19:09:33 -0400
Thread-Topic: [storm] WG Last Call comments on consolidated iSCSI draft
Thread-Index: AQJAVYkkLWavS0oHYUWDAKL4T48HuQDIn2D4AdO1VzkC8WT0eQIKnvcMAoUTTtIBQStMhJPy10yAgABb6vA=
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058B130618@MX14A.corp.emc.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E05896E6CF8@MX14A.corp.emc.com> <AC32D7C72530234288643DD5F1435D5310EDE150@RTPMVEXC1-PRD.hq.netapp.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058B130026@MX14A.corp.emc.com> <4E59A574.8040602@ieee.org> <F1938006-9643-4E73-8F8E-257B81B40F3C@satran.net> <7C4DFCE962635144B8FAE8CA11D0BF1E058B130046@MX14A.corp.emc.com> <4E5BEA43.5050404@ieee.org> <SNT131-ds21686A6C7D8230ADE11F91A0170@phx.gbl>
In-Reply-To: <SNT131-ds21686A6C7D8230ADE11F91A0170@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Aug 2011 23:08:21 -0000

I like Ralph's suggestion to include a mention of operating systems in the new test,
but I have some further tweaks to his words to suggest:

SCSI initiator functionality in some operating systems depends on ACA to enforce
ordered command execution during error recovery, and hence iSCSI initiator
implementations for those operating systems need to support ACA.  In order
to support error recovery for these operating systems and iSCSI initiators,
iSCSI targets SHOULD support ACA.

Thanks,
--David

> -----Original Message-----
> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Mallikarjun Chadalapaka
> Sent: Tuesday, August 30, 2011 1:49 PM
> To: storm@ietf.org
> Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft
> 
> I am catching up on this thread after a vacation.
> 
> I agree in general with the consensus on this thread that we should leave
> ACA as SHOULD.
> 
> Specifically, I like David's last rewrite, which succinctly states the
> rationale in SCSI initiator terms, as appropriate for this spec.  I plan to
> get that into the next rev.
> 
> David, thanks for your Last Call review.  I will address your all other
> comments as well in the next revision.
> 
> Thanks.
> 
> Mallikarjun
> 
> 
> 
>   -----Original Message-----
>   From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf
>   Of Ralph Weber
>   Sent: Monday, August 29, 2011 12:37 PM
>   To: storm@ietf.org
>   Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft
> 
>   A necessary nuance between Operating Systems and initiator products is
>   missing in the rewrite. How about:
> 
>   Some operating systems depend on SCSI ACA to enforce ordered command
>   execution during error recovery, and hence iSCSI initiator implementations
>   for those operating systems need to support ACA.  In order to support
> error
>   recovery for these operating systems and iSCSI initiators, iSCSI targets
>   SHOULD support ACA.
> 
>   All the best,
> 
>   .Ralph
> 
>   On 8/28/2011 12:27 PM, david.black@emc.com wrote:
>   > I agree - second try at text:
>   >
>   > OLD
>   >    ACA helps preserve ordered command execution in the presence of
>   >    errors. As iSCSI can have many commands in-flight between
>   >    initiator and target, iSCSI initiators and targets SHOULD support
>   >    ACA.
>   > NEW
>   >    Some SCSI initiators use ACA to enforce ordered command execution
>   >    during error recovery, and hence iSCSI initiator implementations
>   >    for those SCSI initiators need to support ACA.  In order to support
>   >    error recovery for these SCSI and iSCSI initiators, iSCSI targets
>   >    SHOULD support ACA.
>   >
>   > As Ralph noted, an implementer of an iSCSI initiator that needs ACA
>   > will know it, or learn quickly when error recovery doesn't work right
>   > wrt the SCSI class driver :-), so the primary purpose of the SHOULD in
>   > this text is to tell target implementers about the need for ACA support.
>   >
>   > FWIW, this is a "SHOULD" and not a "MUST" because a target
>   implementer
>   > may choose not to support initiators that use ACA - that absence of
>   > ACA support will be detected quickly at the SCSI level, as the first
>   > SCSI command that sets the NACA bit in the CONTROL byte in the CDB
>   > will get hit with a CHECK CONDITION for having done so.
>   >
>   > Thanks,
>   > --David
>   >
>   >> -----Original Message-----
>   >> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On
>   >> Behalf Of Julian Satran
>   >> Sent: Sunday, August 28, 2011 1:15 AM
>   >> To: Ralph Weber
>   >> Cc: storm@ietf.org
>   >> Subject: Re: [storm] WG Last Call comments on consolidated iSCSI
>   >> draft
>   >>
>   >> Ralph,
>   >>
>   >> I think you caught a nit. Your point is correct - WRT initiators.
>   >> The SHOULD statement should refer to targets only.  Initiators that
>   >> are not supporting ACA may have a hard time surviving in the same
>   >> environment with initiators that require and support ACA  but will
> cause
>   no harm to those that require and support it.
>   >>
>   >> Julo
>   >> On Aug 28, 2011, at 5:18 AM, Ralph Weber wrote:
>   >>
>   >>> I am having a little bit of difficulty following the logic of the
>   >>> proposed new text.
>   >>>
>   >>> First it says that some initiator implementations use ACA (which
>   >>> implies that some do not). Then, it says that iSCSI initiators
>   >>> (presumably all iSCSI initiators) ... SHOULD support ACA.
>   >>>
>   >>> I can understand why initiators that need ACA SHOULD support it, but
>   >>> why should the others bear the burden?
>   >>>
>   >>> All the best,
>   >>>
>   >>> .Ralph
>   >>>
>   >>> On 8/27/2011 5:36 PM, david.black@emc.com wrote:
>   >>>> <WG chair hat off>
>   >>>>
>   >>>> In that case, let's at least get the explanation for the SHOULD right
> ;-).
>   >>>>
>   >>>> Here's a suggestion ...
>   >>>>
>   >>>> OLD
>   >>>>    ACA helps preserve ordered command execution in the presence of
>   >>>>    errors. As iSCSI can have many commands in-flight between
>   >>>>    initiator and target, iSCSI initiators and targets SHOULD support
>   >>>>    ACA.
>   >>>> NEW
>   >>>>    Some SCSI initiator implementations use ACA to enforce ordered
>   >>>>    command execution during recovery from errors.  In order to
>   support
>   >>>>    error recovery in such SCSI initiators, iSCSI initiators and
> targets
>   >>>>    SHOULD support ACA.
>   >>>>
>   >>>> Thanks,
>   >>>> --David
>   >>>>
>   >>>>> -----Original Message-----
>   >>>>> From: Knight, Frederick [mailto:Frederick.Knight@netapp.com]
>   >>>>> Sent: Friday, August 26, 2011 8:51 AM
>   >>>>> To: Black, David
>   >>>>> Cc: storm@ietf.org
>   >>>>> Subject: RE: [storm] WG Last Call comments on consolidated iSCSI
>   >>>>> draft
>   >>>>>
>   >>>>> I disagree.
>   >>>>>
>   >>>>> 1) while not common, the hosts that use it, do need it;
>   >>>>> 2) the original 3720 text contains a SHOULD; and
>   >>>>> 3) there is no good reason for us to be weakening this statement.
>   >>>>>
>   >>>>> 	Fred Knight
>   >>>>> 	NetApp
>   >>>>>
>   >>>>> -----Original Message-----
>   >>>>> From: david.black@emc.com [mailto:david.black@emc.com]
>   >>>>> Sent: Thursday, August 25, 2011 5:55 PM
>   >>>>> To: storm@ietf.org
>   >>>>> Subject: [storm] WG Last Call comments on consolidated iSCSI draft
>   >>>>>
>   >>>>> <...text removed...>
>   >>>>>
>   >>>>> [D] Section 10.2 contains a "SHOULD" requirement for ACA
>   >>>>> (Auto-Contingent Allegiance) support.
>   >>>>> As ACA support in SCSI initiators is not common, I suggest
>   >>>>> weakening this to a MAY requirement.
>   >>>>>
>   >>>>>
>   >>>> _______________________________________________
>   >>>> storm mailing list
>   >>>> storm@ietf.org
>   >>>> https://www.ietf.org/mailman/listinfo/storm
>   >>>>
>   >>>>
>   >>> _______________________________________________
>   >>> storm mailing list
>   >>> storm@ietf.org
>   >>> https://www.ietf.org/mailman/listinfo/storm
>   >> _______________________________________________
>   >> storm mailing list
>   >> storm@ietf.org
>   >> https://www.ietf.org/mailman/listinfo/storm
>   >
>   >
>   _______________________________________________
>   storm mailing list
>   storm@ietf.org
>   https://www.ietf.org/mailman/listinfo/storm
> 
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm