[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
  Web www.spinics.net

Re: iSCSI Implementer's Guide - WG Last Call status


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.


----- Original Message ----
From: "Sandars, Ken" <ken_sandars@xxxxxxxxxxx>
To: Eddy Quicksall <Quicksall_iSCSI@xxxxxxxxxxxxx>; Black_David@xxxxxxx; ips@xxxxxxxx
Sent: Monday, January 1, 2007 5:05:30 PM
Subject: RE:  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

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.


-----Original Message-----
From: Eddy Quicksall [mailto:Quicksall_iSCSI@xxxxxxxxxxxxx] 
Sent: Tuesday, 2 January 2007 00:54
To: Black_David@xxxxxxx; ips@xxxxxxxx
Subject: Re:  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


----- Original Message -----
From: <Black_David@xxxxxxx>
To: <ips@xxxxxxxx>
Sent: Thursday, December 28, 2006 3:27 PM
Subject:  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).


David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@xxxxxxx        Mobile: +1 (978) 394-7754

Ips mailing list

Ips mailing list

Ips mailing list

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

Ips mailing list

[IETF]     [Linux iSCSI]     [Linux SCSI]     [Linux Resources]     [Yosemite News]     [IETF Announcements]     [IETF Discussion]     [SCSI]

Add to Google Powered by Linux