Re: [storm] SPC-2 reserve/release text - version 7 (final, I hope)

["Black, David" <[e-mail]>]

Both changes are fine with me.

Thanks, --David +++Sent from Blackberry

----- Original Message -----
From: Mallikarjun Chadalapaka [mailto:[e-mail]]
Sent: Friday, September 28, 2012 07:23 PM
To: Black, David; [e-mail] <[e-mail]>
Subject: RE: SPC-2 reserve/release text - version 7 (final, I hope)

Hi David,

Thanks for diligently driving these text updates . Sorry, but I think we still need a couple of tweaks:

Thinking more about it, I don't think iSCSI protocol spec can place a normative requirement on the overall solution outside of iSCSI. IOW, an iSCSI protocol compliance test cannot really test a "SHOULD NOT" on a SCSI feature usage (or lack thereof). So IMO, this should be a lower-case.

 Change:
 Reserve/release reservations are obsolete [SPC3] and SHOULD NOT be used

To:
  Reserve/release reservations are obsolete [SPC3] and should not be used

And one editorial (because connection failure isn't the only reason for a session failure; "target retention" can be phrased better):

Change:  
- When connection failure causes the iSCSI session to fail, and
      the session is not reinstated or continued, target retention
      of that session's reserve/release reservation state may
      require an initiator to issue a reset (e.g., LOGICAL UNIT RESET,
      see section 11.5) in order to remove that reservation state.

To:
  - Retention of a failed session's reserve/release reservation state by an iSCSI target,
     even after that failed iSCSI session is not reinstated or continued, may
      require an initiator to issue a reset (e.g., LOGICAL UNIT RESET,
      see section 11.5) in order to remove that reservation state. 

Thanks.

Mallikarjun



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Black, David
Sent: Friday, September 28, 2012 9:48 AM
To: [e-mail]
Subject: [storm] SPC-2 reserve/release text - version 7 (final, I hope)

Two more changes (UA text for session reestablishment, persistent recommendations recommendation text), and I think we're finally (!) done ...

-----------------------------------------

[1] For clarity, the following change should be made in
4.4.3.1:

OLD
  That is, it should perform session recovery as
  described in Chapter 6.
NEW
  That is, it should reinstate the session via iSCSI session
  reinstatement (Section 6.3.5) or continue via session
  continuation (Section 6.3.6).
END

[2] Add the following sentence to the end of 4.4.3.1:

   Unit Attention conditions that result from session reestablishment
   indicate whether nexus state was preserved, see Section 6.3.4 of [SAM4].

[3] NEW TEXT:

4.4.3.2. Reservations

  There are two reservation management methods defined in the SCSI
  standards, reserve/release reservations, based on the RESERVE and
  RELEASE commands [SPC2], and persistent reservations, based on the
  PERSISTENT RESERVE IN and PERSISTENT RESERVE OUT commands [SPC3].
  Reserve/release reservations are obsolete [SPC3] and SHOULD NOT be
  used; persistent reservations are suggested as an alternative,
  see Annex B of [SPC4].

  State for persistent reservations is required to persist
  through changes and failures at the iSCSI layer that result in
  I_T Nexus failures, see [SPC3] for details and specific requirements.

  In contrast, [SPC2] does not specify detailed persistence
  requirements for reserve/release reservation state after an I_T
  Nexus failure.  Nonetheless, when reserve/release reservations are
  supported by an iSCSI target, the preferred implementation approach
  is to preserve reserve/release reservation state for iSCSI session
  reinstatement (see Section 6.3.5) or session continuation
  (see Section 6.3.6).

  Two additional caveats apply to reserve/release reservations:

  - When connection failure causes the iSCSI session to fail, and
      the session is not reinstated or continued, target retention
      of that session's reserve/release reservation state may
      require an initiator to issue a reset (e.g., LOGICAL UNIT RESET,
      see section 11.5) in order to remove that reservation state.

  - Reserve/release reservations may not behave as expected when
      persistent reservations are also used on the same logical unit;
      see the discussion of "Exceptions to SPC-2 RESERVE and RELEASE
      behavior" in [SPC4].

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

_______________________________________________
storm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/storm