Re: [Ips] ABORT TASK vs ABORT TASK SET

["Eddy Quicksall" <[e-mail]>]

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

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Friday, June 03, 2005 8:51 AM
Subject: RE: [Ips] ABORT TASK vs ABORT TASK SET


> 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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
>
> _______________________________________________
> Ips mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ips 


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