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

From: <[email-masked]>
Date: Thu, 25 Aug 2011 17:54:51 -0400

I managed to review this draft, although I didn't look at the Appendixes, and a side-by-side
diff against RFC 3720 was very helpful.

These comments are for discussion, and hence are with WG chair hat off.

Major issues:

[A] I think the "Updates:" field in the header is wrong.  I believe that the RFC published from
the consolidated draft should be the one base reference for iSCSI.  Therefore it needs to obsolete
RFCs 3720, 3980, 4850 and 5048.  The RFC Editor's database tracks "obsoleted by" relationships,
so anyone looking for any of those RFCs will find a reference to the new RFC.  The presence of
RFC 3721 as updated by this draft is correct.

[B] As noted previously on the list, the "MUST" requirement for use of authentication in the
first line of Section 9.2 needs to be changed to a "MAY" (as it was in RFC 3720).  Implementation
of CHAP authentication is still a "MUST" requirement.

[C] The IPsec RFC references have been updated to the new version of IPsec, but we haven't
done anything to RFC 3723, which still references an older version of IPsec.  I had been
hoping to avoid updating RFC 3723, but input on what to do here is welcome.  One possibility
is to add just enough text to the consolidated draft to update the IPsec requirements material
in RFC 3723 to the new version of IPsec, allow implementation of the old version, and avoid
a 3723bis draft.  Thoughts?

[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.

[E] I didn't see any text to specify that the SPKM keys MUST NOT generate "NotUnderstood" responses.
OTOH, as I believe SPKM support for iSCSI was never implemented, I don't believe that this is a
serious problem.

Minor Concerns:

[1] There are a number of statements of the form "See SCSI for ...".  Each of these should cite
a relevant SCSI standard.

[2] In Section 4.4.2, somehow "15 bytes" was changed to "14 bytes" in this bullet item:

       - a text encoding as a hex-constant (see Section 5.1 "Text
          Format") of the ISID (for SCSI initiator port) or the
          portal group tag (for SCSI target port) including the
          initial 0X or 0x and the terminating null (14 bytes).

I believe 15 bytes is correct, as that's "0x" (2 bytes) + 48-bit ISID in hex (12 bytes) +
a null (1 byte).  A portal group tag is shorter (16 bits), so 15 bytes in the maximum length,
but only 7 bytes will be used for the portal group tag case.

[2] In Section 6.3, on p.99, remove at least the second sentence from this paragraph (it's
incorrect), or remove the entire paragraph:

  The initiator and target MAY want to negotiate iSCSI
  authentication parameters. Once this negotiation is completed, the
  channel is considered secure.

[3] In section 6.3.2, change "security mechanism" to "authentication method" in the first line
of the first paragraph for clarity:

  The security exchange sets the security mechanism and authenticates
  the initiator user and the target to each other. The exchange
  proceeds according to the authentication method chosen in the
  negotiation phase and is conducted using the login requests' and
  responses' key=value parameters.

[4] Also in Section 6.3.2, remove "It should be noted that" from the last paragraph:

  It should be noted that the negotiation might also be directed by
  the target if the initiator does support security, but is not
  ready to direct the negotiation (propose options).

Nits:

There are an enormous number of section number cross-references that either point to the
wrong place (because they still need to be updated) or are incomplete (contain no
section number).

In 11.4.5.3, 3rd paragraph:
	at theS CSI layer ->  at the SCSI layer

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Knight, Frederick" <[email-masked]>
Date: Fri, 26 Aug 2011 08:51:23 -0400

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: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, August 25, 2011 5:55 PM
To: [email-masked]
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.

---

From: <[email-masked]>
Date: Sat, 27 Aug 2011 18:36:30 -0400

<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

> From: Knight, Frederick [mailto:[email-masked]]
> Sent: Friday, August 26, 2011 8:51 AM
> To: Black, David
> Cc: [email-masked]
> Subject: RE: [storm] WG Last Call comments on consolidated iSCSI draft
> 
> I disagree.
>

---

From: Ralph Weber <[email-masked]>
Date: Sat, 27 Aug 2011 21:18:28 -0500

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, [email-masked] wrote:
> _______________________________________________
> storm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/storm
>
>

---

From: Julian Satran <[email-masked]>
Date: Sun, 28 Aug 2011 08:14:56 +0300

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

---

From: <[email-masked]>
Date: Sun, 28 Aug 2011 13:27:28 -0400

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian Satran
> Sent: Sunday, August 28, 2011 1:15 AM
> To: Ralph Weber
> Cc: [email-masked]
> Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft
> 
> Ralph,
> 
> 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

---

From: Ralph Weber <[email-masked]>
Date: Mon, 29 Aug 2011 14:36:35 -0500

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

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Tue, 30 Aug 2011 10:48:43 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf
  Of Ralph Weber
  Sent: Monday, August 29, 2011 12:37 PM
  To: [email-masked]
  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, [email-masked] wrote:
  > 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
  >
  >> 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.
  >>> I can understand why initiators that need ACA SHOULD support it, but
  >>> why should the others bear the burden?
  >>>
  >>> All the best,
  >>>
  >>> .Ralph
  >>>

---

From: <[email-masked]>
Date: Tue, 30 Aug 2011 19:09:33 -0400

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mallikarjun Chadalapaka
> Sent: Tuesday, August 30, 2011 1:49 PM
> To: [email-masked]

---

From: Ralph Weber <[email-masked]>
Date: Tue, 30 Aug 2011 21:08:19 -0500

David, If agreement between the two of us counts as consensus,
then pop open the bubbly. All the best, .Ralph