[Ips] Error detection responsibility

[[e-mail]]

Eddy,

I agree with Mallikarjun that a blanket statement, even one
like the second one you proposed, is a bad idea.

I think a better approach would be to identify the specific
cases for which you believe it's unreasonable for a target to
make comprehensive error checks, and document what an
implementation MAY choose not to check.  A blanket statement
like the one you proposed still leaves implementers
scratching their heads about what they're supposed to do.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Eddy Quicksall
> Sent: Monday, June 13, 2005 2:12 PM
> To: Mallikarjun C.; [e-mail]
> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET
> 
> 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." <[e-mail]>
> To: <[e-mail]>
> Sent: Friday, June 10, 2005 2:00 PM
> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET
> 
> 
> > 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
> > Networked Storage Architecture
> > StorageWorks Division
> > Hewlett-Packard MS 5668
> > Roseville CA 95747
> > cbm [at] rose.hp.com
> >
> >
> > Eddy Quicksall wrote:
> >> What do you think  about this? I don't remember seeing an answer.
> >>
> >> Eddy
> >>
> >> ----- Original Message ----- From: "Eddy Quicksall" 
> >> <[e-mail]>
> >> To: <[e-mail]>; <[e-mail]>; <[e-mail]>
> >> Sent: Friday, June 03, 2005 12:45 PM
> >> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET
> >>
> >>
> >>> 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
> >
> >
> > _______________________________________________
> > Ips mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/ips 
> 
> 
> _______________________________________________
> Ips mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ips
> 

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