[storm] iSCSI -06 candidate-1 version

[Mallikarjun Chadalapaka <[e-mail]>]

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.