Subject: Re: [storm] Plan for iSCSI work

From: "Hemal Shah" <[email-masked]>
Date: Thu, 9 Jun 2011 15:56:38 -0700

Thanks Mallikarjun!

The way I read Section 4.1.3 of RFC5048 and Section 4.2.3.4 of the consolidated draft, the implementation of "FastAbort" feature is a MUST. From the first paragraph text from Section 4.1.3 of RFC5048, the first sentence mandates that all iSCSI implementation comply to this section but the second sentence say that the requirement in this section is conditional to the negotiation of "FastAbort" key.

Protocol behavior defined in this section MUST be implemented by all iSCSI implementations complying with this document. Protocol behavior defined in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (Section 9.1) key to "FastAbort" on that session.

This is confusing. I think it will be better to remove the first sentence from 4.2.3.4 and clarify that the requirements in this section is conditional. I suggest rewording the first two sentences to below:

iSCSI implementations may negotiate the TaskReporting (Section 9.1) key to "FastAbort" on an iSCSI session. Protocol behavior
defined in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (Section 9.1) key to "FastAbort" on that session.

Hemal

-----Original Message-----
From: Mallikarjun Chadalapaka [mailto:[email-masked]]
Sent: Friday, May 27, 2011 5:29 PM
To: Hemal Shah; [email-masked]; [email-masked]
Subject: RE: [storm] Plan for iSCSI work

Hi Hemal,

The text in this draft came verbatim from section 4.1.3 of RFC 5048.  There
have been no changes in this area.

The new text (as well as the old text) requires the TaskReporting key to be
negotiated to "FastAbort" before the multi-task abort semantics can be used
on an iSCSI session.

Thanks.

Mallikarjun

  -----Original Message-----
  From: Hemal Shah [mailto:[email-masked]]
  Sent: Friday, May 27, 2011 4:51 PM
  To: Mallikarjun Chadalapaka; [email-masked]; [email-masked]
  Subject: RE: [storm] Plan for iSCSI work

  Mallikarjun and David,

  I noticed one problematic item in the consolidated draft. This item is the
  requirement to support FastAbort. This feature was already defined in the
  implementation guide, but it was optional. In this draft, it became a
  required feature MUST - see in section 4.2.3.4.

  Do you know why the requirement was changed in the consolidated draft?

  I would like to keep the requirement optional as stated in the
  implementation guide and not break backward compatibility.

  Hemal

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]] On Behalf
  Of Mallikarjun Chadalapaka
  Sent: Thursday, May 26, 2011 6:50 PM
  To: [email-masked]; [email-masked]
  Subject: Re: [storm] Plan for iSCSI work

  Hi David,

  The list of changes you have called out are already done in the latest
draft.  I
  assume then that you are suggesting that the list itself should be
included
  in the next revision of the draft.

  Here's what I recall we have done so far:
  1)  iSCSIProtocolLevel specified as "1", and added a related normative
  reference to iSCSI-SAM draft
  2)  Markers and related keys were removed
  3)  SPKM authentication and related keys were removed
  4)  Added a new section on responding to obsoleted keys
  5)  Have explicitly allowed initiator+target implementations throughout
the
  text
  6)  Clarified that implementations SHOULD NOT rely on SLP-based discovery
  7)  Added UML diagrams, and related conventions

  The above is of course in addition to consolidating the different RFCs,
and
  making the related editorial changes.

  Thanks.

  Mallikarjun

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]] On Behalf
    Of [email-masked]
    Sent: Friday, May 20, 2011 2:49 PM
    To: [email-masked]
    Subject: [storm] Plan for iSCSI work

    I thought I'd offer some advance planning/warning on this, as the
    consolidated iSCSI draft (draft-ietf-storm-iscsi-cons) is large (over
300
    pages).  The current plan is to run a simultaneous WG Last Call on both
  this
    draft and the new features draft (draft-ietf-storm-iscsi-sam) starting
in
  mid-
    June (probably the week of June 13, after I get back from a badly needed
    vacation).  That WG Last Call will run longer than the typical 2-week
