draft-ietf-ips-iscsi-impl-guide-02.txt   draft-ietf-ips-iscsi-impl-guide-03.txt 
INTERNET DRAFT Mallikarjun Chadalapaka INTERNET DRAFT Mallikarjun Chadalapaka
draft-ietf-ips-iscsi-impl-guide-02.txt Hewlett-Packard Co. draft-ietf-ips-iscsi-impl-guide-03.txt Hewlett-Packard Co.
Editor Editor
Expires September 2006
iSCSI Implementer's Guide iSCSI Implementer's Guide
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents By submitting this Internet-Draft, each author represents
that any applicable patent or other IPR claims of which he or that any applicable patent or other IPR claims of which he or
she is aware have been or will be disclosed, and any of which she is aware have been or will be disclosed, and any of which
he or she becomes aware will be disclosed, in accordance with he or she becomes aware will be disclosed, in accordance with
Section 6 of BCP 79. Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
skipping to change at page 2, line 31 skipping to change at page 2, line 31
4.1 Requests Affecting Multiple Tasks .....................12 4.1 Requests Affecting Multiple Tasks .....................12
4.1.1 Scope of affected tasks..............................12 4.1.1 Scope of affected tasks..............................12
4.1.2 Clarified multi-task abort semantics.................12 4.1.2 Clarified multi-task abort semantics.................12
4.1.3 Updated multi-task abort semantics...................14 4.1.3 Updated multi-task abort semantics...................14
4.1.4 Rationale behind the new semantics...................16 4.1.4 Rationale behind the new semantics...................16
5 Discovery semantics ...................................18 5 Discovery semantics ...................................18
5.1 Error Recovery for Discovery Sessions .................18 5.1 Error Recovery for Discovery Sessions .................18
5.2 Reinstatement Semantics of Discovery Sessions .........18 5.2 Reinstatement Semantics of Discovery Sessions .........18
5.2.1 Unnamed Discovery Sessions...........................19 5.2.1 Unnamed Discovery Sessions...........................19
5.2.2 Named Discovery Sessions.............................19 5.2.2 Named Discovery Sessions.............................19
5.3 TPGT Values ...........................................20 6 Negotiation and Others ................................20
5.4 Session type negotiation ..............................20 6.1 TPGT Values ...........................................20
6 iSCSI Error Handling and Recovery .....................21 6.2 Session type negotiation ..............................20
6.1 ITT ...................................................21 6.3 Understanding NotUnderstood ...........................20
6.2 Format Errors .........................................21 7 iSCSI Error Handling and Recovery .....................22
6.3 Digest Errors .........................................21 7.1 ITT ...................................................22
7 iSCSI PDUs ............................................23 7.2 Format Errors .........................................22
7.1 Asynchronous Message ..................................23 7.3 Digest Errors .........................................22
8 Login/Text Operational Text Keys ......................24 8 iSCSI PDUs ............................................24
8.1 FastMultiTaskAbort ....................................24 8.1 Asynchronous Message ..................................24
9 Security Considerations ...............................25 9 Login/Text Operational Text Keys ......................25
10 IANA Considerations ...................................26 9.1 FastMultiTaskAbort ....................................25
11 References and Bibliography ...........................27 10 Security Considerations ...............................26
11.1 Normative References.................................27 11 IANA Considerations ...................................27
11.2 Informative References...............................27 12 References and Bibliography ...........................28
12 Editor's Address ......................................28 12.1 Normative References.................................28
13 Acknowledgements ......................................29 12.2 Informative References...............................28
14 Full Copyright Statement ..............................30 13 Editor's Address ......................................29
15 Intellectual Property Statement .......................31 14 Acknowledgements ......................................30
15 Full Copyright Statement ..............................31
16 Intellectual Property Statement .......................32
1 Definitions and acronyms 1 Definitions and acronyms
1.1 Definitions 1.1 Definitions
I/O Buffer A buffer that is used in a SCSI Read or Write I/O Buffer A buffer that is used in a SCSI Read or Write
operation so SCSI data may be sent from or received into operation so SCSI data may be sent from or received into
that buffer. For a read or write data transfer to take that buffer. For a read or write data transfer to take
place for a task, an I/O Buffer is required on the place for a task, an I/O Buffer is required on the
initiator and at least one required on the target. initiator and at least one required on the target.
skipping to change at page 11, line 10 skipping to change at page 11, line 10
sessions. sessions.
5. The TMF Response carrying the Clear ACA response on the 5. The TMF Response carrying the Clear ACA response on the
issuing session. issuing session.
Note: Due to the absence of ACA-related fencing requirements in Note: Due to the absence of ACA-related fencing requirements in
[RFC3720], initiator implementations SHOULD NOT use ACA on [RFC3720], initiator implementations SHOULD NOT use ACA on
multi-connection iSCSI sessions to targets complying only with multi-connection iSCSI sessions to targets complying only with
[RFC3720], i.e. those not complying with this document. [RFC3720], i.e. those not complying with this document.
Initiators may assess target compliance to this document via Initiators may assess target compliance to this document via
negotiating for FastMultiTaskAbort (section 8.1) key. negotiating for FastMultiTaskAbort (section 9.1) key.
4 Task Management 4 Task Management
4.1 Requests Affecting Multiple Tasks 4.1 Requests Affecting Multiple Tasks
This section clarifies and updates the original text in section This section clarifies and updates the original text in section
10.6.2 of [RFC3720]. The clarified semantics (section 4.1.2) 10.6.2 of [RFC3720]. The clarified semantics (section 4.1.2)
are a superset of the protocol behavior required in the original are a superset of the protocol behavior required in the original
text and all iSCSI implementations MUST support the new text and all iSCSI implementations MUST support the new
behavior. The updated semantics (section 4.1.3) on the other behavior. The updated semantics (section 4.1.3) on the other
hand are mandatory only when the new key FastMultiTaskAbort hand are mandatory only when the new key FastMultiTaskAbort
(section 8.1) is negotiated to "Yes". (section 9.1) is negotiated to "Yes".
4.1.1 Scope of affected tasks 4.1.1 Scope of affected tasks
This section defines the notion of "affected tasks" in multi- This section defines the notion of "affected tasks" in multi-
task abort scenarios. Scope definitions in this section apply task abort scenarios. Scope definitions in this section apply
to both the clarified protocol behavior (section 4.1.2) and the to both the clarified protocol behavior (section 4.1.2) and the
updated protocol behavior (section 4.1.3). updated protocol behavior (section 4.1.3).
ABORT TASK SET: All outstanding tasks for the I_T_L nexus ABORT TASK SET: All outstanding tasks for the I_T_L nexus
identified by the LUN field in the ABORT TASK SET TMF identified by the LUN field in the ABORT TASK SET TMF
skipping to change at page 14, line 11 skipping to change at page 14, line 11
means by which the target ensures that all affected tasks means by which the target ensures that all affected tasks
have returned their status to the initiator are defined by have returned their status to the initiator are defined by
the specific non-iSCSI transport protocol(s). the specific non-iSCSI transport protocol(s).
4.1.3 Updated multi-task abort semantics 4.1.3 Updated multi-task abort semantics
Protocol behavior defined in this section MUST be implemented by Protocol behavior defined in this section MUST be implemented by
all iSCSI implementations complying with this document. all iSCSI implementations complying with this document.
Protocol behavior defined in this section MUST be exhibited by Protocol behavior defined in this section MUST be exhibited by
iSCSI implementations on an iSCSI session when they negotiate iSCSI implementations on an iSCSI session when they negotiate
the FastMultiTaskAbort (section 8.1) key to "Yes" on that the FastMultiTaskAbort (section 9.1) key to "Yes" on that
session. The execution of ABORT TASK SET, CLEAR TASK SET, session. The execution of ABORT TASK SET, CLEAR TASK SET,
LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF
Requests consists of the following sequence of actions in the Requests consists of the following sequence of actions in the
specified order on the specified party. specified order on the specified party.
The initiator iSCSI layer: The initiator iSCSI layer:
a. MUST NOT send any more Data-Out PDUs for affected tasks on a. MUST NOT send any more Data-Out PDUs for affected tasks on
the issuing connection of the issuing iSCSI session once the issuing connection of the issuing iSCSI session once
the TMF is sent to the target. the TMF is sent to the target.
b. Should receive any responses that the target may provide b. Should receive any responses that the target may provide
for some tasks among the affected tasks (may process them for some tasks among the affected tasks (may process them
as usual because they are guaranteed to have as usual because they are guaranteed to have
chronologically originated prior to the TMF response). chronologically originated prior to the TMF response).
c. MUST respond to Async Message PDU with AsyncEvent=5 as c. MUST respond to Async Message PDU with AsyncEvent=5 as
defined in section 7.1. defined in section 8.1.
d. Should receive the TMF Response concluding all the tasks in d. Should receive the TMF Response concluding all the tasks in
the set of affected tasks. the set of affected tasks.
The target iSCSI layer: The target iSCSI layer:
a. MUST wait for all commands of the affected tasks to be a. MUST wait for all commands of the affected tasks to be
received based on the CmdSN ordering on the issuing received based on the CmdSN ordering on the issuing
session. SHOULD NOT wait for new commands on third-party session. SHOULD NOT wait for new commands on third-party
affected sessions - only the instantiated tasks have to be affected sessions - only the instantiated tasks have to be
skipping to change at page 15, line 13 skipping to change at page 15, line 13
"plugged". "plugged".
b. MUST propagate the TMF request to and receive the response b. MUST propagate the TMF request to and receive the response
from the target SCSI layer. from the target SCSI layer.
c. MUST leave all active "affected TTTs" (i.e. active TTTs c. MUST leave all active "affected TTTs" (i.e. active TTTs
associated with affected tasks) valid along with any buffer associated with affected tasks) valid along with any buffer
allocations for the TTTs intact. allocations for the TTTs intact.
d. MUST generate an Asynchronous Message PDU with AsyncEvent=5 d. MUST generate an Asynchronous Message PDU with AsyncEvent=5
(section 7.1) on: (section 8.1) on:
i) each connection of each third-party session that at i) each connection of each third-party session that at
least one affected task is allegiant to, and least one affected task is allegiant to, and
ii) each connection except the non-issuing connection of the ii) each connection except the non-issuing connection of the
issuing session that has at least one allegiant affected issuing session that has at least one allegiant affected
task. task.
If there are multiple affected LUs (say due to a target If there are multiple affected LUs (say due to a target
reset), then one Async Message PDU MUST be sent for each reset), then one Async Message PDU MUST be sent for each
such LU on each connection that has at least one allegiant such LU on each connection that has at least one allegiant
affected task. affected task.
skipping to change at page 20, line 5 skipping to change at page 20, line 5
by the initiator and thus the target can unambiguously ascertain by the initiator and thus the target can unambiguously ascertain
the TargetPortalGroupTag as well. Since all the four elements the TargetPortalGroupTag as well. Since all the four elements
of the 4-tuple are known, the ISID RULE MUST be enforced by of the 4-tuple are known, the ISID RULE MUST be enforced by
targets with no changes from [RFC3720] semantics. A new session targets with no changes from [RFC3720] semantics. A new session
with a matching <InitiatorName, ISID, TargetName, with a matching <InitiatorName, ISID, TargetName,
TargetPortalGroupTag> thus will reinstate an existing session. TargetPortalGroupTag> thus will reinstate an existing session.
Note in this case that any new iSCSI session (Discovery or Note in this case that any new iSCSI session (Discovery or
Normal) with the matching 4-tuple may reinstate an existing Normal) with the matching 4-tuple may reinstate an existing
Named Discovery iSCSI session. Named Discovery iSCSI session.
5.3 TPGT Values 6 Negotiation and Others
6.1 TPGT Values
SAM-2 and SAM-3 specifications incorrectly note in their SAM-2 and SAM-3 specifications incorrectly note in their
informative text that TPGT value should be non-zero, although informative text that TPGT value should be non-zero, although
[RFC3720} allows the value of zero for TPGT. This section is to [RFC3720} allows the value of zero for TPGT. This section is to
clarify that zero value is expressly allowed as a legal value clarify that zero value is expressly allowed as a legal value
for TPGT. A future revision of SAM will be corrected to address for TPGT. A future revision of SAM will be corrected to address
this discrepancy. this discrepancy.
5.4 Session type negotiation 6.2 Session type negotiation
During the Login phase, the SessionType key is offered by the During the Login phase, the SessionType key is offered by the
initiator to choose the type of session it wants to create with initiator to choose the type of session it wants to create with
the target. The target may accept or reject the offer. the target. The target may accept or reject the offer.
Depending on the type of the session, a target may decide on Depending on the type of the session, a target may decide on
resources to allocate and the security to enforce etc. for the resources to allocate and the security to enforce etc. for the
session. If the SessionType key is thus going to be offered as session. If the SessionType key is thus going to be offered as
"Discovery", it SHOULD be offered in the initial Login request "Discovery", it SHOULD be offered in the initial Login request
by the initiator. by the initiator.
6 iSCSI Error Handling and Recovery 6.3 Understanding NotUnderstood
6.1 ITT [RFC3720] defines NotUnderstood as a valid answer during a
negotiation text key exchange between two iSCSI nodes.
NotUnderstood has the reserved meaning that the sending side did
not understand the key semantics. This section seeks to clarify
that NotUnderstood is a valid answer for both declarative and
negotiated keys. The general iSCSI philosophy is that
comprehension precedes processing for any iSCSI key. A proposer
of an iSCSI key, negotiated or declarative, in a text key
exchange MUST thus be able to properly handle a NotUnderstood
response.
The proper way to handle a NotUnderstood response varies
depending on the lineage and type of the key. 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.
For all other later keys, a NotUnderstood answer concludes the
negotiation for a negotiated key whereas for a declarative key,
a NotUnderstood answer simply informs the declarer of lack of
comprehension by the receiver. In either case, a NotUnderstood
answer always requires that the protocol behavior associated
with that key be not used within the scope of the key
(connection/session) by either side.
7 iSCSI Error Handling and Recovery
7.1 ITT
Section 10.19 in [RFC3720] mentions this in passing but noted Section 10.19 in [RFC3720] mentions this in passing but noted
here again for making it obvious since the semantics apply to here again for making it obvious since the semantics apply to
the initiators in general. An ITT value of 0xffffffff is the initiators in general. An ITT value of 0xffffffff is
reserved and MUST NOT be assigned for a task by the initiator. reserved and MUST NOT be assigned for a task by the initiator.
The only instance it may be seen on the wire is in a target- The only instance it may be seen on the wire is in a target-
initiated NOP-In PDU (and in the initiator response to that PDU initiated NOP-In PDU (and in the initiator response to that PDU
if necessary). if necessary).
6.2 Format Errors 7.2 Format Errors
Section 6.6 of [RFC3720] discusses format error handling. This Section 6.6 of [RFC3720] discusses format error handling. This
section elaborates on the "inconsistent" PDU field contents section elaborates on the "inconsistent" PDU field contents
noted in [RFC3720]. noted in [RFC3720].
All initiator-detected PDU construction errors MUST be All initiator-detected PDU construction errors MUST be
considered as format errors. Some examples of such errors are: considered as format errors. Some examples of such errors are:
- NOP-In with a valid TTT but an invalid LUN - NOP-In with a valid TTT but an invalid LUN
- NOP-In with a valid ITT (i.e. a NOP-In response) and also a - NOP-In with a valid ITT (i.e. a NOP-In response) and also a
valid TTT valid TTT
- SCSI Response PDU with Status=CHECK CONDITION, but - SCSI Response PDU with Status=CHECK CONDITION, but
DataSegmentLength = 0 DataSegmentLength = 0
6.3 Digest Errors 7.3 Digest Errors
Section 6.7 of [RFC3720] discusses digest error handling. It Section 6.7 of [RFC3720] discusses digest error handling. It
states that "No further action is necessary for initiators if the discarded states that "No further action is necessary for initiators if the discarded
PDU is an unsolicited PDU (e.g., Async, Reject)" on detecting a PDU is an unsolicited PDU (e.g., Async, Reject)" on detecting a
payload digest error. This is incorrect. payload digest error. This is incorrect.
An Asynchronous Message PDU or a Reject PDU carries the next An Asynchronous Message PDU or a Reject PDU carries the next
StatSN value on an iSCSI connection, advancing the StatSN. When StatSN value on an iSCSI connection, advancing the StatSN. When
an initiator discards one of these PDUs due to a payload digest an initiator discards one of these PDUs due to a payload digest
error, the entire PDU including the header MUST be discarded. error, the entire PDU including the header MUST be discarded.
skipping to change at page 23, line 5 skipping to change at page 24, line 5
the following options noted in [RFC3720]: the following options noted in [RFC3720]:
a) Request PDU retransmission with a status SNACK. a) Request PDU retransmission with a status SNACK.
b) Logout the connection for recovery and continue the b) Logout the connection for recovery and continue the
tasks on a different connection instance. tasks on a different connection instance.
c) Logout to close the connection (abort all the commands c) Logout to close the connection (abort all the commands
associated with the connection). associated with the connection).
7 iSCSI PDUs 8 iSCSI PDUs
7.1 Asynchronous Message 8.1 Asynchronous Message
This section defines additional semantics for the Asynchronous This section defines additional semantics for the Asynchronous
Message PDU defined in section 10.9 of [RFC3720] using the same Message PDU defined in section 10.9 of [RFC3720] using the same
conventions. conventions.
The following new legal value for AsyncEvent is defined: The following new legal value for AsyncEvent is defined:
5: all active tasks for LU with matching LUN field in the Async 5: all active tasks for LU with matching LUN field in the Async
Message PDU are being terminated. Message PDU are being terminated.
skipping to change at page 24, line 5 skipping to change at page 25, line 5
taking the following steps in order. taking the following steps in order.
i) Stop Data-Out transfers on that connection for all active i) Stop Data-Out transfers on that connection for all active
TTTs for the affected LUN quoted in the Async Message TTTs for the affected LUN quoted in the Async Message
PDU. PDU.
ii) Acknowledge the StatSN of the Async Message PDU via a ii) Acknowledge the StatSN of the Async Message PDU via a
Nop-Out PDU with ITT=0xffffffff (i.e. non-ping flavor), Nop-Out PDU with ITT=0xffffffff (i.e. non-ping flavor),
while copying the LUN field from Async Message to Nop- while copying the LUN field from Async Message to Nop-
Out. Out.
8 Login/Text Operational Text Keys 9 Login/Text Operational Text Keys
This section follows the same conventions as section 12 of This section follows the same conventions as section 12 of
[RFC3720]. [RFC3720].
8.1 FastMultiTaskAbort 9.1 FastMultiTaskAbort
Use: LO Use: LO
Senders: Initiator and Target Senders: Initiator and Target
Scope: SW Scope: SW
Irrelevant when: SessionType=Discovery Irrelevant when: SessionType=Discovery
FastMultiTaskAbort=<boolean-value> FastMultiTaskAbort=<boolean-value>
Default is No. Default is No.
Result function is AND. Result function is AND.
This key is used to negotiate the updated fast multi-task abort This key is used to negotiate the updated fast multi-task abort
semantics defined in section 4.1.3. By negotiating this key to semantics defined in section 4.1.3. By negotiating this key to
"Yes", an initiator and a target agree that the new semantics "Yes", an initiator and a target agree that the new semantics
MUST be used in the multi-task TMF handling situations. The MUST be used in the multi-task TMF handling situations. The
default is to use the [RFC3720] TMF semantics as clarified in default is to use the [RFC3720] TMF semantics as clarified in
section 4.1.2. section 4.1.2.
9 Security Considerations 10 Security Considerations
This document does not introduce any new security considerations This document does not introduce any new security considerations
other than those already noted in [RFC3720]. Consequently, all other than those already noted in [RFC3720]. Consequently, all
the iSCSI-related security text in [RFC3723] is also directly the iSCSI-related security text in [RFC3723] is also directly
applicable to this document. applicable to this document.
10 IANA Considerations 11 IANA Considerations
This draft does not have any specific IANA considerations other This draft does not have any specific IANA considerations other
than those already noted in [RFC3720]. than those already noted in [RFC3720].
11 References and Bibliography 12 References and Bibliography
11.1 Normative References 12.1 Normative References
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka,
M., and E. Zeidner, "Internet Small Computer Systems M., and E. Zeidner, "Internet Small Computer Systems
Interface (iSCSI)", RFC 3720, April 2004. Interface (iSCSI)", RFC 3720, April 2004.
[RFC3722] Bakke, M., "String Profile for Internet Small [RFC3722] Bakke, M., "String Profile for Internet Small
Computer Systems Interface (iSCSI) Names", RFC 3722, April Computer Systems Interface (iSCSI) Names", RFC 3722, April
2004. 2004.
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and
F. Travostino, "Securing Block Storage Protocols over IP", F. Travostino, "Securing Block Storage Protocols over IP",
RFC 3723, April 2004. RFC 3723, April 2004.
[SPC3] T10/1416-D, SCSI Primary Commands-3. [SPC3] T10/1416-D, SCSI Primary Commands-3.
11.2 Informative References 12.2 Informative References
[RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K.,
and M. Krueger, "Internet Small Computer Systems Interface and M. Krueger, "Internet Small Computer Systems Interface
(iSCSI) Naming and Discovery", RFC 3721, April 2004. (iSCSI) Naming and Discovery", RFC 3721, April 2004.
[iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler, [iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler,
P., J. Hufferd, "iSCSI Extensions for RDMA", IETF P., J. Hufferd, "iSCSI Extensions for RDMA", IETF
Internet Draft draft-ietf-ips-iser-04.txt (work in Internet Draft draft-ietf-ips-iser-04.txt (work in
progress), June 2005. progress), June 2005.
[RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[SAM2] ANSI X3.366-2003, SCSI Architecture Model-2 (SAM-2). [SAM2] ANSI X3.366-2003, SCSI Architecture Model-2 (SAM-2).
12 Editor's Address 13 Editor's Address
Mallikarjun Chadalapaka Mallikarjun Chadalapaka
Hewlett-Packard Company Hewlett-Packard Company
8000 Foothills Blvd. 8000 Foothills Blvd.
Roseville, CA 95747-5668, USA Roseville, CA 95747-5668, USA
Phone: +1-916-785-5621 Phone: +1-916-785-5621
E-mail: cbm@rose.hp.com E-mail: cbm@rose.hp.com
13 Acknowledgements 14 Acknowledgements
The IP Storage (ips) Working Group in the Transport Area of The IP Storage (ips) Working Group in the Transport Area of
IETF has been responsible for defining the iSCSI protocol IETF has been responsible for defining the iSCSI protocol
(apart from a host of other relevant IP Storage protocols). (apart from a host of other relevant IP Storage protocols).
The editor acknowledges the contributions of the entire The editor acknowledges the contributions of the entire
working group. working group.
The following individuals directly contributed to identifying The following individuals directly contributed to identifying
[RFC3720] issues and/or suggesting resolutions to the issues [RFC3720] issues and/or suggesting resolutions to the issues
clarified in this document: David Black (REPORT LUNS/overflow clarified in this document: David Black (REPORT LUNS/overflow
semantics, ACA semantics), Gwendal Grignou (TMF scope), Mike semantics, ACA semantics), Gwendal Grignou (TMF scope), Mike
Ko (digest error handling for Asynchronous Message), Dmitry Ko (digest error handling for Asynchronous Message), Dmitry
Fomichev (reserved ITT), Bill Studenmund (residual handling, Fomichev (reserved ITT), Bill Studenmund (residual handling,
discovery semantics), Ken Sandars (discovery semantics), Bob discovery semantics), Ken Sandars (discovery semantics), Bob
Russell (discovery semantics), Julian Satran (discovery Russell (discovery semantics), Julian Satran (discovery
semantics), Rob Elliott (T10 liaison, R2T ordering), Joseph semantics), Rob Elliott (T10 liaison, R2T ordering), Joseph
Pittman(TMF scope), Somesh Gupta (multi-task abort Pittman(TMF scope), Somesh Gupta (multi-task abort
semantics). This document benefited from all these semantics). This document benefited from all these
contributions. contributions.
14 Full Copyright Statement 15 Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain BCP 78, and except as set forth therein, the authors retain
all their rights. all their rights.
This document and the information contained herein are This document and the information contained herein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE provided on an "AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
15 Intellectual Property Statement 16 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might any Intellectual Property Rights or other rights that might
be claimed to pertain to the implementation or use of the be claimed to pertain to the implementation or use of the
technology described in this document or the extent to which technology described in this document or the extent to which
any license under such rights might or might not be any license under such rights might or might not be
available; nor does it represent that it has made any available; nor does it represent that it has made any
independent effort to identify any such rights. Information independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can on the procedures with respect to rights in RFC documents can
be found in BCP 78 and BCP 79. be found in BCP 78 and BCP 79.
 End of changes. 28 change blocks. 
48 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/