Re: [storm] WG Last Call comments on consolidated iSCSI draft

[Mallikarjun Chadalapaka <[e-mail]>]

Sure, works for me.  Thanks.

M

  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]] On Behalf
  Of Ralph Weber
  Sent: Tuesday, August 30, 2011 7:08 PM
  To: [e-mail]
  Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft
  
  David, If agreement between the two of us counts as consensus, then pop
  open the bubbly. All the best, .Ralph
  
  On 8/30/2011 6:09 PM, [e-mail] wrote:
  > I like Ralph's suggestion to include a mention of operating systems in
  > the new test, but I have some further tweaks to his words to suggest:
  >
  > SCSI initiator functionality in some operating systems depends on ACA
  > to enforce ordered command execution during error recovery, and hence
  > iSCSI initiator implementations for those operating systems need to
  > support ACA.  In order to support error recovery for these operating
  > systems and iSCSI initiators, iSCSI targets SHOULD support ACA.
  >
  > Thanks,
  > --David
  >
  >> -----Original Message-----
  >> From: [e-mail] [mailto:[e-mail]] On
  >> Behalf Of Mallikarjun Chadalapaka
  >> Sent: Tuesday, August 30, 2011 1:49 PM
  >> To: [e-mail]
  >> Subject: Re: [storm] WG Last Call comments on consolidated iSCSI
  >> draft
  >>
  >> I am catching up on this thread after a vacation.
  >>
  >> I agree in general with the consensus on this thread that we should
  >> leave ACA as SHOULD.
  >>
  >> Specifically, I like David's last rewrite, which succinctly states
  >> the rationale in SCSI initiator terms, as appropriate for this spec.
  >> I plan to get that into the next rev.
  >>
  >> David, thanks for your Last Call review.  I will address your all
  >> other comments as well in the next revision.
  >>
  >> Thanks.
  >>
  >> Mallikarjun
  >>
  >>
  >>
  >>    -----Original Message-----
  >>    From: [e-mail] [mailto:[e-mail]] On
  Behalf
  >>    Of Ralph Weber
  >>    Sent: Monday, August 29, 2011 12:37 PM
  >>    To: [e-mail]
  >>    Subject: Re: [storm] WG Last Call comments on consolidated iSCSI
  >> draft
  >>
  >>    A necessary nuance between Operating Systems and initiator products
  is
  >>    missing in the rewrite. How about:
  >>
  >>    Some operating systems depend on SCSI ACA to enforce ordered
  command
  >>    execution during error recovery, and hence iSCSI initiator
  implementations
  >>    for those operating systems need to support ACA.  In order to
  >> support error
  >>    recovery for these operating systems and iSCSI initiators, iSCSI
targets
  >>    SHOULD support ACA.
  >>
  >>    All the best,
  >>
  >>    .Ralph
  >>
  >>    On 8/28/2011 12:27 PM, [e-mail] wrote:
  >>    >  I agree - second try at text:
  >>    >
  >>    >  OLD
  >>    >     ACA helps preserve ordered command execution in the presence
of
  >>    >     errors. As iSCSI can have many commands in-flight between
  >>    >     initiator and target, iSCSI initiators and targets SHOULD
support
  >>    >     ACA.
  >>    >  NEW
  >>    >     Some SCSI initiators use ACA to enforce ordered command
  execution
  >>    >     during error recovery, and hence iSCSI initiator
implementations
  >>    >     for those SCSI initiators need to support ACA.  In order to
support
  >>    >     error recovery for these SCSI and iSCSI initiators, iSCSI
targets
  >>    >     SHOULD support ACA.
  >>    >
  >>    >  As Ralph noted, an implementer of an iSCSI initiator that needs
ACA
  >>    >  will know it, or learn quickly when error recovery doesn't work
right
  >>    >  wrt the SCSI class driver :-), so the primary purpose of the
SHOULD
  in
  >>    >  this text is to tell target implementers about the need for ACA
  support.
  >>    >
  >>    >  FWIW, this is a "SHOULD" and not a "MUST" because a target
  >>    implementer
  >>    >  may choose not to support initiators that use ACA - that absence
of
  >>    >  ACA support will be detected quickly at the SCSI level, as the
first
  >>    >  SCSI command that sets the NACA bit in the CONTROL byte in the
  CDB
  >>    >  will get hit with a CHECK CONDITION for having done so.
  >>    >
  >>    >  Thanks,
  >>    >  --David
  >>    >
  >>    >>  -----Original Message-----
  >>    >>  From: [e-mail] [mailto:[e-mail]]
  On
  >>    >>  Behalf Of Julian Satran
  >>    >>  Sent: Sunday, August 28, 2011 1:15 AM
  >>    >>  To: Ralph Weber
  >>    >>  Cc: [e-mail]
  >>    >>  Subject: Re: [storm] WG Last Call comments on consolidated iSCSI
  >>    >>  draft
  >>    >>
  >>    >>  Ralph,
  >>    >>
  >>    >>  I think you caught a nit. Your point is correct - WRT
initiators.
  >>    >>  The SHOULD statement should refer to targets only.  Initiators