time
    period, due to the total size of the drafts, but will end by July 5th at
the
    latest so that the status of the drafts and the next steps are known
prior
  to
    the T10 (SCSI standards) meetings during the week of July 11.  As July
11th
    is also the draft cutoff deadline for the Quebec City IETF meetings,
revised
    draft versions may not show up until that meeting week (week of July
    24th).

    This is also a good point to announce that the storm WG will meet in
    Quebec City.
    I've only requested a 1-hour session, as we get most of our work done on
    the mailing list.  Among the items for that meeting will be figuring out
  what
    to do with the RDMA extensions draft (despite its name,
draft-ietf-storm-
    rdmap-ext-00, it's not currently an official work item for the storm
WG).

    One thing that's missing from the consolidated iSCSI draft (and is a
reason
    why we're going to need a -03 version) is the changes that it makes to
the
    RFCs that it consolidates.  Off the top of my head, the major changes
are:
        - Removal of SPKM authentication
        - Removal of the Marker appendix
        - Removal of the SHOULD requirement for SLP implementation.
    Have I missed anything significant?  The summary of this will need to be
    added to that draft.

    WG Last Call will be an opportunity (in fact the final opportunity) to
  discuss
    whether anything else should be removed from iSCSI, but there's no need
    to wait
    - I encourage people to review both drafts and post comments whenever
    they can.

    In parallel, work will get started on any iSCSI MIB changes that are
needed.
    So far, I only see one MIB change - the iSCSIProtocolLevel from the new
    features draft needs to be added to the MIB, probably with a structure
    analogous to the iSCSI version support that's already in the MIB.

    Thanks,
    --David (storm WG co-chair)
    ----------------------------------------------------
    David L. Black, Distinguished Engineer
    EMC Corporation, 176 South St., Hopkinton, MA  01748
    +1 (508) 293-7953             FAX: +1 (508) 293-7786
    [email-masked]        Mobile: +1 (978) 394-7754
    ----------------------------------------------------

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

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

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Fri, 17 Jun 2011 15:32:12 -0700

Hi Hemal,

During RFC 5048 effort, I recall we settled on the “MUST implement, but MUST
negotiate” formulation after some list deliberation.  

With plain RFC 3720 semantics, there are some multi-initiator scenarios
where multi-task aborts could essentially lead to target deadlocks, waiting
on initiators on third-party sessions that may never respond.  With the
“Clarified” semantics in RFC 5048, the third-party deadlocks aren’t a
problem anymore, but issuing initiator could still experience timeouts and
escalate error recovery – depending on the number of LUs, sessions,
connections and tasks affected with the issued TMF.    Escalated error
recovery is usually something we want to avoid as it adds more
delays/alerts/logs/failovers/failbacks etc.  Finally, “Updated” semantics in
RFC 5048 are meant to address this timeout problem – they permit targets to
provide accelerated responses and allow them to deal with
book-keeping/quiescing operations in a lazy fashion (which are the real
culprits that trigger timeouts).  

Given all the above, the WG settled on FastAbort as a MUST-implement.  The
"MUST negotiate" part then is to enable backwards-compatibility with RFC
3720 implementations.  At this point, I'd rather not loosen the Consolidated
iSCSI draft requirement from what it is in RFC 5048.  I suggest we leave it
the way it is.

Mallikarjun

From: Hemal Shah [mailto:[email-masked]] 
Sent: Thursday, June 09, 2011 3:57 PM
To: Mallikarjun Chadalapaka; [email-masked]; [email-masked]
Subject: RE: [storm] Plan for iSCSI work

Thanks Mallikarjun!
 
The way I read Section 4.1.3 of RFC5048 and Section 4.2.3.4 of the
consolidated draft, the implementation of "FastAbort" feature is a MUST.
>From the first paragraph text from Section 4.1.3 of RFC5048, the first
sentence mandates that all iSCSI implementation comply to this section but
the second sentence say that the requirement in this section is conditional
to the negotiation of "FastAbort" key. 
 
