[storm] iSCSI -06 candidate-1 version

Mallikarjun Chadalapaka <cbm@chadalapaka.com> Sun, 01 July 2012 23:01 UTC

Return-Path: <cbm@chadalapaka.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 0376321F8715 for <storm@ietfa.amsl.com>; Sun, 1 Jul 2012 16:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level:
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1]
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 UbTupqlGw301 for <storm@ietfa.amsl.com>; Sun, 1 Jul 2012 16:01:24 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id E60D521F8709 for <storm@ietf.org>; Sun, 1 Jul 2012 16:01:23 -0700 (PDT)
Received: from mail23-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Sun, 1 Jul 2012 22:59:31 +0000
Received: from mail23-db3 (localhost [127.0.0.1]) by mail23-db3-R.bigfish.com (Postfix) with ESMTP id 5CF7F320358 for <storm@ietf.org>; Sun, 1 Jul 2012 22:59:31 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT001.namprd06.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -9
X-BigFish: PS-9(zzc85fh103dK1a09J14ffIzz1202hzz8275bh8275dh5eeeKz2fh2a8h668h839hd25hf0ah)
Received-SPF: pass (mail23-db3: domain of chadalapaka.com designates 157.56.240.117 as permitted sender) client-ip=157.56.240.117; envelope-from=cbm@chadalapaka.com; helo=BL2PRD0610HT001.namprd06.prod.outlook.com ; .outlook.com ;
Received: from mail23-db3 (localhost.localdomain [127.0.0.1]) by mail23-db3 (MessageSwitch) id 1341183567876518_12923; Sun, 1 Jul 2012 22:59:27 +0000 (UTC)
Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.247]) by mail23-db3.bigfish.com (Postfix) with ESMTP id CA05B160047 for <storm@ietf.org>; Sun, 1 Jul 2012 22:59:27 +0000 (UTC)
Received: from BL2PRD0610HT001.namprd06.prod.outlook.com (157.56.240.117) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 1 Jul 2012 22:59:25 +0000
Received: from BL2PRD0610MB361.namprd06.prod.outlook.com ([169.254.11.249]) by BL2PRD0610HT001.namprd06.prod.outlook.com ([10.255.101.36]) with mapi id 14.16.0164.004; Sun, 1 Jul 2012 23:01:19 +0000
From: Mallikarjun Chadalapaka <cbm@chadalapaka.com>
To: "storm@ietf.org" <storm@ietf.org>
Thread-Topic: iSCSI -06 candidate-1 version
Thread-Index: Ac1X3WE3rLXBUcNiQ46+fgKU7SCbYA==
Date: Sun, 1 Jul 2012 23:01:18 +0000
Message-ID: <E160851FCED17643AE5F53B5D4D0783A235D7DAF@BL2PRD0610MB361.namprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [76.22.17.63]
Content-Type: multipart/alternative; boundary="_000_E160851FCED17643AE5F53B5D4D0783A235D7DAFBL2PRD0610MB361_"
MIME-Version: 1.0
X-OriginatorOrg: chadalapaka.com
Subject: [storm] iSCSI -06 candidate-1 version
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: Sun, 01 Jul 2012 23:01:28 -0000

Hi All,

Since the -05 version, iSCSI Consolidated draft received invaluable feedback from a few folks, most notably from our AD Martin Stiemerling and Rob Elliott. Many thanks to both of them.

I have now incorporated all the feedback - most of it is editorial/non-normative in nature - with the exception of one major item, the X-/X# key-related changes that David sent out to the list last week - which the authors are in agreement with. I will give it a few days for the list feedback, before I incorporate those changes and submit the -06 version.

I am including a list of all normative changes below. You can find the current working version of the draft, including the changes below, here:

http://www.chadalapaka.com/Documents/draft-ietf-storm-iscsi-cons-06.pdf

Please let the authors know of your feedback.

Thanks!

Mallikarjun


Section 4.2.2.1
[from]

The initiator and target must  ensure that the task management commands act as specified by  [SAM2].

[to]

The initiator and target MUST ensure that the SCSI task management functions specified in [SAM2] act in accordance with the [SAM2] specification.

Section 6.2
[from]

An iSCSI initiator or target MAY terminate a negotiation that does not end within a reasonable time or number of exchanges.

[to]

An iSCSI initiator or target MAY terminate a negotiation that does not terminate within an implementation-specific reasonable time or number of exchanges, but SHOULD allow at least 6 exchanges.

Section 6.2.2
[from]

Proposing a value not admissible (e.g., not within the specified  bounds) MAY be answered with the constant "Reject" or the acceptor   MAY select an admissible value.

[to]

Proposing a value not admissible (e.g., not within the specified bounds) MAY be answered with the constant "Reject", otherwise the acceptor MUST select an admissible value.

Section 6.2.2
[from]

For a numerical range the value selected must be an integer within  the proposed range or "Reject" (if the range is unacceptable).


[to]

For a numerical range the value selected MUST be an integer within the proposed range or "Reject" (if the range is unacceptable).

Section 6.3.3
[from]

If the target responds to a Login request that has the T bit set to 1 with a Login response that has the T bit set to 0, the initiator should keep sending the Login request (even empty) with the T bit set to 1, while it still wants to switch stage, until it receives the Login Response that has the T bit set to 1 or it receives a key that requires it to set the T bit to 0.
[to]
Even when the initiator indicates its intent to switch stage by setting the T bit to 1 in a Login request, the target MAY respond with a Login response with the T bit set to 0. In that case, the initiator SHOULD continue to set the T bit to 1 in subsequent Login requests (even empty) that it sends, until target sends a Login response with the T bit set to 1 or sends a key that requires initiator to set the T bit to 0.

Section 6.4
[from]

  if the target responds to a text request with the f bit set to 1

  with a text response with the f bit set to 0, the initiator should

  keep sending the text request (even empty) with the f bit set to

  1, while it still wants to finish the negotiation, until it

  receives the text response with the f bit set to 1. responding to

  a text request with the f bit set to 1 with an empty (no key=value

  pairs) response with the f bit set to 0 is discouraged.

[to]

Even when the initiator indicates its intent to finish the negotiation by setting the F bit to 1 in a Text request, the target MAY respond with a Text response with the F bit set to 0. In that case, the initiator SHOULD continue to set the F bit to 1 in subsequent Text requests (even empty) that it sends, until target sends the final Text response with the F bit set to 1. Note that in the same case of Text request with the F bit set to 1, target SHOULD NOT respond with an empty (no key=value pairs) Text response with the F bit set to 0, because such a response may cause the initiator to abandon negotiation.

Section 9.2
[from]

Therefore, a method using clear text (or equivalent) passwords is not acceptable
[to]

Therefore, a method using clear text (or equivalent) passwords MUST NOT be used

Section 11.3.1
[from]

Setting both the W and the F bit to 0 is an error

[to]

At least one of the W and F bits MUST be set to 1.

Section 11.4.3
[from]

A non-zero response field indicates a failure to execute the command in which case the Status and Flag fields are undefined.

[to]

A non-zero response field indicates a failure to execute the command in which case the Status and Flag fields are undefined and MUST be ignored on reception.

Section 11.4.5.1
[from]

The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If neither bit is set, the Residual Count field is reserved.

[to]

The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If neither bit is set, the Residual Count field MUST be ignored on reception and SHOULD be set to 0 when sending.

Appendix C
[add]
The text in this Appendix is a normative part of this document.