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: david.black@emc.com
To: Michael@huaweisymantec.com ; storm@ietf.org
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:Michael@huaweisymantec.com]
Sent: Monday, September 26, 2011 8:57 PM
To: Black, David; storm@ietf.org
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: david.black@emc.com

To: Michael@huaweisymantec.com ; storm@ietf.org

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 makeit 
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: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of 
Michael Ko
Sent: Monday, September 26, 2011 6:25 PM
To: storm@ietf.org
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: internet-drafts@ietf.org

To: i-d-announce@ietf.org

Cc: storm@ietf.org

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
storm@ietf.org
https://www.ietf.org/mailman/listinfo/storm