Protocol behavior defined in this section MUST be implemented by all iSCSI
implementations complying with this document. Protocol behavior defined in
this section MUST be exhibited by iSCSI implementations on an iSCSI session
when they negotiate the TaskReporting (Section 9.1) key to "FastAbort" on
that session.

This is confusing. I think it will be better to remove the first sentence
from 4.2.3.4 and clarify that the requirements in this section is
conditional. I suggest rewording the first two sentences to below:
 
       iSCSI implementations may negotiate the TaskReporting (Section 9.1)
key to "FastAbort" on an iSCSI session. Protocol behavior
defined in this section MUST be exhibited by iSCSI implementations on an
iSCSI session when they negotiate the TaskReporting (Section 9.1) key to
"FastAbort" on that session.
 
Hemal

-----Original Message-----
From: Mallikarjun Chadalapaka [mailto:[email-masked]] 
Sent: Friday, May 27, 2011 5:29 PM
To: Hemal Shah; [email-masked]; [email-masked]
Subject: RE: [storm] Plan for iSCSI work
 
Hi Hemal,

 
Thanks.
 
Mallikarjun

 
  -----Original Message-----
 
  Mallikarjun and David,

 
 
  Hemal
 
  -----Original Message-----
 
  Hi David,

 
 
  Thanks.
 
  Mallikarjun

 
    -----Original Message-----

 

 
    Thanks,

---

From: "Hemal Shah" <[email-masked]>
Date: Tue, 28 Jun 2011 11:32:39 -0700

Thanks Mallikarjun! I would still like to confirm my understanding of what you describe as "MUST implement, but MUST negotiate".

Here is my understanding:

1.      The implementation of TaskReporting is required and NotUnderstood response for TaskReporting key is not permitted based on the following text from RFC5048 and Section 6.2 of the consolidated draft:
                All keys defined in [RFC3720] MUST be supported by all
            compliant implementations; a NotUnderstood answer on any of the
            [RFC3720] keys therefore MUST be considered a protocol error and
            handled accordingly.
2.      To enable FastAbort on a session, the negotiation of TaskReporting key is required.
3.      Only when the TaskReporting=FastAbort functionality is supported, the protocol behavior specified in Section 4.2.3.4 is required to be implemented and exhibited. There are several places in the spec that indicate this type of conditionality.
a.      Section 4.2.3.5: If an iSCSI target implementation is capable of supporting
TaskReporting=FastAbort functionality (Section 13.23)...
b.      Section 4.2.2.3.3: Whenever the TaskReporting key (Section 12.23 "Task Reporting") is negotiated to ResponseFence or FastAbort for an iSCSI session...
c.      Section 4.2.2.3.4: Whenever the TaskReporting key (Section 13.23) is negotiated to ResponseFence or FastAbort for an iSCSI session...
4.      If TaskReporting=FastAbort functionality is not supported, then the protocol behavior specified in Section 4.2.3.4 is not required to be implemented or exhibited. If this is true, then the first sentence in section 4.2.3.4 is misleading and should be removed or prefixed with some text like "Only when the TaskReporting=FastAbort functionality is supported..".

Hemal

-----Original Message-----
From: Mallikarjun Chadalapaka [mailto:[email-masked]]
Sent: Friday, June 17, 2011 3:32 PM
To: Hemal Shah; [email-masked]; [email-masked]
Subject: RE: [storm] Plan for iSCSI work

Hi Hemal,

During RFC 5048 effort, I recall we settled on the "MUST implement, but MUST
negotiate" formulation after some list deliberation.

With plain RFC 3720 semantics, there are some multi-initiator scenarios
where multi-task aborts could essentially lead to target deadlocks, waiting
on initiators on third-party sessions that may never respond.  With the
"Clarified" semantics in RFC 5048, the third-party deadlocks aren't a
problem anymore, but issuing initiator could still experience timeouts and
escalate error recovery - depending on the number of LUs, sessions,
connections and tasks affected with the issued TMF.    Escalated error
recovery is usually something we want to avoid as it adds more
delays/alerts/logs/failovers/failbacks etc.  Finally, "Updated" semantics in
RFC 5048 are meant to address this timeout problem - they permit targets to
provide accelerated responses and allow them to deal with
book-keeping/quiescing operations in a lazy fashion (which are the real
culprits that trigger timeouts).

