Re: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike,

That approach will work, here's some minor rewording to make the "running code" aspect more explicit:

"Except as noted, all changes are backwards compatible with RFC 5046." ->
     "With the exception of item 8, all changes are backwards compatible with RFC 5046."

"reflects the known implementations which deviated from RFC 5046" -> "reflects all known implementations of iSER, each of which has implemented this change, despite its absence in RFC 5046."

Also, please double-check whether items 1 (ok to open connection in "zero-copy" instead of "normal" mode) and 4 (change default value for MaxOutstandingUnexpectedPDUs) are backwards-compatible.  I suspect that item 1 is ok because when an initiator opens a connection in "zero-copy" mode with a responder that expects a "normal" mode open, the result should produce errors and die quickly.
OTOH, the default value change for MaxOutstandingUnexpectedPDUs in item 4 does not appear to be backwards-compatible.  If all of the implementations have made this change, handle it as item 8 above.  Otherwise an alterative is to add a statement that the MaxOutstandingUnexpectedPDUs key SHOULD be negotiated because the default value of 0 is problematic for most implementations as it does not impose a bound on resources consumable by unexpected PDUs.

Thanks,
--David

________________________________
From: Michael Ko [Michael@huaweisymantec.com]
Sent: Friday, September 09, 2011 10:22 PM
To: Black, David; storm@ietf.org
Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-03.txt

David,

There is only one change which is not backwards compatible, and that is the inclusion of Base Offset in the iSER header.  I could just leave the first sentence of the paragraph so I don't have to repeat it umpteen times.  So section 14 would lead off with the following:

"Except as noted, all changes are backwards compatible with RFC 5046."

And then for the iSER header change, I will add the following:

"This change is not backwards comptaible with RFC 5046 but it reflects the known implementations which deviated from RFC 5046."

Mike
----- Original Message -----
From: david.black@emc.com<mailto:david.black@emc.com>
To: Michael@huaweisymantec.com<mailto:Michael@huaweisymantec.com> ; storm@ietf.org<mailto:storm@ietf.org>
Sent: Friday, September 09, 2011 6:20 PM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike - that proposed text is just enough to attract the attention of IETF reviewers to ask for more.

Please list the specific changes that are not backwards compatible and state that they reflect the known implementations, all of which chose to do something different from RFC 5046.  The second sentence about the hypothetical implementation should not be used - this is about actual implementations (i.e., “running code”).

Thanks,
--David

From: Michael Ko [mailto:Michael@huaweisymantec.com]
Sent: Friday, September 09, 2011 8:44 PM
To: Black, David; storm@ietf.org
Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-03.txt

David,

I intend to add the following paragraph in section 14.

Except as noted, all changes are backwards compatible with RFC 5046.  However, there are some changes which reflect existing implementation and are not backwards compatible with RFC 5046.  As a result, a hypothetical implementation based on RFC 5046 will not interoperate with an implementation based on this version of the specification.

Mike
----- Original Message -----
From: david.black@emc.com<mailto:david.black@emc.com>
To: Michael@huaweisymantec.com<mailto:Michael@huaweisymantec.com> ; storm@ietf.org<mailto:storm@ietf.org>
Sent: Friday, September 09, 2011 8:34 AM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike,

Thanks for submitting this updated draft.

In Section 14 (Appendix A), please add a discussion of backwards compatibility with RFC 5046 - it’s important to explain how an implementation based on this draft will interact with a hypothetical implementation based on RFC 5046.  As part of this, it’s important to identify changes that are incompatible with RFC 5046, but compatible with existing implementations because the implementations did something different from RFC 5046.  As a start, it would help to identify each numbered change as backwards-compatible (with RFC 5046) vs. backwards-incompatible (because RFC 5046 got it wrong in 20/20 hindsight).

Thanks,
--David

From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Michael Ko
Sent: Wednesday, September 07, 2011 12:59 PM
To: storm@ietf.org
Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-03.txt

The summary of changes since RFC 5046 can be found in section 14.  In particular, the following changes were made since the -02 version of the draft:

8. Added two 64-bit fields in iSER header in section 9.2 for the Read Base Offset and the Write Base Offset to accommodate a non-zero Base Offset.  This allows one implementation such as the OFED stack to be used in both the Infiniband and the iWARP environment.  Changes were made in the definition of Base Offset, Advertisement, and Tagged Buffer.  Changes were also made in sections 2.4.1, 2.5, 2.6, 7.3.1, 7.3.3, 7.3.5, 7.3.6, 9.1, 9.3, 9.4, 9.5.1, and 9.5.2.
9. Remove iWARP specific behavior.  Changes were made in the definition section on RDMA Operation and Send Message Type.  Changes affecting Send with Invalidate were made in sections 2.4.1, 2.5, 2.6, 4.1, and 7.3.2.  Changes affecting Terminate were made in sections 10.1.2.1 and 10.1.2.2.  (Forgot to mention here that section 15 was also updated to remove iWARP specific behavior.)
10. Denial of service descriptions for the initiator in section 5.1.1 was removed since it is applicable for the target only.
Mike
----- Original Message -----
From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
Cc: storm@ietf.org<mailto:storm@ietf.org>
Sent: Tuesday, September 06, 2011 6:17 PM
Subject: [storm] I-D Action: draft-ietf-storm-iser-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the STORage Maintenance Working Group of the IETF.

Title           : iSCSI Extensions for RDMA Specification
Author(s)       : Michael Ko
                          Alexander Nezhinsky
Filename        : draft-ietf-storm-iser-03.txt
Pages           : 91
Date            : 2011-09-06

   iSCSI Extensions for RDMA provides the RDMA data transfer capability
   to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol.  An
   RDMA-Capable Protocol provides RDMA Read and Write services, which
   enable data to be transferred directly into SCSI I/O Buffers without
   intermediate data copies.  This document describes the extensions to
   the iSCSI protocol to support RDMA services as provided by an RDMA-
   Capable Protocol.

   This document obsoletes RFC5046
   Table of Contents

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-storm-iser-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-storm-iser-03.txt
_______________________________________________
storm mailing list
storm@ietf.org<mailto:storm@ietf.org>
https://www.ietf.org/mailman/listinfo/storm