Subject: [Ips] WG Last Call Review: iSER

From: [email-masked]
Date: Fri, 3 Jun 2005 21:31:21 -0400

I have reviewed the iSER draft, draft-ietf-ips-iser-03.txt,
and in addition to editorial issues that I will send
directly to Mike, I found a number of technical issues:

(1) Section 3.3 has a structural problem in that the first
sentence says "should satisfy" and the remaining sentences
to be satisfied are expressed as "MUST" requirements.  The
net result is that all the requirements in that section are
"should" requirements, which is not what was intended.
The first sentence needs to be rewritten to say something
to the effect of "In order to use iSER, the following MUST
be done:" .

(2) Section 3.3, item 1. says "MUST negotiate the
RDMAExtensions key to "Yes" "  Since the key is negotiated
(not declared) and it takes two to negotiate, that requirement
cannot be achieved by an implementation if the other side
doesn't cooperate.  This needs to be rewritten to talk about
offering the key as "Yes" and replying as "Yes" and that
if the result is not "Yes" then iSER is not used (traditional
iSCSI is used instead).

(3) Section 3.3., item 5. says "MUST successfully negotiate
the TargetRecvDataSegmentLength key".  Again there's a "takes
two to negotiate" problem, and the "failed to successfully
negotiate" case needs to be specified.

(4) Section 5.1, last two paragraphs have similar problems in
that they specify required negotiation behavior without
describing what to do when the other side doesn't cooperate
or do what it is supposed to.  Those failure cases need to
be covered.

(5) Section 5.1.2, in the Note at the very end of the section
about two steps needing to be atomic, "must" should be "MUST".

(6) Section 5.1.3 is missing specification and explanation of
version negotiation and version numbers in the iSER Hello
Exchange.  The error case instructions for when version
negotiation fails need to be copied here in addition to their
current location in Section 10.1.3.2 .

(7) Section 7.3.9 - I believe sending of Login Request or Login
Response in Datamover mode is always an error.  This section
should say so and say what to do about it.

(8) Sections 7.3.11 and 10.2.1 - The specified SNACK handling
does not work because the instruction in 10.2.1 to handle SNACK
as per RFC 3720 would require retransmission of non-existent
Data and R2T PDUs.  I can see a couple of possible corrective
approaches:
a) Change Section 7.3.11 to prohibit (MUST NOT) sending SNACK
	PDUs (instead of the current SHOULD NOT) and change
	Section 10.2.1 to define reception of any SNACK PDU as
	an error.
b) Put limits on what SNACK PDUs can be used to recover
	(Status only?) in Section 7.3.11, and modify Section
	10.2.1 to say how to recover that and what to do when
	a prohibited SNACK is received.

(9) Section 8.1 uses the phrase "buffer underrun" for an "out
	of buffers" condition.  That should be "buffer exhaustion".

(10) Section 8.4 could result in a situation where an iSER Target
	cannot send a Reject PDU that an iSCSI Target would be
	able send.  It needs to explain what to do in that situation.

(11) Section 11 on Security Considerations is weak, but the
	overall approach of appealing to security considerations in
	other specifications is probably ok.  This section needs to
	be strengthened by saying that since iSER is still functionally
	iSCSI, all of the iSCSI security considerations in RFC 3720
	apply, and it should also reference the discussion of iSCSI
	security in RFC 3723.

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

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Mike Ko <[email-masked]>
Date: Sun, 12 Jun 2005 22:09:56 -0700

David,

Thanks for the review.  Please see my comments inline.

Mike

[email-masked]@ietf.org on 06/03/2005 06:31:21 PM

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    [Ips] WG Last Call Review: iSER

[mk] ok

[mk] ok

[mk] The old items 4 and 5 are now replaced by the new item 4 with the
follwowing text:

"The iSCSI Layers at both the initiator and the target MUST support the
keys as defined in section 6 on Login/Text Operational Keys.  If used as
specified, these keys MUST NOT be answered with NotUnderstood and the
semantics as defined MUST be followed for each iSER-assisted connection."

[mk] The new text for comment #3 should address this issue.

[mk] ok

[mk] ok

[mk] ok

[mk] The updated iSER draft will follow the suggestion in 8a.  Also updated
 text in section 3.3 and section 8.3 on SNACK handling.

[mk] ok

[mk] The following text has been added in section 8.4:
    (Implementation note:  If the number of outstanding unexpected
    control-type PDUs equals MaxOutstandingUnexpectedPDUs, the target will
    not be able to send another unexpected control-type PDU until some
    outstanding ones have been retired.  To ensure that the initiator has a
    means of retiring outstanding PDUs, the target should reserve the last
    unexpected control-type PDU allowable by MaxOutstandingUnexpectedPDUs
    as a NOP-in ping request with ITT = 0xffffffff and TTT != 0xffffffff to
    allow the initiator to return the NOP-out ping response with the
    current ExpStatSN.)

[mk] This section now references RFC3723 and the security drafts for RDDP.
 Both documents have also been added to the list of references.

Thanks,
--David