Mallikarjun

Thanks Mallikarjun!

Hemal

-----Original Message-----
From: Mallikarjun Chadalapaka [mailto:[email-masked]]
Sent: Friday, May 27, 2011 5:29 PM
To: Hemal Shah; [email-masked]; [email-masked]
Subject: RE: [storm] Plan for iSCSI work

Hi Hemal,

Thanks.

Mallikarjun

  -----Original Message-----
  From: Hemal Shah [mailto:[email-masked]]
  Sent: Friday, May 27, 2011 4:51 PM
  To: Mallikarjun Chadalapaka; [email-masked]; [email-masked]
  Subject: RE: [storm] Plan for iSCSI work

  Mallikarjun and David,

  Hemal

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]] On Behalf
  Of Mallikarjun Chadalapaka
  Sent: Thursday, May 26, 2011 6:50 PM
  To: [email-masked]; [email-masked]
  Subject: Re: [storm] Plan for iSCSI work

  Hi David,

  Thanks.

  Mallikarjun

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]] On Behalf
    Of [email-masked]
    Sent: Friday, May 20, 2011 2:49 PM
    To: [email-masked]
    Subject: [storm] Plan for iSCSI work

    Thanks,

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Wed, 29 Jun 2011 15:15:56 -0700

Hi Hemal,

>1.	The implementation of TaskReporting is required and NotUnderstood
response for TaskReporting key is not permitted

No.  Note that TaskReporting is not defined in RFC 3720.  Patrick MacArthur
proposed on this list a couple of weeks ago that we should fix this
disconnect in the consolidated draft - which I agreed with because I think
it's a good suggestion.  

 >2.	To enable FastAbort on a session, the negotiation of TaskReporting
key is required.

Correct, specifically "TaskReporting=FastAbort" must be negotiated.

>3.	Only when the TaskReporting=FastAbort functionality is supported,
the protocol behavior specified in Section 4.2.3.4 is required to be
implemented and exhibited.

If I were to attempt re-writing your idea, I would say:

When the protocol behavior specified in Section 4.2.3.4 is implemented and
TaskReporting=FastAbort is operational on a session, then the FastAbort
functionality is supported/exhibited on that session by the implementation.

>TaskReporting=FastAbort functionality (Section 13.23).
 
"Supporting" = implemented and negotiated to "TaskReporting=FastAbort".
Note that if even if an implementation has implemented this functionality
and wants to use it, it will not be able to negotiate it on any session if
it's only communicating with a bunch of RFC 3720 implementations.  

 >b.	Section 4.2.2.3.3: Whenever the TaskReporting key (Section 12.23
"Task Reporting") is negotiated to ResponseFence or FastAbort for an iSCSI
session.
>c.	Section 4.2.2.3.4: Whenever the TaskReporting key (Section 13.23) is
negotiated to ResponseFence or FastAbort for an iSCSI session.

I don't see an issue.  Note that the discussion in these two sections is on
response fencing, not fast abort per se.

>4.	...prefixed with some text like "Only when the
TaskReporting=FastAbort functionality is supported..".

Please see the above responses.  Your wording is vague for me, as I don't
comprehend a standalone notion of "supporting" a feature, other than
implementing a feature and negotiating the feature usage.   Current RFC 5048
requirement is that implementation is MUST, and negotiation is MUST (may
result in the feature to be used, or not).  So as such, there is already
ample flexibility for implementations.  

I think you are restating your earlier suggestion to loosen the "MUST
implement" requirement in RFC5048.  And I've already shared how I feel about
it, :)  I think it would be a step in the wrong direction, when faster error
recovery with multi-task aborts with large # of sessions/LUs/initiators is
even more critical, due to increased consolidation in data centers.  

At this point, I think it would be good to also hear from the rest of the
list.

Thanks.

Mallikarjun

