Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 4 Jan 2007 12:27:14 -0800 (PST)

Ken,

I think the concern here is that whatever text we put in could easily be misinterpreted as granting the target implementation the freedom to "properly understand" the initiator's intent, when the problem is that the initiator's intent is either fuzzy or plain confusing from the PDU contents and the target does not really know what the "proper intent" is.

Mallikarjun

----- Original Message ----
From: "Sandars, Ken" <[email-masked]>
To: Eddy Quicksall <[email-masked]>; [email-masked]; [email-masked]
Sent: Monday, January 1, 2007 5:05:30 PM
Subject: RE: [Ips] iSCSI Implementer's Guide - WG Last Call status

Happy New Gregorian Year,

I support Eddy's request for some words to suggest that target
implementations should be allowed to handle initiator errors in a manner
which does not damage the target behaviour.

Target behaviour should be evaluated by its transmissions on the wire
and via data integrity tests. Test suites and protocol analysers should
not assume what the target's actions will be as a result of illegal
initiator behaviour unless explicitly defined in RFC3720.

For example, say an initiator issues a Logout Request PDU with reason
code 0 (close the session), but sets the CID field to the current
connection. The target MAY process this command as though there is no
error on the part of the initiator. A test suite or protocol analyser
MUST NOT penalise the target if it does so.

Another example is an initiator which sets either the W or/and R bits in
a SCSI Command Request PDU which has an Expected Data Transfer Length of
0.

Finally, a test-suite which sets a non-zero value in reserved fields for
initiator PDUs should not expect the target to check these values.

Clearly a target which performs additional checking of the initiator's
PDUs is likely to be more robust when faced with reception errors when
not using digests.

Cheers
Ken

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]] 
Sent: Tuesday, 2 January 2007 00:54
To: [email-masked]; [email-masked]
Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status

Actually I didn't want to discourage targets from checking but to point
out that checking is not required unless the RFC specifically requires
it. The note could in fact encourage checking where performance is not
affected.

Eddy

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 28, 2006 3:27 PM
Subject: [Ips] iSCSI Implementer's Guide - WG Last Call status

The Working Group Last Call on this draft nominally ended on
December 18th, but there was no reason to treat that as a hard
cutoff.  I am now ending the WG Last Call on this draft, although
list discussion of issues should be continued.

There have been two issues raised during this WGLC:
(1) Task Management - how to deal with uncooperative third-
party initiators.  This issue has been resolved
on the list.
(2) Target checks - whether to discourage targets from
checking for initiator mistakes that the target can
tolerate.  At the moment, I think the "rough consensus"
of the WG is not to do this - if anyone other than
Eddy thinks this is important to clarify, they need
to speak up promptly after the holidays.

The process from here is that Mallikarjun will submit a
revised version of the draft in the near future (there are
still some details to be worked out on the list).  I will
be completely out of action (no email) the first two weeks
of January, so there will be time for people to check for
problems/issues/etc.  I will check the revised draft and
send it to Lars with a request for RFC publication sometime
in the second half of January (probably during the week of
January 22nd).

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 

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

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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

---

From: Paul Koning <[email-masked]>
Date: Thu, 4 Jan 2007 16:11:51 -0500

>>>>> "Mallikarjun" == Mallikarjun C <[email-masked]> writes:

 Mallikarjun> Ken, I think the concern here is that whatever text we
 Mallikarjun> put in could easily be misinterpreted as granting the
 Mallikarjun> target implementation the freedom to "properly
 Mallikarjun> understand" the initiator's intent, when the problem is
 Mallikarjun> that the initiator's intent is either fuzzy or plain
 Mallikarjun> confusing from the PDU contents and the target does not
 Mallikarjun> really know what the "proper intent" is.

I think we've been here before.

To me the answer is very simple.  If an initiator obeys the protocol
rules, it is entitled to see behavior specified by the RFC.  If it
violates the rules, it is not entitled to anything.

A target MAY check for protocol violations, but (unless the RFC
specifically requires it, which it should only do for strong reasons)
it is under no obligation to check.  If it checks, then the initiator
will probably see a fairly clean reaction to a protocol error (for
example a disconnect, or a reject of some sort).  If the target
doesn't check, a faulty initiator may see undefined behavior.

Ditto in the other direction (swap "initiator" and "target" in the
above). 

Requiring "sane" reactions (however one might define those) to
non-sane inputs is not a good thing to ask for.  It imposes
substantial overhead on good implementations, and it only benefits bad
implementations.

	paul