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

From: [email-masked]
Date: Tue, 06 Sep 2011 18:17:01 -0700

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

---

From: Michael Ko <[email-masked]>
Date: Tue, 06 Sep 2011 18:22:34 -0700

This is the latest iSER draft incorporating all known issues with RFC5046 as 
discussed in Quebec City.

Mike
----- Original Message ----- 
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
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.

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-storm-iser-03.txt
_______________________________________________
storm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/storm

---

From: Michael Ko <[email-masked]>
Date: Wed, 07 Sep 2011 09:59:27 -0700

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

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 11:34:38 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Ko
Sent: Wednesday, September 07, 2011 12:59 PM
To: [email-masked]
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: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Sent: Tuesday, September 06, 2011 6:17 PM
Subject: [storm] I-D Action: draft-ietf-storm-iser-03.txt

[email-masked]<mailto:[email-masked]>

---

From: Michael Ko <[email-masked]>
Date: Fri, 09 Sep 2011 10:27:00 -0700

David,

Will do in the next version.

Mike
----- Original Message ----- 
From: [email-masked]
To: [email-masked] ; [email-masked]
Sent: Friday, September 09, 2011 8:34 AM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike,

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: [email-masked] [mailto:[email-masked]] On Behalf Of 
Michael Ko
Sent: Wednesday, September 07, 2011 12:59 PM
To: [email-masked]
Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike

----- Original Message ----- 

Cc: [email-masked]

---

From: Michael Ko <[email-masked]>
Date: Fri, 09 Sep 2011 17:44:02 -0700

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: [email-masked]
To: [email-masked] ; [email-masked]
Sent: Friday, September 09, 2011 8:34 AM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike,

Thanks,
--David

Mike

----- Original Message ----- 

Cc: [email-masked]

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 21:20:47 -0400

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:[email-masked]]
Sent: Friday, September 09, 2011 8:44 PM
To: Black, David; [email-masked]
Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-03.txt

David,

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: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Friday, September 09, 2011 8:34 AM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike,

Thanks,
--David

---

From: Michael Ko <[email-masked]>
Date: Fri, 09 Sep 2011 19:22:18 -0700

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: [email-masked]
To: [email-masked] ; [email-masked]
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

David,

Mike

----- Original Message ----- 

Mike,

Thanks,
--David

Mike

----- Original Message ----- 

Cc: [email-masked]

---

From: <[email-masked]>
Date: Sun, 11 Sep 2011 14:12:27 -0400

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 [[email-masked]]
Sent: Friday, September 09, 2011 10:22 PM
To: Black, David; [email-masked]
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:

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

Mike
----- Original Message -----
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Friday, September 09, 2011 6:20 PM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

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

David,

Mike
----- Original Message -----
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Friday, September 09, 2011 8:34 AM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike,

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: Michael Ko <[email-masked]>
Date: Sun, 11 Sep 2011 17:05:20 -0700

David,

I agree with the assessment on item #1.

For item #4, If we add "SHOULD" for it, then we should probably also add it 
for items #5 and #7.

Mike
----- Original Message ----- 
From: [email-masked]
To: [email-masked] ; [email-masked]
Sent: Sunday, September 11, 2011 11:12 AM
Subject: 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

David,

Mike
----- Original Message -----
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]> ; 

implementations (i.e., “running code”).

Thanks,
--David

David,

Mike
----- Original Message -----
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]> ; 

Mike,

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: <[email-masked]>
Date: Sun, 11 Sep 2011 20:32:06 -0400

Mike,

For item #4 The reason for the "SHOULD" is that if the default is left at 0 for backwards compatibility, then a "SHOULD" provides appropriate warning that accepting this default is usually not a good idea.

For item #5, the interesting concern is what to do when the response to an attempt to negotiate MaxAHSLength is "MaxAHSLength=NotUnderstood" (i.e., the other party is an RFC 5046 implementation that does not understand the new key).  A SHOULD for negotiating this key won't help, in contrast to item #4, where a "NotUnderstood" response is not possible.  Please add some text to Section 6.8 advising an implementation that wants to negotiate MaxAHSLength what it should do if the response is "NotUnderstood".  FWIW, the default value of 256 seems ok, as it's not easy to create an iSCSI AHS that's larger than 256 bytes - the largest CDBs in anything resembling common use are 32 bytes (which would produce an AHS with 16 bytes of payload plus the AHS header).  Weird stuff like OSD and capability based command security (see SPC-4) can definitely produce larger CDBs, so perhaps the caution ought to be something like "If an initiator supports SCSI functionality that can create CDBs that are significantly larger than 32 bytes (e.g., OSD, SPC-4 capability-based command security), then MaxAHSLength SHOULD be explicitly negotiated."