>Thanks Mallikarjun! I would still like to confirm my understanding of what
you describe as "MUST implement, but MUST negotiate".
>1.	The implementation of TaskReporting is required and NotUnderstood
response for TaskReporting key is not permitted based on the following text
from RFC5048 and Section 6.2 of the consolidated draft:
>3.	Only when the TaskReporting=FastAbort functionality is supported,
the protocol behavior specified in Section 4.2.3.4 is required to be
implemented and exhibited. There are several places in the spec that
indicate this type of conditionality.
>TaskReporting=FastAbort functionality (Section 13.23).
>b.	Section 4.2.2.3.3: Whenever the TaskReporting key (Section 12.23
"Task Reporting") is negotiated to ResponseFence or FastAbort for an iSCSI
session.
>c.	Section 4.2.2.3.4: Whenever the TaskReporting key (Section 13.23) is
negotiated to ResponseFence or FastAbort for an iSCSI session.
>4.	If TaskReporting=FastAbort functionality is not supported, then the
protocol behavior specified in Section 4.2.3.4 is not required to be
implemented or exhibited. If this is true, then the first sentence in
section 4.2.3.4 is misleading and should be removed or prefixed with some
text like "Only when the TaskReporting=FastAbort functionality is
supported..".

---

From: "Pat Thaler" <[email-masked]>
Date: Wed, 29 Jun 2011 16:02:35 -0700

Hi Malikarjun,

10.7 in the consolidated draft says that FastAbort is a SHOULD: "Therefore, both iSCSI target and initiator implementations SHOULD support FastAbort multi-task abort semantics (Section 4.2.3.4)."

When 4.2.3.5 saying "If an iSCSI target implementation is capable of supporting TaskReporting=FastAbort functionality" implies that the implementation was allowed to not implement FastAbort. You might interpret "supporting" = (implemented and negotiated to TaskAbort) as you say below, but "capable of supporting" still reads as implemented. When the standard puts an if in front of that, it implies that an implementation is allowed to be not capable of supporting FastAbort.

Neither of these is consistent with MUST implement for FastAbort. The rationale for requiring FastAbort doesn't seem strong and I'd prefer that the inconsistency be resolved by not requiring its implementation.

Regards,
Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mallikarjun Chadalapaka
Sent: Wednesday, June 29, 2011 3:16 PM
To: Hemal Shah; [email-masked]; [email-masked]
Subject: Re: [storm] Plan for iSCSI work

Hi Hemal,

Thanks.

Mallikarjun

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Thu, 30 Jun 2011 11:06:08 -0700

Hi Pat,

Thanks for flagging the inconsistency in 10.7, that's a good catch.  Given
that and your/Hemal's feedback, I think turning the current MUST into a
SHOULD is probably the right resolution.   That syncs them both to SHOULD.
Unless I see other comments, I will get this into the next revision.

Thanks.

Mallikarjun

  -----Original Message-----
  From: Pat Thaler [mailto:[email-masked]]
  Sent: Wednesday, June 29, 2011 4:03 PM
  To: Mallikarjun Chadalapaka; Hemal Shah; [email-masked];
  [email-masked]
  Subject: RE: [storm] Plan for iSCSI work
  
  Hi Malikarjun,
  
  10.7 in the consolidated draft says that FastAbort is a SHOULD:
"Therefore,
  both iSCSI target and initiator implementations SHOULD support FastAbort
  multi-task abort semantics (Section 4.2.3.4)."
  
  When 4.2.3.5 saying "If an iSCSI target implementation is capable of
  supporting TaskReporting=FastAbort functionality" implies that the
  implementation was allowed to not implement FastAbort. You might
  interpret "supporting" = (implemented and negotiated to TaskAbort) as you
  say below, but "capable of supporting" still reads as implemented. When
  the standard puts an if in front of that, it implies that an
implementation is
  allowed to be not capable of supporting FastAbort.
  
  Neither of these is consistent with MUST implement for FastAbort. The
  rationale for requiring FastAbort doesn't seem strong and I'd prefer that
