Re: [Ips] ABORT TASK vs ABORT TASK SET

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

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. ; [e-mail] ; [e-mail] 
  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" <[e-mail]> 
        Sent by: [e-mail] 
        13/06/2005 13:12 
       To "Mallikarjun C." <[e-mail]>, <[e-mail]>  
              cc  
              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