Subject: RE: [Ips] ABORT TASK vs ABORT TASK SET

From: [email-masked]
Date: Fri, 3 Jun 2005 08:51:01 -0400

Mallikarjun,

> I am concerned that the current lack of detailed specification would
> allow targets that might even cause silent data corruptions 
> to qualify as RFC 3720-compliant.
> 
> Here are what I believe to be semantics applicable to all TMF requests
> that can potentially terminate multiple tasks.  I do not know the IETF 
> process well enough here, but I suggest that we consider this text 
> replacing the existing section 10.6.2 in RFC 3720 - so the new text can 
> cover all the TMFs that can impact multiple tasks.  This is basically a 
> superset of the current 10.6.2 semantics.

IETF does have an errata process, but (IMHO) it's not a great venue
for something like this that it's important for implementers to pay
attention to.  What I would suggest is that we start an Internet-Draft
that is intended to become an Implementers Guide RFC (standards track)
to include both technical corrections like this one, and explanations
of subtle points such as how to deal with (what appear to be) REPORT
LUNS overruns as discussed here earlier.  An available example is that
an implementers guide draft is being maintained for SCTP (see
draft-ietf-tsvwg-sctpimpguide-13.txt) although I'd like to believe that
an iSCSI implementers guide won't grow to that size.

For this task management issue, explaining what the problem is and why
the change fixes it in an implementers guide is at least as important as
specifying the change.  For the REPORT LUNS overruns, the implementers
guide text would be an explanation of why no change is needed, including
some elaboration on the (less than completely obvious) SPC-2 text that
specifies the behavior of REPORT LUNS in this circumstance.  Before I
go looking for another volunteer, would you be interested in editing
an implementers guide Internet Draft?  Between Julian and I, we should
be able write the REPORT LUNS explanation paragraph or two.

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: "Eddy Quicksall" <[email-masked]>
Date: Fri, 3 Jun 2005 12:45:19 -0400

If you are going to write this guide, I would like to suggest that a 
paragraph be added saying something like "the initiator and target are not 
expected to catch all protocol errors introduced by the other party and it 
is the implementers option as to which errors may be caught due to internal 
dynamics, crash dynamics or data corruption".

Eddy

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 07 Jun 2005 11:40:14 -0700

David,

 >What I would suggest is that we start an Internet-Draft

I am fine with your suggestion.  Is there a standard way to make a 
formal linkage between RFC 3720 and this new draft, e.g. as in "when you 
implement RFC 3720, you must/should implement the contents of draft foo 
because foo fills in some intended but unspecified semantics of RFC 3720"

 >would you be interested in editing
 > an implementers guide Internet Draft?

Yes, I can be talked into doing that....  I assume it has to be 
submitted as an individual submission to begin with?

Thanks.

Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
StorageWorks Division
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

---

From: "Eddy Quicksall" <[email-masked]>
Date: Tue, 7 Jun 2005 21:17:09 -0400

What do you think  about this? I don't remember seeing an answer.

Eddy

----- Original Message ----- 
From: "Eddy Quicksall" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, June 03, 2005 12:45 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

> is the implementers option as to which errors may be caught due to 
> internal dynamics, crash dynamics or data corruption".
>
> Eddy
>

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 10 Jun 2005 11:00:30 -0700

My comment on this is that such a blanket statement will be a problem.

RFC 3720 has a defined notion of protocol errors and their handling, and 
uses a fair number of MUSTs (sometimes conditional) on Rejects (as PDUs 
and in negotiation) - e.g., if you support data digests, you must 
discard a bad digest PDU with a Reject.  These actions inherently 
require protocol validation and catching errors.  I don't think we want 
to weaken any of that.

Mallikarjun

Mallikarjun Chadalapaka