the
  inconsistency be resolved by not requiring its implementation.
  
  Regards,
  Pat
  
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]] On Behalf
  Of Mallikarjun Chadalapaka
  Sent: Wednesday, June 29, 2011 3:16 PM
  To: Hemal Shah; [email-masked]; [email-masked]
  Subject: Re: [storm] Plan for iSCSI work
  
  Hi Hemal,

  No.  Note that TaskReporting is not defined in RFC 3720.  Patrick
MacArthur
  proposed on this list a couple of weeks ago that we should fix this
  disconnect in the consolidated draft - which I agreed with because I think
  it's a good suggestion.

  

  When the protocol behavior specified in Section 4.2.3.4 is implemented and
  TaskReporting=FastAbort is operational on a session, then the FastAbort
  functionality is supported/exhibited on that session by the
implementation.

  "Supporting" = implemented and negotiated to "TaskReporting=FastAbort".
  Note that if even if an implementation has implemented this functionality
  and wants to use it, it will not be able to negotiate it on any session if
it's
  only communicating with a bunch of RFC 3720 implementations.

  I don't see an issue.  Note that the discussion in these two sections is
on
  response fencing, not fast abort per se.

  Please see the above responses.  Your wording is vague for me, as I don't
  comprehend a standalone notion of "supporting" a feature, other than
  implementing a feature and negotiating the feature usage.   Current RFC
  5048
  requirement is that implementation is MUST, and negotiation is MUST
  (may result in the feature to be used, or not).  So as such, there is
already
  ample flexibility for implementations.
  
  I think you are restating your earlier suggestion to loosen the "MUST
  implement" requirement in RFC5048.  And I've already shared how I feel
  about it, :)  I think it would be a step in the wrong direction, when
faster
  error recovery with multi-task aborts with large # of
sessions/LUs/initiators
  is even more critical, due to increased consolidation in data centers.

  Thanks.
  
  Mallikarjun

  >1.     The implementation of TaskReporting is required and NotUnderstood
  response for TaskReporting key is not permitted based on the following
text
  from RFC5048 and Section 6.2 of the consolidated draft:
  >            [RFC3720] keys therefore MUST be considered a protocol
  > error
  and
  protocol behavior specified in Section 4.2.3.4 is not required to be
  implemented or exhibited. If this is true, then the first sentence in
section
  4.2.3.4 is misleading and should be removed or prefixed with some text