that
  >>    >>  are not supporting ACA may have a hard time surviving in the
  same
  >>    >>  environment with initiators that require and support ACA  but
  >> will cause
  >>    no harm to those that require and support it.
  >>    >>
  >>    >>  Julo
  >>    >>  On Aug 28, 2011, at 5:18 AM, Ralph Weber wrote:
  >>    >>
  >>    >>>  I am having a little bit of difficulty following the logic of
the
  >>    >>>  proposed new text.
  >>    >>>
  >>    >>>  First it says that some initiator implementations use ACA
(which
  >>    >>>  implies that some do not). Then, it says that iSCSI initiators
  >>    >>>  (presumably all iSCSI initiators) ... SHOULD support ACA.
  >>    >>>
  >>    >>>  I can understand why initiators that need ACA SHOULD support
it,
  but
  >>    >>>  why should the others bear the burden?
  >>    >>>
  >>    >>>  All the best,
  >>    >>>
  >>    >>>  .Ralph
  >>    >>>
  >>    >>>  On 8/27/2011 5:36 PM, [e-mail] wrote:
  >>    >>>>  <WG chair hat off>
  >>    >>>>
  >>    >>>>  In that case, let's at least get the explanation for the
  >> SHOULD right ;-).
  >>    >>>>
  >>    >>>>  Here's a suggestion ...
  >>    >>>>
  >>    >>>>  OLD
  >>    >>>>     ACA helps preserve ordered command execution in the
  presence of
  >>    >>>>     errors. As iSCSI can have many commands in-flight between
  >>    >>>>     initiator and target, iSCSI initiators and targets SHOULD
  support
  >>    >>>>     ACA.
  >>    >>>>  NEW
  >>    >>>>     Some SCSI initiator implementations use ACA to enforce
  ordered
  >>    >>>>     command execution during recovery from errors.  In order to
  >>    support
  >>    >>>>     error recovery in such SCSI initiators, iSCSI initiators
and
  >> targets
  >>    >>>>     SHOULD support ACA.
  >>    >>>>
  >>    >>>>  Thanks,
  >>    >>>>  --David
  >>    >>>>
  >>    >>>>>  -----Original Message-----
  >>    >>>>>  From: Knight, Frederick [mailto:[e-mail]]
  >>    >>>>>  Sent: Friday, August 26, 2011 8:51 AM
  >>    >>>>>  To: Black, David
  >>    >>>>>  Cc: [e-mail]
  >>    >>>>>  Subject: RE: [storm] WG Last Call comments on consolidated
  iSCSI
  >>    >>>>>  draft
  >>    >>>>>
  >>    >>>>>  I disagree.
  >>    >>>>>
  >>    >>>>>  1) while not common, the hosts that use it, do need it;
  >>    >>>>>  2) the original 3720 text contains a SHOULD; and
  >>    >>>>>  3) there is no good reason for us to be weakening this
  statement.
  >>    >>>>>
  >>    >>>>>  	Fred Knight
  >>    >>>>>  	NetApp
  >>    >>>>>
  >>    >>>>>  -----Original Message-----
  >>    >>>>>  From: [e-mail] [mailto:[e-mail]]
  >>    >>>>>  Sent: Thursday, August 25, 2011 5:55 PM
  >>    >>>>>  To: [e-mail]
  >>    >>>>>  Subject: [storm] WG Last Call comments on consolidated iSCSI
  draft
  >>    >>>>>
  >>    >>>>>  <...text removed...>
  >>    >>>>>
  >>    >>>>>  [D] Section 10.2 contains a "SHOULD" requirement for ACA
  >>    >>>>>  (Auto-Contingent Allegiance) support.
  >>    >>>>>  As ACA support in SCSI initiators is not common, I suggest
  >>    >>>>>  weakening this to a MAY requirement.
  >>    >>>>>
  >>    >>>>>
  >>    >>>>  _______________________________________________
  >>    >>>>  storm mailing list
  >>    >>>>  [e-mail]
  >>    >>>>  https://www.ietf.org/mailman/listinfo/storm
  >>    >>>>
  >>    >>>>
  >>    >>>  _______________________________________________
  >>    >>>  storm mailing list
  >>    >>>  [e-mail]
  >>    >>>  https://www.ietf.org/mailman/listinfo/storm
  >>    >>  _______________________________________________
  >>    >>  storm mailing list
  >>    >>  [e-mail]
  >>    >>  https://www.ietf.org/mailman/listinfo/storm
  >>    >
  >>    >
  >>    _______________________________________________
  >>    storm mailing list
  >>    [e-mail]
  >>    https://www.ietf.org/mailman/listinfo/storm
  >>
  >> _______________________________________________
  >> storm mailing list
  >> [e-mail]
  >> https://www.ietf.org/mailman/listinfo/storm
  > _______________________________________________
  > storm mailing list
  > [e-mail]
  > https://www.ietf.org/mailman/listinfo/storm
  >
  >
  _______________________________________________
  storm mailing list
  [e-mail]
  https://www.ietf.org/mailman/listinfo/storm