Eddy Quicksall wrote:
> ----- Original Message ----- From: "Eddy Quicksall" 
> <[email-masked]>
>> paragraph be added saying something like "the initiator and target are 
>> not expected to catch all protocol errors introduced by the other 
>> party and it is the implementers option as to which errors may be 
>> caught due to internal dynamics, crash dynamics or data corruption".
>>
>> Eddy
>>
>> ----- Original Message ----- From: <[email-masked]>

---

From: "Eddy Quicksall" <[email-masked]>
Date: Mon, 13 Jun 2005 14:12:29 -0400

Actually, I was talking about a clarification of what is expected of the 
target and initiator in the event that the RFC does not cover it with a 
MUST. The problem is that some people think the target must check for all 
protocol errors. This is not practical and sometimes not even possible for 
all cases.

Perhaps wording similar to this would be in order:

"Except where specifically noted, the initiator and target are
not expected to catch all protocol errors introduced by the other
party and it is the implementers option as to which errors may be
caught due to internal dynamics."

Eddy

----- Original Message ----- 
From: "Mallikarjun C." <[email-masked]>
To: <[email-masked]>
Sent: Friday, June 10, 2005 2:00 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

> and in negotiation) - e.g., if you support data digests, you must discard 
> a bad digest PDU with a Reject.  These actions inherently require protocol 
> validation and catching errors.  I don't think we want to weaken any of 
> that.
>
> Mallikarjun
>
> Mallikarjun Chadalapaka
>>> not expected to catch all protocol errors introduced by the other party 
>>> and it is the implementers option as to which errors may be caught due 
>>> to internal dynamics, crash dynamics or data corruption".
>>>
>>> Eddy
>>>

---

From: Julian Satran <[email-masked]>
Date: Sat, 18 Jun 2005 01:19:56 -0500

Eddy,

Why  should we say what an I or
T is not expected to do - except in case of errors?

At best it should say "are not
mandated" instead of "not expected"  and it would be
redundant and somewhat harmful (some will interpret as a license to improve
by doing something beyond "mandated").

Julo

"Eddy Quicksall"

Sent by: [email-masked]

13/06/2005 13:12

To

"Mallikarjun C." <[email-masked]>,
<[email-masked]>

cc

Subject

Re: [Ips] ABORT TASK vs ABORT TASK SET

Actually, I was talking about a clarification of what
is expected of the

protocol errors. This is not practical and sometimes not even possible
for

all cases.

Eddy

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

To: <[email-masked]>

> and in negotiation) - e.g., if you support data digests, you must
discard

>>>>> replacing the existing section 10.6.2 in RFC 3720
- so the new text

>>>>> can

>>>>> cover all the TMFs that can impact multiple tasks.
This is basically

>>>>> a

>>>> the change fixes it in an implementers guide is at least
as important

>>>> as

>>>> guide text would be an explanation of why no change is
needed,

>>>> including

Ips mailing list

[email-masked]

---

From: "Eddy Quicksall" <[email-masked]>
Date: Tue, 21 Jun 2005 16:13:35 -0400

Not mandated sounds good. We could drop the "... and it is the ... clause if it is not of any informational use.

"Except where specifically noted, the initiator and target are
not mandated to catch all protocol errors introduced by the other
party and it is the implementers option as to which errors may be
caught."

Eddy
  ----- Original Message ----- 
  From: Julian Satran 
  To: Eddy Quicksall 
  Cc: Mallikarjun C. ; [email-masked] ; [email-masked] 
  Sent: Saturday, June 18, 2005 2:19 AM
  Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

  Eddy, 

  Why  should we say what an I or T is not expected to do - except in case of errors? 
  At best it should say "are not mandated" instead of "not expected"  and it would be redundant and somewhat harmful (some will interpret as a license to improve by doing something beyond "mandated"). 

  Julo 

        "Eddy Quicksall" <[email-masked]> 
        Sent by: [email-masked] 
        13/06/2005 13:12 
       To "Mallikarjun C." <[email-masked]>, <[email-masked]>  
              cc  
              Subject Re: [Ips] ABORT TASK vs ABORT TASK SET 

  Eddy