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

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 protected]>
To: Eddy Quicksall <[email protected]>; [email protected]; [email protected]
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 protected]] 
Sent: Tuesday, 2 January 2007 00:54
To: [email protected]; [email protected]
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 protected]>
To: <[email protected]>
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 protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------


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


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

_______________________________________________
Ips mailing list
[email protected]
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 protected]
https://www1.ietf.org/mailman/listinfo/ips