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

[<[e-mail]>]

It sounds like we should go with option b)

b) Default remains at 0, keep existing text that says the key SHOULD be
negotiated because that default value is problematic.

Thanks,
--David

From: Michael Ko [mailto:[e-mail]]
Sent: Thursday, September 29, 2011 5:27 PM
To: Black, David; [e-mail]
Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-04.txt

David,

That's why I suggested not changing the default at all and just leave it as zero, the original default value in RFC 5046.  By changing the default to 4 and then adding a MUST requirement for this key actually creates more work for existing implementation.  At least when the default is zero, there is no ambiquity as to which default is being followed and it is up to an implementation whether it needs to negotiate this key or not.

Mike
----- Original Message -----
From: [e-mail]<mailto:[e-mail]>
To: [e-mail]<mailto:[e-mail]> ; [e-mail]<mailto:[e-mail]>
Sent: Tuesday, September 27, 2011 7:24 AM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-04.txt

Mike,

> It seems to me that the default for MaxOutstandingUnexpectedPDUs is another thing that could have been defined better in RFC 5046.

RFC 5046 does not lack for clarity, even though it may have (in 20/20 hindsight) chosen a poor default value, see last line below.

6.7.  MaxOutstandingUnexpectedPDUs

   Use: LO (leading only), Declarative

   Senders: Initiator and Target

   Scope: SW (session-wide)

   Irrelevant when: RDMAExtensions=No

   MaxOutstandingUnexpectedPDUs=<numerical-value-from-2-to-(2**32-1) |
   0>

   Default is 0


Subsequent text specifies that 0 means "no limit".

Changing the default from 0 to 4 without a "MUST negotiate" requirement is not backwards compatible when the key is not negotiated.

Thanks,
--David

From: Michael Ko [mailto:[e-mail]]
Sent: Monday, September 26, 2011 8:57 PM
To: Black, David; [e-mail]
Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-04.txt

David,

It seems to me that the default for MaxOutstandingUnexpectedPDUs is another thing that could have been defined better in RFC 5046.  It is not clear to me that all existing implementation uses a default value of 4.  If some implementations assume a default value of 0, then the key has to be negotiated anyway.  So my inclination is to not change the original text in RFC 5046 and just leave it as is (option d - no change) unless we hear otherwise from developers.

For MaxAHSLength, I can go ahead and incorporate your suggestion.

Mike
----- Original Message -----
From: [e-mail]<mailto:[e-mail]>
To: [e-mail]<mailto:[e-mail]> ; [e-mail]<mailto:[e-mail]>
Sent: Monday, September 26, 2011 3:57 PM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-04.txt

Mike,
Thanks for updating this draft.

Looking at the details.  I think some changes are needed:

6.7  MaxOutstandingUnexpectedPDUs

The problem here is that the change in the default value of the key from
0 to 4 is not backwards compatible if the key is not negotiated.  I had
thought that the default was going to be changed to 0.

I think there are three choices:
a) No default, key MUST be negotiated, 4 is a suggested value, unless a
      larger value is needed.
b) Default remains at 0, keep existing text that says the key SHOULD be
negotiated because that default value is problematic.
c) Change the default to 4 and state that all implementations do this,
      keep existing text that says the key SHOULD be negotiated because
the default value of 0 in RFC 5046 is problematic is fine.
It looks like you're headed for option c), and hence need to add text
to say that all implementations already use this default if that's the
case.  If not, a) may be the best way out of this.

This will affect item 4 in Section 14.


I'd like to edit the text in 6.8 MaxAHSLength to use a SHOULD and make

it clear when the SHOULD applies:

OLD
      For interoperability with implementations based on [RFC5046], an
      initiator or target MAY terminate the connection if it anticipates
      MaxAHSLength to be greater than 256 and the key is not understood by
      its peer.
NEW
      For interoperability with implementations based on [RFC5046], an
      initiator or target that needs a MaxAHSLength larger than
256 and receives a NotUnderstood response to this key from its peer
SHOULD terminate the connection.

Thanks,
--David

From: [e-mail] [mailto:[e-mail]] On Behalf Of Michael Ko
Sent: Monday, September 26, 2011 6:25 PM
To: [e-mail]
Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-04.txt

This version of the iSER draft incorporated the comments from David Black on backward compatibility.  Changes from the -03 version are in sections 6.7, 6.8, and Appendix A.

Mike
----- Original Message -----
From: [e-mail]<mailto:[e-mail]>
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Sent: Monday, September 26, 2011 3:17 PM
Subject: [storm] I-D Action: draft-ietf-storm-iser-04.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-04.txt
Pages           : 91
Date            : 2011-09-26

   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 RFC 5046.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-storm-iser-04.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-04.txt
_______________________________________________
storm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/storm