like
  "Only when the TaskReporting=FastAbort functionality is supported..".
  >where multi-task aborts could essentially lead to target deadlocks,
  >waiting on initiators on third-party sessions that may never respond.
  >With the "Clarified" semantics in RFC 5048, the third-party deadlocks
  >aren't a problem anymore, but issuing initiator could still experience
  >timeouts and escalate error recovery - depending on the number of LUs,
  sessions,
  >delays/alerts/logs/failovers/failbacks etc.  Finally, "Updated"
  >semantics
  in
  >RFC 5048 are meant to address this timeout problem - they permit
  >targets to provide accelerated responses and allow them to deal with
  >Given all the above, the WG settled on FastAbort as a MUST-implement.
  >The "MUST negotiate" part then is to enable backwards-compatibility
  >with RFC
  >iSCSI draft requirement from what it is in RFC 5048.  I suggest we
  >leave it the way it is.
  >
  >Mallikarjun
  >
  >
  >
  >
  >
  >
  >sentence mandates that all iSCSI implementation comply to this section
  >but the second sentence say that the requirement in this section is
  >conditional to the negotiation of "FastAbort" key.
  >
  >Protocol behavior defined in this section MUST be implemented by all
  >iSCSI implementations complying with this document. Protocol behavior
  >defined in this section MUST be exhibited by iSCSI implementations on
  >an iSCSI session when they negotiate the TaskReporting (Section 9.1)
  >key to "FastAbort" on that session.
  >
  >
  >This is confusing. I think it will be better to remove the first
  >sentence from 4.2.3.4 and clarify that the requirements in this section
  >is conditional. I suggest rewording the first two sentences to below:
  >
  >       iSCSI implementations may negotiate the TaskReporting (Section
  >9.1) key to "FastAbort" on an iSCSI session. Protocol behavior defined
  >in this section MUST be exhibited by iSCSI implementations on an iSCSI
  >session when they negotiate the TaskReporting (Section 9.1) key to
  >The text in this draft came verbatim from section 4.1.3 of RFC 5048.
  >There have been no changes in this area.
  >
  >The new text (as well as the old text) requires the TaskReporting key
  >to be negotiated to "FastAbort" before the multi-task abort semantics
  >can be used on an iSCSI session.
  >
  >Thanks.
  >
  >Mallikarjun
  >
  >
  >
  >
  >  I noticed one problematic item in the consolidated draft. This item
  > is
  the
  >  requirement to support FastAbort. This feature was already defined in
  > the  implementation guide, but it was optional. In this draft, it
  > became a  required feature MUST - see in section 4.2.3.4.
  >
  >  The list of changes you have called out are already done in the
  >latest draft.  I
  >  5)  Have explicitly allowed initiator+target implementations
  >throughout the
  >  text
  >  The above is of course in addition to consolidating the different
  >RFCs, and
  >    draft and the new features draft (draft-ietf-storm-iscsi-sam)
  >starting in
  >  mid-
  >    vacation).  That WG Last Call will run longer than the typical
  >2-week time
  >    period, due to the total size of the drafts, but will end by July
  >5th
  at
  >the
  >    latest so that the status of the drafts and the next steps are
  >known prior
  >  to
  >    the T10 (SCSI standards) meetings during the week of July 11.  As
  >July 11th
  >    is also the draft cutoff deadline for the Quebec City IETF
  >meetings, revised
  >    I've only requested a 1-hour session, as we get most of our work
  > done
  on
  >    the mailing list.  Among the items for that meeting will be
  > figuring
  out
  >    rdmap-ext-00, it's not currently an official work item for the
  >storm WG).
  >
  >    One thing that's missing from the consolidated iSCSI draft (and is
  >a reason
  >    why we're going to need a -03 version) is the changes that it makes
  >to the
  >    Have I missed anything significant?  The summary of this will need
  >to
  be
  >    added to that draft.
  >
  >    WG Last Call will be an opportunity (in fact the final opportunity)
  > to  discuss
  >    In parallel, work will get started on any iSCSI MIB changes that
  >are needed.

---

From: "Hemal Shah" <[email-masked]>
Date: Thu, 30 Jun 2011 11:08:43 -0700

Thanks Mallikarjun!

Hemal

-----Original Message-----
From: Mallikarjun Chadalapaka [mailto:[email-masked]]
Sent: Thursday, June 30, 2011 11:06 AM
To: Pat Thaler; Hemal Shah; [email-masked]; [email-masked]
Subject: RE: [storm] Plan for iSCSI work

Hi Pat,

Thanks.

Mallikarjun

  -----Original Message-----
  From: Pat Thaler [mailto:[email-masked]]
  Sent: Wednesday, June 29, 2011 4:03 PM
  To: Mallikarjun Chadalapaka; Hemal Shah; [email-masked];
  [email-masked]
  Subject: RE: [storm] Plan for iSCSI work

  Hi Malikarjun,

  Regards,
  Pat

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]] On Behalf
  Of Mallikarjun Chadalapaka
  Sent: Wednesday, June 29, 2011 3:16 PM
  To: Hemal Shah; [email-masked]; [email-masked]
  Subject: Re: [storm] Plan for iSCSI work

  Hi Hemal,

  Thanks.

  Mallikarjun

  and
  sessions,
  in
  the
  at
  on
  out
  be

---

From: <[email-masked]>
Date: Thu, 30 Jun 2011 16:22:31 -0400

<WG chair hat off> I think use of "SHOULD" is the right approach here. </WG chair hat off>

<WG chair hat on> Based on list discussion, I believe "SHOULD" is the rough consensus of the WG. </WG chair hat on>

Thanks,
--David

> Sent: Thursday, June 30, 2011 2:09 PM
> To: Mallikarjun Chadalapaka; Pat Thaler; Black, David; [email-masked]