Item #7 seems to be more complex.  My reading of the summary of item #7 is that courtesy of underlying communication infrastructure differences, an implementation that needs to turn off iSER Hello messages is likely to be talking to an implementation that will cooperate (e.g., InfiniBand), and one that doesn't need turn off those messages is likely to be talking to an implementation that supports them.  Again, I think some text is needed about how to deal with a "NotUnderstood" response, but the previous sentence should be part of the discussion (e.g., before suggesting that an implementation that needs to turn off iSER Hello messages should respond to "iSERHelloRequired=NotUnderstood" by abandoning the connection/session).  As part of this, I think the default for iSERHelloRequired should be changed to "Yes" and text needs to be added to say that an initiator implementation that does not support iSER Hello messages MUST explicitly declare this key (i.e., "iSERHelloRequired=No").

Thanks,
--David

Sent: Sunday, September 11, 2011 8:05 PM

David,

For item #4, If we add "SHOULD" for it, then we should probably also add it for items #5 and #7.

Mike
----- Original Message -----
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Sunday, September 11, 2011 11:12 AM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike,

Thanks,
--David

To: Black, David; [email-masked]<mailto:[email-masked]>

David,

Mike
----- Original Message -----
From: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>> ; [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 09, 2011 6:20 PM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Thanks,
--David

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

David,

Mike
----- Original Message -----
From: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>> ; [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 09, 2011 8:34 AM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike,

Thanks,
--David

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

----- Original Message -----
From: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, September 06, 2011 6:17 PM
Subject: [storm] I-D Action: draft-ietf-storm-iser-03.txt

[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>

---

From: Michael Ko <[email-masked]>
Date: Sun, 11 Sep 2011 19:52:10 -0700

David,

For item #5, if MaxAHSLength is supported, then the default of 256 should 
cover the situation where "an initiator supports SCSI functionality that can 
create CDBs that are significantly larger than 32 bytes (e.g., OSD, SPC-4 
capability-based command security)".  So perhaps you mean when it is "larger 
than 256 bytes" then "MaxAHSLength SHOULD be explicitly negotiated".  But 
even if MaxAHSLength is not supported, a target can still function properly 
as long as there is no "Weird stuff like OSD and capability based command 
security" which can produce larger CDBs.  So perhaps an iSER device MAY 
terminate the connection if it anticipates MaxAHSLength > 256 and the key is 
not understood.

Since the iSER update is intended to reflect running code, then for item #7, 
the default for iSERHelloRequired being "Yes" would require changes in 
existing implementation in order to comply with the new iSER spec.  Do we 
really want to change running code to accommodate something that doesn't 
exist?

Mike
----- Original Message ----- 
From: [email-masked]
To: [email-masked] ; [email-masked]
Sent: Sunday, September 11, 2011 5:32 PM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike,

For item #4 The reason for the "SHOULD" is that if the default is left at 0 
for backwards compatibility, then a "SHOULD" provides appropriate warning 
that accepting this default is usually not a good idea.

For item #5, the interesting concern is what to do when the response to an 
attempt to negotiate MaxAHSLength is "MaxAHSLength=NotUnderstood" (i.e., the 
other party is an RFC 5046 implementation that does not understand the new 
key).  A SHOULD for negotiating this key won't help, in contrast to item #4, 
where a "NotUnderstood" response is not possible.  Please add some text to 
Section 6.8 advising an implementation that wants to negotiate MaxAHSLength 
what it should do if the response is "NotUnderstood".  FWIW, the default 
value of 256 seems ok, as it's not easy to create an iSCSI AHS that's larger 
than 256 bytes - the largest CDBs in anything resembling common use are 32 
bytes (which would produce an AHS with 16 bytes of payload plus the AHS 
header).  Weird stuff like OSD and capability based command security (see 
SPC-4) can definitely produce larger CDBs, so perhaps the caution ought to 
be something like "If an initiator supports SCSI functionality that can 
create CDBs that are significantly larger than 32 bytes (e.g., OSD, SPC-4 
capability-based command security), then MaxAHSLength SHOULD be explicitly 
negotiated."

Item #7 seems to be more complex.  My reading of the summary of item #7 is 
that courtesy of underlying communication infrastructure differences, an 
implementation that needs to turn off iSER Hello messages is likely to be 
talking to an implementation that will cooperate (e.g., InfiniBand), and one 
that doesn't need turn off those messages is likely to be talking to an 
implementation that supports them.  Again, I think some text is needed about 
how to deal with a "NotUnderstood" response, but the previous sentence 
should be part of the discussion (e.g., before suggesting that an 
implementation that needs to turn off iSER Hello messages should respond to 
"iSERHelloRequired=NotUnderstood" by abandoning the connection/session).  As 
part of this, I think the default for iSERHelloRequired should be changed to 
"Yes" and text needs to be added to say that an initiator implementation 
that does not support iSER Hello messages MUST explicitly declare this key 
(i.e., "iSERHelloRequired=No").

Thanks,
--David

David,

Mike
----- Original Message -----
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]> ; 

Mike,

Thanks,
--David

David,

Mike
----- Original Message -----
From: 
[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
To: 
[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>> 
; 
[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 09, 2011 6:20 PM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Thanks,
--David

David,

Mike
----- Original Message -----
From: 
[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
To: 
[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>> 
; 
[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 09, 2011 8:34 AM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike,

Thanks,
--David

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

----- Original Message -----
From: 
[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
To: 
[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
Cc: 
[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, September 06, 2011 6:17 PM
Subject: [storm] I-D Action: draft-ietf-storm-iser-03.txt

---

From: <[email-masked]>
Date: Mon, 12 Sep 2011 09:27:26 -0400

Mike,

Your discussion of item #5 is fine - please reflect that in text in the new draft.

For item #7, I'm ok with the iSERHelloRequired default being "no" because iSER Hello has not been implemented. Please add a statement that iSER Hello has not been implemented and is not in use as the explanation for that default (sorry, I'd forgotten that fact).

Thanks,
--David

From: Michael Ko [mailto:[email-masked]]
Sent: Sunday, September 11, 2011 10:52 PM
To: Black, David; [email-masked]
Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-03.txt

David,

For item #5, if MaxAHSLength is supported, then the default of 256 should cover the situation where "an initiator supports SCSI functionality that can create CDBs that are significantly larger than 32 bytes (e.g., OSD, SPC-4 capability-based command security)".  So perhaps you mean when it is "larger than 256 bytes" then "MaxAHSLength SHOULD be explicitly negotiated".  But even if MaxAHSLength is not supported, a target can still function properly as long as there is no "Weird stuff like OSD and capability based command security" which can produce larger CDBs.  So perhaps an iSER device MAY terminate the connection if it anticipates MaxAHSLength > 256 and the key is not understood.

Since the iSER update is intended to reflect running code, then for item #7, the default for iSERHelloRequired being "Yes" would require changes in existing implementation in order to comply with the new iSER spec.  Do we really want to change running code to accommodate something that doesn't exist?

Mike
----- Original Message -----
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Sunday, September 11, 2011 5:32 PM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike,

Thanks,
--David

David,

Mike
----- Original Message -----
From: [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>> ; [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>
Sent: Sunday, September 11, 2011 11:12 AM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike,

Thanks,
--David

To: Black, David; [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

David,

Mike
----- Original Message -----
From: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]>>>
To: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]>>> ; [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]>>>
Sent: Friday, September 09, 2011 6:20 PM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Thanks,
--David

From: Michael Ko [mailto:[email-masked]]
Sent: Friday, September 09, 2011 8:44 PM
To: Black, David; [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>
Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-03.txt

David,

Mike
----- Original Message -----
From: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]>>>
To: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]>>> ; [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]>>>
Sent: Friday, September 09, 2011 8:34 AM
Subject: RE: [storm] I-D Action: draft-ietf-storm-iser-03.txt

Mike,

Thanks,
--David

From: [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>> [mailto:[email-masked]] On Behalf Of Michael Ko
Sent: Wednesday, September 07, 2011 12:59 PM
To: [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>
Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-03.txt

----- Original Message -----
From: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]>>>
To: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]>>>
Cc: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]>>>
Sent: Tuesday, September 06, 2011 6:17 PM
Subject: [storm] I-D Action: draft-ietf-storm-iser-03.txt

[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]>>>