[要約] RFC 5048は、iSCSIプロトコルの修正と明確化に関するドキュメントです。このRFCの目的は、iSCSIの実装と運用に関する問題を解決し、プロトコルの正確性と信頼性を向上させることです。
Network Working Group M. Chadalapaka, Ed.
Request for Comments: 5048 Hewlett-Packard Co.
Updates: 3720 October 2007
Category: Standards Track
Internet Small Computer System Interface (iSCSI) Corrections and Clarifications
インターネットスモールコンピューターシステムインターフェイス（ISCSI）修正と説明
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ.
Internet Small Computer System Interface（ISCSI）はSCSIトランスポートプロトコルであり、SCSIアーキテクチャとコマンドセットをTCP/IPにマップします。RFC 3720 ISCSIプロトコルを定義します。このドキュメントは、RFC 3720の元のプロトコル定義に明確化をまとめて、ISCSI実装者のコンパニオンドキュメントとして機能します。このドキュメントはRFC 3720を更新し、このドキュメントのテキストは、2つが異なる場合にRFC 3720のテキストに取って代わります。
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions, Acronyms, and Document Summary .....................3
2.1. Definitions ................................................3
2.2. Acronyms ...................................................4
2.3. Clarifications, Changes, and New Semantics .................5
3. iSCSI Semantics for SCSI Tasks ..................................7
3.1. Residual Handling ..........................................7
3.1.1. Overview ............................................7
3.1.2. SCSI REPORT LUNS and Residual Overflow ..............7
3.2. R2T Ordering ...............................................9
3.3. Model Assumptions for Response Ordering ....................9
3.3.1. Model Description ..................................10
3.3.2. iSCSI Semantics with the Interface Model ...........10
3.3.3. Current List of Fenced Response Use Cases ..........11
4. Task Management ................................................12
4.1. Requests Affecting Multiple Tasks .........................12
4.1.1. Scope of Affected Tasks ............................12
4.1.2. Clarified Multi-Task Abort Semantics ...............13
4.1.3. Updated Multi-Task Abort Semantics .................14
4.1.4. Affected Tasks Shared across RFC 3720 and
FastAbort Sessions .................................16
4.1.5. Implementation Considerations ......................17
4.1.6. Rationale behind the New Semantics .................17
5. Discovery Semantics ............................................19
5.1. Error Recovery for Discovery Sessions .....................19
5.2. Reinstatement Semantics of Discovery Sessions .............19
5.2.1. Unnamed Discovery Sessions .........................20
5.2.2. Named Discovery Sessions ...........................20
5.3. Target PDUs during Discovery ..............................20
6. Negotiation and Others .........................................21
6.1. TPGT Values ...............................................21
6.2. SessionType Negotiation ...................................21
6.3. Understanding NotUnderstood ...............................21
6.4. Outstanding Negotiation Exchanges .........................22
7. iSCSI Error Handling and Recovery ..............................22
7.1. ITT .......................................................22
7.2. Format Errors .............................................22
7.3. Digest Errors .............................................22
7.4. Message Error Checking ....................................23
8. iSCSI PDUs .....................................................23
8.1. Asynchronous Message ......................................23
8.2. Reject ....................................................24
9. Login/Text Operational Text Keys ...............................24
9.1. TaskReporting .............................................24
10. Security Considerations .......................................25
11. IANA Considerations ...........................................26
11.1. iSCSI-Related IANA Registries ............................26
11.2. iSCSI Opcodes ............................................26
11.3. iSCSI Login/Text Keys ....................................28
11.4. iSCSI Asynchronous Events ................................30
11.5. iSCSI Task Management Function Codes .....................31
11.6. iSCSI Login Response Status Codes ........................32
11.7. iSCSI Reject Reason Codes ................................34
11.8. iSER Opcodes .............................................35
12. References ....................................................36
12.1. Normative References .....................................36
12.2. Informative References ...................................36
Acknowledgements ..................................................37
Several iSCSI implementations have been built since [RFC3720] was published and the iSCSI community is now richer by the resulting implementation expertise. The goal of this document is to leverage this expertise both to offer clarifications to the [RFC3720] semantics and to address defects in [RFC3720] as appropriate. This document intends to offer critical guidance to implementers with regard to non-obvious iSCSI implementation aspects so as to improve interoperability and accelerate iSCSI adoption. This document, however, does not purport to be an all-encompassing iSCSI how-to guide for implementers, nor a complete revision of [RFC3720]. Instead, this document is intended as a companion document to [RFC3720] for the iSCSI implementers.
[RFC3720]が公開されて以来、いくつかのISCSI実装が構築されており、ISCSIコミュニティは、結果の実装の専門知識によって豊かになりました。このドキュメントの目標は、この専門知識を活用して、[RFC3720]セマンティクスの説明を提供し、必要に応じて[RFC3720]の欠陥に対処することです。このドキュメントは、相互運用性を向上させ、ISCSIの採用を加速するために、非自明なISCSI実装の側面に関する実装者に重要なガイダンスを提供する予定です。ただし、このドキュメントは、実装者向けのすべての網羅的なハウツーガイドでも、[RFC3720]の完全な改訂版であることを意図していません。代わりに、このドキュメントは、ISCSI実装者の[RFC3720]のコンパニオンドキュメントとして意図されています。
iSCSI implementers are required to reference [RFC3722] and [RFC3723] in addition to [RFC3720] for mandatory requirements. In addition, [RFC3721] also contains useful information for iSCSI implementers. The text in this document, however, updates and supersedes the text in [RFC3720] whenever there is such a question.
ISCSI実装者は、必須要件については[RFC3722]および[RFC3723]に加えて[RFC3723]を参照する必要があります。さらに、[RFC3721]には、ISCSI実装者にとって有用な情報も含まれています。ただし、このドキュメントのテキストは、そのような質問がある場合はいつでも[RFC3720]のテキストを更新して置き換えます。
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 that buffer. For a read or write data transfer to take place for a task, an I/O Buffer is required on the initiator and at least one is required on the target.
I/OバッファーSCSIの読み取りまたは書き込み操作で使用されるバッファーを使用すると、SCSIデータがそのバッファーから送信または受信される可能性があります。読み取りまたは書き込みデータ転送がタスクのために行われるには、イニシエーターにI/Oバッファーが必要であり、ターゲットには少なくとも1つが必要です。
SCSI-Presented Data Transfer Length (SPDTL) SPDTL is the aggregate data length of the data that the SCSI layer logically "presents" to the iSCSI layer for a Data-In or Data-Out transfer in the context of a SCSI task. For a bidirectional task, there are two SPDTL values -- one for Data-In and one for Data-Out. Note that the notion of "presenting" includes immediate data per the data transfer model in [SAM2], and excludes overlapping data transfers, if any, requested by the SCSI layer.
SCSI-PResentedデータ転送長（SPDTL）SPDTLは、SCSI層がSCSIタスクのコンテキストでデータインまたはデータアウト転送のためにISCSI層に論理的に「提示」するデータの集約データ長です。双方向のタスクの場合、2つのSPDTL値があります。1つはデータイン用、もう1つはデータアウト用です。「提示」の概念には、[SAM2]のデータ転送モデルごとに即時データが含まれており、SCSIレイヤーによって要求されたデータ転送の重複がある場合は除外されていることに注意してください。
Third-party A term used in this document to denote nexus objects (I_T or I_T_L) and iSCSI sessions that reap the side effects of actions that take place in the context of a separate iSCSI session, while being third parties to the action that caused the side effects. One example of a third-party session is an iSCSI session hosting an I_T_L nexus to an LU that is reset with an LU Reset TMF via a separate I_T nexus.
サードパーティこのドキュメントで使用された用語は、Nexusオブジェクト（i_tまたはi_t_l）と、ISCSIセッションのコンテキストで行われるアクションの副作用を享受するISCSIセッションを除き、ISCSIセッションを享受します。副作用。サードパーティセッションの1つの例は、I_T_L NexusをLUにホストするISCSIセッションで、別のI_T Nexusを介してLUリセットTMFでリセットされたものです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Acronym Definition
-------------------------------------------------------------
EDTL Expected Data Transfer Length
EDTL予想データ転送長
IANA Internet Assigned Numbers Authority
IANAインターネットに割り当てられた番号当局
IETF Internet Engineering Task Force
IETFインターネットエンジニアリングタスクフォース
I/O Input - Output
I/O入力 - 出力
IP Internet Protocol
IPインターネットプロトコル
iSCSI Internet SCSI
ISCSIインターネットSCSI
iSER iSCSI Extensions for RDMA
RDMAのISER ISCSI拡張機能
ITT Initiator Task Tag
ITTイニシエータータスクタグ
LO Leading Only
リードのみ
LU Logical Unit
LU論理ユニット
LUN Logical Unit Number
LUN論理単位番号
PDU Protocol Data Unit
PDUプロトコルデータユニット
RDMA Remote Direct Memory Access
RDMAリモートダイレクトメモリアクセス
R2T Ready To Transfer
R2T転送準備完了
R2TSN Ready To Transfer Sequence Number
r2tsnシーケンス番号を転送する準備ができています
RFC Request For Comments
RFCコメントのリクエスト
SAM SCSI Architecture Model
SAM SCSIアーキテクチャモデル
SCSI Small Computer Systems Interface
SN Sequence Number
SNACK Selective Negative Acknowledgment - also Sequence Number Acknowledgement for data
スナック選択的否定的な承認 - また、データのシーケンス番号承認
TCP Transmission Control Protocol
TCP伝送制御プロトコル
TMF Task Management Function
TMFタスク管理機能
TTT Target Transfer Tag
TTTターゲット転送タグ
UA Unit Attention
UAユニットの注意
This document specifies certain changes to [RFC3720] semantics as well as defines new iSCSI semantics. In addition, this document also clarifies the [RFC3720] semantics. This section summarizes the contents of the document, categorizing each section into one or more of a clarification, change, or new semantic.
このドキュメントは、[RFC3720]セマンティクスの特定の変更を指定し、新しいISCSIセマンティクスを定義します。さらに、このドキュメントは[RFC3720]セマンティクスも明確にします。このセクションでは、ドキュメントの内容を要約し、各セクションを1つ以上の明確化、変更、または新しいセマンティックに分類します。
Section 3.1.1: Clarification on iSCSI residuals computation general principles
セクション3.1.1：ISCSI残差に関する説明計算一般原則
Section 3.1.2: Clarification on iSCSI residuals computation with an example
セクション3.1.2：ISCSI残差に関する説明の説明例
Section 3.2: Clarification on R2T ordering requirements
セクション3.2：R2T順序付け要件に関する明確化
Section 3.3: New Semantics for Response Ordering in multi-connection iSCSI sessions
セクション3.3：マルチ接続のISCSIセッションでの応答順序の新しいセマンティクス
Section 4.1.2: Clarifications, changes, and new semantics on multi-task abort semantics that all implementations must comply with
セクション4.1.2：すべての実装が準拠しなければならないマルチタスク中絶セマンティクスに関する明確化、変更、および新しいセマンティクス
Section 4.1.3: Changes and new semantics (FastAbort semantics) on multi-task abort semantics that implementations should use for faster error recovery
セクション4.1.3：マルチタスクの変更と新しいセマンティクス（ファーストアボートセマンティクス）は、実装がより高速なエラー回復に使用する必要があるセマンティクスを中止します
Section 4.1.3.1: Changes in iSCSI clearing effects semantics resulting from new FastAbort semantics
セクション4.1.3.1：ISCSIクリアリング効果の変化新しいFastAbortセマンティクスに起因するセマンティクス
Section 4.1.4: New Semantics on third-party session interactions with the new FastAbort semantics Section 4.1.5: Clarification on implementation considerations related to outstanding data transfers in order to realize correct iSCSI protocol behavior
セクション4.1.4：サードパーティのセッションに関する新しいセマンティクスと、新しいFastabortセマンティクスセクション4.1.5：正しいISCSIプロトコルの動作を実現するために、発生データ転送に関連する実装考慮事項に関する説明
Section 4.1.6: Clarification on the intent behind FastAbort semantics (not clarifications to [RFC3720] semantics)
セクション4.1.6：FastAbortセマンティクスの背後にある意図に関する説明（[RFC3720]セマンティクスの明確化ではありません）
Section 5.1: Clarification on error recovery semantics as applicable to Discovery sessions
セクション5.1：発見セッションに該当するエラー回復セマンティクスに関する説明
Section 5.2.1: Clarification and new semantics on applying the Initiator Session Identifier (ISID) RULE ([RFC3720]) to Unnamed Discovery Sessions
セクション5.2.1：イニシエーターセッション識別子（ISID）ルール（[RFC3720]）を無名のディスカバリーセッションに適用することに関する説明と新しいセマンティクス
Section 5.2.2: Clarification on applying the ISID RULE to Named Discovery Sessions
セクション5.2.2：ISIDルールを名前付きディスカバリーセッションに適用することに関する説明
Section 5.3: Clarification on allowed PDU types and target Logout notification behavior on a Discovery session
セクション5.3：許可されているPDUタイプとターゲットログアウト通知の動作に関する説明
Section 6.1: Clarification on the legality of the Target Portal Group Tag (TPGT) value of zero
セクション6.1：ゼロのターゲットポータルグループタグ（TPGT）値の合法性に関する明確化
Section 6.2: Clarification on the negotiating order of SessionType with respect to other keys
セクション6.2：他のキーに関するセッションタイプの交渉順序に関する明確化
Section 6.3: Clarification on the NotUnderstood negotiation response on declarative keys and the implied semantics
セクション6.3：宣言的な鍵と暗黙のセマンティクスに関するNotSurstedの交渉対応に関する明確化
Section 6.4: Clarification on the number of legal outstanding negotiation PDUs (Text or Login-related)
セクション6.4：法的未払いの交渉PDUの数に関する説明（テキストまたはログイン関連）
Section 7.1: Clarification on usage of the ITT value of 0xffffffff
セクション7.1：0xffffffffのITT値の使用に関する明確化
Section 7.2: Clarification on what constitutes format errors for the purpose of error recovery defined in [RFC3720]
セクション7.2：[RFC3720]で定義されているエラー回復を目的とした形式エラーを構成するものに関する説明
Section 7.3: Change in error recovery semantics for the case of discarding unsolicited PDUs
セクション7.3：未承諾PDUを廃棄する場合のエラー回復セマンティクスの変更
Section 7.4: Clarification on the intended level of error checking on inbound PDUs
セクション7.4：インバウンドPDUのエラーチェックの意図されたレベルの明確化
Section 8.1: New semantics for a new AsyncEvent code
セクション8.1：新しい非同期コードの新しいセマンティクス
Section 8.2: Change of legal status for Reject reason code 0x0b; it is now deprecated Section 9.1: New semantics for a new text key TaskReporting
セクション8.2：拒否理由コード0x0bの法的ステータスの変更。現在、廃止されたセクション9.1：新しいテキストキータスクレポートの新しいセマンティクス
Section 10.4.1 of [RFC3720] defines the notion of "residuals" and specifies how the residual information should be encoded into the SCSI Response PDU in the Counts and Flags fields. Section 3.1.1 clarifies the intent of [RFC3720] and explains the general principles. Section 3.1.2 describes the residual handling in the REPORT LUNS scenario.
[RFC3720]のセクション10.4.1は、「残差」の概念を定義し、カウントフィールドとフラグフィールドのSCSI応答PDUに残留情報をエンコードする方法を指定します。セクション3.1.1は[RFC3720]の意図を明確にし、一般原則を説明します。セクション3.1.2では、レポートLUNSシナリオの残留処理について説明します。
SCSI-Presented Data Transfer Length (SPDTL) is the term this document uses (see Section 1.1 for definition) to represent the aggregate data length that the target SCSI layer attempts to transfer using the local iSCSI layer for a task. Expected Data Transfer Length (EDTL) is the iSCSI term that represents the length of data that the iSCSI layer expects to transfer for a task. EDTL is specified in the SCSI Command PDU.
SCSI-PResentedデータ転送長（SPDTL）は、このドキュメントが使用する用語であり（定義についてはセクション1.1を参照）、ターゲットSCSI層がタスクのローカルISCSIレイヤーを使用して転送しようとする集約データ長を表します。予想されるデータ転送長（EDTL）は、ISCSI層がタスクの転送を予想するデータの長さを表すISCSI用語です。EDTLは、SCSIコマンドPDUで指定されています。
When SPDTL = EDTL for a task, the target iSCSI layer completes the task with no residuals. Whenever SPDTL differs from EDTL for a task, that task is said to have a residual.
タスクの場合、spdtl = edtlの場合、ターゲットISCSI層は残差なしでタスクを完了します。SPDTLがタスクのEDTLと異なる場合はいつでも、そのタスクには残留があると言われています。
If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the SCSI Response PDU as specified in [RFC3720]. The Residual Count MUST be set to the numerical value of (SPDTL - EDTL).
タスクのspdtl> edtlの場合、[RFC3720]で指定されているように、SCSI応答PDUでISCSIオーバーフローをシグナル化する必要があります。残差カウントは、（spdtl -edtl）の数値値に設定する必要があります。
If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in the SCSI Response PDU as specified in [RFC3720]. The Residual Count MUST be set to the numerical value of (EDTL - SPDTL).
タスクのSPDTL <EDTLの場合、[RFC3720]で指定されているように、SCSI応答PDUでISCSIアンダーフローを信号する必要があります。残差カウントは、（EDTL -SPDTL）の数値に設定する必要があります。
Note that the Overflow and Underflow scenarios are independent of Data-In and Data-Out. Either scenario is logically possible in either direction of data transfer.
オーバーフローおよびアンダーフローシナリオは、データインとデータアウトに依存しないことに注意してください。どちらのシナリオも、どちらの方向のデータ転送方向でも論理的に可能です。
This section discusses the residual overflow issues citing the example of the SCSI REPORT LUNS command. Note however that there are several SCSI commands (e.g., INQUIRY) with ALLOCATION LENGTH fields following the same underlying rules. The semantics in the rest of the section apply to all such SCSI commands.
このセクションでは、SCSI Report Lunsコマンドの例を挙げて、残留オーバーフローの問題について説明します。ただし、同じ根本的なルールに従って割り当て長さフィールドを備えたいくつかのSCSIコマンド（例：問い合わせ）があることに注意してください。セクションの残りのセマンティクスは、そのようなすべてのSCSIコマンドに適用されます。
The specification of the SCSI REPORT LUNS command requires that the SCSI target limit the amount of data transferred to a maximum size (ALLOCATION LENGTH) provided by the initiator in the REPORT LUNS CDB. If the Expected Data Transfer Length (EDTL) in the iSCSI header of the SCSI Command PDU for a REPORT LUNS command is set to at least as large as that ALLOCATION LENGTH, the SCSI layer truncation prevents an iSCSI Residual Overflow from occurring. A SCSI initiator can detect that such truncation has occurred via other information at the SCSI layer. The rest of the section elaborates this required behavior.
SCSIレポートLUNSコマンドの仕様では、SCSIターゲットは、レポートLUNS CDBのイニシエーターが提供する最大サイズ（割り当て長）に転送されるデータの量を制限することが必要です。レポートLUNSコマンドのSCSIコマンドPDUのISCSIヘッダーの予想データ転送長（EDTL）が、その割り当て長と少なくとも同じ大きさに設定されている場合、SCSI層の切り捨てはISCSI残存オーバーフローの発生を防ぎます。SCSIイニシエーターは、SCSI層の他の情報を介してそのような切り捨てが発生したことを検出できます。セクションの残りの部分では、この必要な動作を詳しく説明しています。
iSCSI uses the (O) bit (bit 5) in the Flags field of the SCSI Response and the last SCSI Data-In PDUs to indicate that an iSCSI target was unable to transfer all of the SCSI data for a command to the initiator because the amount of data to be transferred exceeded the EDTL in the corresponding SCSI Command PDU (see Section 10.4.1 of [RFC3720]).
ISCSIは、SCSI応答のフラグフィールドと最後のSCSIデータインPDUの（o）ビット（ビット5）を使用して、ISCSIターゲットがコマンドのすべてのSCSIデータをイニシエーターに転送できなかったことを示します。転送されるデータの量は、対応するSCSIコマンドPDUのEDTLを超えました（[RFC3720]のセクション10.4.1を参照）。
The SCSI REPORT LUNS command requests a target SCSI layer to return a logical unit inventory (LUN list) to the initiator SCSI layer (see Section 6.21 of SPC-3 [SPC3]). The size of this LUN list may not be known to the initiator SCSI layer when it issues the REPORT LUNS command; to avoid transferring more LUN list data than the initiator is prepared for, the REPORT LUNS CDB contains an ALLOCATION LENGTH field to specify the maximum amount of data to be transferred to the initiator for this command. If the initiator SCSI layer has under-estimated the number of logical units at the target, it is possible that the complete logical unit inventory does not fit in the specified ALLOCATION LENGTH. In this situation, Section 4.3.3.6 in [SPC3] requires that the target SCSI layer "shall terminate transfers to the Data-In Buffer" when the number of bytes specified by the ALLOCATION LENGTH field have been transferred.
SCSIレポートLUNSコマンドは、ターゲットSCSIレイヤーを要求して、論理ユニットインベントリ（LUNリスト）をイニシエーターSCSIレイヤーに返すように要求します（SPC-3 [SPC3]のセクション6.21を参照）。このLUNリストのサイズは、Report LUNSコマンドを発行した場合、開始者SCSIレイヤーにはわからない場合があります。イニシエーターが準備されているよりも多くのLUNリストデータの転送を避けるために、レポートLUNS CDBには、このコマンドのイニシエーターに転送される最大量のデータを指定するための割り当て長さフィールドが含まれています。イニシエーターSCSI層がターゲットの論理ユニットの数を過小評価している場合、完全な論理ユニットインベントリが指定された割り当て長に適合しない可能性があります。この状況では、[SPC3]のセクション4.3.3.6では、ターゲットSCSI層が、割り当て長さフィールドで指定されたバイト数が転送された場合、「データインバッファーへの転送を終了する」ことを要求しています。
Therefore, in response to a REPORT LUNS command, the SCSI layer at the target presents at most ALLOCATION LENGTH bytes of data (logical unit inventory) to iSCSI for transfer to the initiator. For a REPORT LUNS command, if the iSCSI EDTL is at least as large as the ALLOCATION LENGTH, the SCSI truncation ensures that the EDTL will accommodate all of the data to be transferred. If all of the logical unit inventory data presented to the iSCSI layer -- i.e., the data remaining after any SCSI truncation -- is transferred to the initiator by the iSCSI layer, an iSCSI Residual Overflow has not occurred and the iSCSI (O) bit MUST NOT be set in the SCSI Response or final SCSI Data-Out PDU. This is not a new requirement but is already required by the combination of [RFC3720] with the specification of the REPORT LUNS command in [SPC3]. However, if the iSCSI EDTL is larger than the ALLOCATION LENGTH in this scenario, note that the iSCSI Underflow MUST be signaled in the SCSI Response PDU. An iSCSI Underflow MUST also be signaled when the iSCSI EDTL is equal to the ALLOCATION LENGTH but the logical unit inventory data presented to the iSCSI layer is smaller than the ALLOCATION LENGTH.
したがって、レポートLUNSコマンドに応じて、ターゲットのSCSIレイヤーは、イニシエーターへの転送のために、データのほとんどの割り当て長バイト（論理単位インベントリ）にISCSIに表示されます。LUNSコマンドの場合、ISCSI EDTLが少なくとも割り当て長と同じくらい大きい場合、SCSIの切り捨てにより、EDTLが転送されるすべてのデータに対応することが保証されます。ISCSI層に提示されたすべての論理ユニットインベントリデータ、つまりSCSIの切り捨ての後に残っているデータ - がISCSI層によってイニシエーターに転送されると、ISCSI残存オーバーフローは発生しておらず、ISCSI（O）ビットは発生していません。SCSI応答または最終的なSCSIデータアウトPDUに設定しないでください。これは新しい要件ではありませんが、[RFC3720]と[SPC3]のレポートLUNSコマンドの仕様と組み合わせにより、すでに必要です。ただし、このシナリオのISCSI EDTLが割り当て長よりも大きい場合、SCSI応答PDUでISCSIアンダーフローをシグナルにする必要があることに注意してください。ISCSI EDTLが割り当て長に等しいが、ISCSI層に提示された論理ユニットインベントリデータは割り当て長より小さい場合にも、ISCSIアンダーフローを信号する必要があります。
The LUN LIST LENGTH field in the logical unit inventory (the first field in the inventory) is not affected by truncation of the inventory to fit in ALLOCATION LENGTH; this enables a SCSI initiator to determine that the received inventory is incomplete by noticing that the LUN LIST LENGTH in the inventory is larger than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. A common initiator behavior in this situation is to re-issue the REPORT LUNS command with a larger ALLOCATION LENGTH.
論理ユニットインベントリのLUNリスト長フィールド（インベントリの最初のフィールド）は、割り当て長に適合するための在庫の切り捨ての影響を受けません。これにより、SCSIイニシエーターは、在庫のLUNリストの長さがレポートLUNS CDBで送信された割り当て長よりも大きいことに気付くことで、受信した在庫が不完全であることを判断できます。この状況での一般的なイニシエーターの動作は、割り当て長さが大きいレポートLUNSコマンドを再発行することです。
Section 10.8 in [RFC3720] says the following:
[RFC3720]のセクション10.8は、次のように説明しています。
The target may send several R2T PDUs. It, therefore, can have a number of pending data transfers. The number of outstanding R2T PDUs is limited by the value of the negotiated key MaxOutstandingR2T. Within a connection, outstanding R2Ts MUST be fulfilled by the initiator in the order in which they were received.
ターゲットは、いくつかのR2T PDUを送信する場合があります。したがって、多くの保留中のデータ転送を持つことができます。未解決のR2T PDUの数は、ネゴシエートされたキーmaxout Standingr2tの値によって制限されます。接続内で、優れたR2TSが開始者が受信された順序で満たされなければなりません。
The quoted [RFC3720] text was unclear on the scope of applicability -- either per task, or across all tasks on a connection -- and may be interpreted as either. This section is intended to clarify that the scope of applicability of the quoted text is a task. No R2T ordering relationship -- either in generation at the target or in fulfilling at the initiator -- across tasks is implied. That is, outstanding R2Ts within a task MUST be fulfilled by the initiator in the order in which they were received on a connection.
引用された[RFC3720]テキストは、タスクごとに、または接続上のすべてのタスクにわたって適用可能性の範囲について不明であり、どちらかと解釈される場合があります。このセクションは、引用されたテキストの適用可能性の範囲がタスクであることを明確にすることを目的としています。ターゲットでの生成またはイニシエーターでの充足において、R2Tの順序付け関係は、タスク全体で暗示されていません。つまり、タスク内の傑出したR2Tは、接続時に受信された順序でイニシエーターによって満たされなければなりません。
Whenever an iSCSI session is composed of multiple connections, the Response PDUs (task responses or TMF responses) originating in the target SCSI layer are distributed onto the multiple connections by the target iSCSI layer according to iSCSI connection allegiance rules. This process generally may not preserve the ordering of the responses by the time they are delivered to the initiator SCSI layer. Since ordering is not expected across SCSI responses anyway, this approach works fine in the general case. However, to address the special cases where some ordering is desired by the SCSI layer, the following "Response Fence" semantics are defined with respect to handling SCSI response messages as they are handed off from the SCSI protocol layer to the iSCSI layer.
ISCSIセッションが複数の接続で構成されている場合はいつでも、ターゲットSCSI層に由来する応答PDU（タスク応答またはTMF応答）は、ISCSI接続の忠誠ルールに従ってターゲットISCSI層によって複数の接続に分布します。このプロセスは、一般に、イニシエーターSCSI層に配信されるまでに応答の順序を保持しない場合があります。とにかくSCSI応答全体で注文は予想されないため、このアプローチは一般的なケースでは正常に機能します。ただし、SCSI層によってある程度の順序付けが望まれる特別なケースに対処するために、SCSIプロトコル層からISCSI層に引き渡されるため、SCSI応答メッセージの処理に関して、次の「応答フェンス」セマンティクスが定義されます。
The target SCSI protocol layer hands off the SCSI response messages to the target iSCSI layer by invoking the "Send Command Complete" protocol data service ([SAM2], clause 5.4.2) and "Task Management Function Executed" ([SAM2], clause 6.9) service. On receiving the SCSI response message, the iSCSI layer exhibits the Response Fence behavior for certain SCSI response messages (Section 3.3.3 describes the specific instances where the semantics must be realized). Whenever the Response Fence behavior is required for a SCSI response message, the target iSCSI layer MUST ensure that the following conditions are met in delivering the response message to the initiator iSCSI layer:
ターゲットSCSIプロトコルレイヤーは、「送信コマンドComplete」プロトコルデータサービス（[SAM2]、5.4.2項）および「[SAM2]実行」（[SAM2]、条項、条項を呼び出すことにより、ターゲットISCSIレイヤーへのSCSI応答メッセージを手渡します。6.9）サービス。SCSI応答メッセージを受信すると、ISCSIレイヤーは特定のSCSI応答メッセージの応答フェンスの動作を示します（セクション3.3.3では、セマンティクスを実現する必要がある特定のインスタンスについて説明します）。SCSI応答メッセージに応答フェンスの動作が必要なときはいつでも、ターゲットISCSIレイヤーは、イニシエーターISCSIレイヤーに応答メッセージを送信する際に、次の条件が満たされていることを確認する必要があります。
(1) Response with Response Fence MUST be delivered chronologically after all the "preceding" responses on the I_T_L nexus, if the preceding responses are delivered at all, to the initiator iSCSI layer.
(1) 応答フェンスを使用した応答は、前述の応答がまったく提供されている場合、I_T_L Nexusのすべての「先行」応答をイニシエーターISCSIレイヤーに提供した後、時系列に配信する必要があります。
(2) Response with Response Fence MUST be delivered chronologically prior to all the "following" responses on the I_T_L nexus.
(2) 応答フェンスによる応答は、I_T_Lネクサスのすべての「次の」応答の前に時系列に配信する必要があります。
The "preceding" and "following" notions refer to the order of handoff of a response message from the target SCSI protocol layer to the target iSCSI layer.
「前」と「次の」概念は、ターゲットSCSIプロトコル層からターゲットISCSIレイヤーへの応答メッセージのハンドオフの順序を指します。
Whenever the TaskReporting key (Section 9.1) is negotiated to ResponseFence or FastAbort for an iSCSI session and the Response Fence behavior is required for a SCSI response message, the target iSCSI layer MUST perform the actions described in this section for that session.
TaskReportingキー（セクション9.1）がISCSIセッションのResponsefenceまたはFastAbortにネゴシエートされ、SCSI応答メッセージに応答フェンスの動作が必要な場合、ターゲットISCSIレイヤーは、このセッションで説明されているアクションを実行する必要があります。
a) If it is a single-connection session, no special processing is required. The standard SCSI Response PDU build and dispatch process happens.
a) 単一接続セッションの場合、特別な処理は必要ありません。標準のSCSI応答PDUビルドおよびディスパッチプロセスが発生します。
b) If it is a multi-connection session, the target iSCSI layer takes note of the last-sent and unacknowledged StatSN on each of the connections in the iSCSI session, and waits for an acknowledgement (NOP-In PDUs MAY be used to solicit acknowledgements as needed in order to accelerate this process) of each such StatSN to clear the fence. The SCSI response requiring Response Fence behavior MUST NOT be sent to the initiator before acknowledgements are received for each of the unacknowledged StatSNs.
b) マルチ接続セッションの場合、ターゲットISCSIレイヤーは、ISCSIセッションの各接続の最終セントおよび未充填のstatsnに注意し、確認を待つことができます（nop-in pdusは、承認を求めるために使用することができます。フェンスをクリアするためにこのような各statsnのこのプロセスを加速するために必要です。応答フェンスの動作を必要とするSCSI応答は、承認のない各統計について承認を受信する前に、イニシエーターに送信してはなりません。
c) The target iSCSI layer must wait for an acknowledgement of the SCSI Response PDU that carried the SCSI response requiring the Response Fence behavior. The fence MUST be considered cleared only after receiving the acknowledgement.
c) ターゲットISCSI層は、応答フェンスの動作を必要とするSCSI応答を運ぶSCSI応答PDUの認識を待つ必要があります。フェンスは、謝辞を受け取った後にのみクリアされたと見なされる必要があります。
d) All further status processing for the LU is resumed only after clearing the fence. If any new responses for the I_T_L nexus are received from the SCSI layer before the fence is cleared, those Response PDUs MUST be held and queued at the iSCSI layer until the fence is cleared.
d) LUのすべてのさらなるステータス処理は、フェンスをクリアした後にのみ再開されます。フェンスがクリアされる前にI_T_Lネクサスの新しい応答がSCSI層から受信される場合、フェンスがクリアされるまでこれらの応答PDUを保持し、iSCSI層で列に並べなければなりません。
This section lists the fenced response use cases that iSCSI implementations MUST comply with. However, this is not an exhaustive enumeration. It is expected that as SCSI protocol specifications evolve, the specifications will specify when response fencing is required on a case-by-case basis.
このセクションには、ISCSIの実装が従う必要があるフェンスで囲まれた対応の使用ケースをリストします。ただし、これは徹底的な列挙ではありません。SCSIプロトコル仕様が進化するにつれて、仕様は、ケースバイケースで応答フェンシングが必要なときに指定されることが予想されます。
Whenever the TaskReporting key (Section 9.1) is negotiated to ResponseFence or FastAbort for an iSCSI session, the target iSCSI layer MUST assume that the Response Fence is required for the following SCSI completion messages:
ISCSIセッションのTaskReportingキー（セクション9.1）がResponsefenceまたはFastAbortと交渉される場合はいつでも、ターゲットISCSIレイヤーは、次のSCSI完了メッセージに応答フェンスが必要であると仮定する必要があります。
1. The first completion message carrying the UA after the multi-task abort on issuing and third-party sessions. See Section 4.1.1 for related TMF discussion.
1. マルチタスクが発行およびサードパーティのセッションを中止した後、UAを運ぶ最初の完了メッセージ。関連するTMFディスカッションについては、セクション4.1.1を参照してください。
2. The TMF Response carrying the multi-task TMF Response on the issuing session.
2. 発行セッションでマルチタスクTMF応答を運ぶTMF応答。
3. The completion message indicating ACA establishment on the issuing session.
3. 発行セッションでのACA確立を示す完了メッセージ。
4. The first completion message carrying the ACA ACTIVE status after ACA establishment on issuing and third-party sessions.
4. 発行およびサードパーティのセッションに関するACA設立後のACAアクティブステータスを運ぶ最初の完了メッセージ。
5. The TMF Response carrying the Clear ACA response on the issuing session.
5. 発行セッションで明確なACA応答を運ぶTMF応答。
6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT command.
6. 永続的な予約/先制および中止コマンドへの応答。
Note: Due to the absence of ACA-related fencing requirements in [RFC3720], initiator implementations SHOULD NOT use ACA on multi-connection iSCSI sessions to targets complying only with [RFC3720]. Initiators that want to employ ACA on multi-connection iSCSI sessions SHOULD first assess response-fencing behavior via negotiating for ResponseFence or FastAbort values for the TaskReporting (Section 9.1) key.
注：[RFC3720]にACA関連のフェンシング要件がないため、イニシエーターの実装は、[RFC3720]のみに準拠したターゲットにマルチ接続ISCSIセッションでACAを使用してはなりません。マルチコネクションISCSIセッションでACAを採用したいイニシエーターは、最初に、タスクレポーティング（セクション9.1）キーの応答面またはファスタボート値の交渉を介して応答フェンシング動作を評価する必要があります。
This section clarifies and updates the original text in Section 10.6.2 of [RFC3720]. The clarified semantics (Section 4.1.2) are a superset of the protocol behavior required in the original text and all iSCSI implementations MUST support the new behavior. The updated semantics (Section 4.1.3) on the other hand are mandatory only when the new key TaskReporting (Section 9.1) is negotiated to "FastAbort".
このセクションでは、[RFC3720]のセクション10.6.2の元のテキストを明確にして更新します。明確なセマンティクス（セクション4.1.2）は、元のテキストで必要なプロトコルの動作のスーパーセットであり、すべてのISCSI実装は新しい動作をサポートする必要があります。一方、更新されたセマンティクス（セクション4.1.3）は、新しいキータスクレポート（セクション9.1）が「FastAbort」と交渉された場合にのみ必須です。
This section defines the notion of "affected tasks" in multi-task abort scenarios. Scope definitions in this section apply to both the clarified protocol behavior (Section 4.1.2) and the updated protocol behavior (Section 4.1.3).
このセクションでは、マルチタスク中断シナリオの「影響を受けたタスク」の概念を定義します。このセクションのスコープ定義は、明確なプロトコル動作（セクション4.1.2）と更新されたプロトコル動作（セクション4.1.3）の両方に適用されます。
ABORT TASK SET: All outstanding tasks for the I_T_L nexus identified by the LUN field in the ABORT TASK SET TMF Request PDU.
中止タスクセット：ABORTタスクセットTMFリクエストPDUのLUNフィールドによって識別されたI_T_Lネクサスのすべての未解決のタスク。
CLEAR TASK SET: All outstanding tasks in the task set for the LU identified by the LUN field in the CLEAR TASK SET TMF Request PDU. See [SPC3] for the definition of a "task set".
クリアタスクセット：CLEARタスクセットTMFリクエストPDUでLUNフィールドによって識別されたLUのタスクセットのすべての未解決のタスク。[タスクセット]の定義については、[SPC3]を参照してください。
LOGICAL UNIT RESET: All outstanding tasks from all initiators for the LU identified by the LUN field in the LOGICAL UNIT RESET Request PDU.
論理ユニットのリセット：論理ユニットリセットリクエストPDUのLUNフィールドによって識別されたLUのすべてのイニシエーターからのすべての未解決のタスク。
TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from all initiators across all LUs to which the TMF-issuing session has access on the SCSI target device hosting the iSCSI session.
ターゲットウォームリセット/ターゲットコールドリセット：ISCSIセッションをホストするSCSIターゲットデバイスにTMF発行セッションがアクセスできるすべてのLUのすべてのイニシエーターからのすべての未解決のタスク。
Usage: An "ABORT TASK SET TMF Request PDU" in the preceding text is an iSCSI TMF Request PDU with the "Function" field set to "ABORT TASK SET" as defined in [RFC3720]. Similar usage is employed for other scope descriptions.
使用法：前のテキストの「AbortタスクセットTMF要求PDU」は、[RFC3720]で定義されている「Abort Task Set」に設定された「関数」フィールドを備えたISCSI TMF要求PDUです。他の範囲の説明にも同様の使用法が採用されています。
All iSCSI implementations MUST support the protocol behavior defined in this section as the default behavior. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.
すべてのISCSI実装は、このセクションで定義されているプロトコルの動作をデフォルトの動作としてサポートする必要があります。中止タスクセット、クリアタスクセット、論理ユニットリセット、ターゲットウォームリセット、ターゲットコールドリセットTMFリクエストの実行は、指定されたパーティの指定された順序で次の一連のアクションで構成されます。
The initiator iSCSI layer:
イニシエーターISCSIレイヤー：
a. MUST continue to respond to each TTT received for the affected tasks.
a. 影響を受けるタスクに対して受信した各TTTに引き続き応答する必要があります。
b. SHOULD process any responses received for affected tasks in the normal fashion. This is acceptable because the responses are guaranteed to have been sent prior to the TMF response.
b. 影響を受けたタスクに対して受信した回答を通常の方法で処理する必要があります。これは、TMF応答の前に応答が送信されたことが保証されているため、受け入れられます。
c. SHOULD receive the TMF Response concluding all the tasks in the set of affected tasks unless the initiator has done something (e.g., LU reset, connection drop) that may prevent the TMF Response from being sent or received. The initiator MUST thus conclude all affected tasks as part of this step in either case, and MUST discard any TMF Response received after the affected tasks are concluded.
c. イニシエーターがTMF応答の送信または受信を防ぐ可能性のある何か（例えば、LUリセット、接続ドロップなど）を実行していない限り、影響を受けるタスクのセットのすべてのタスクを締めくくるTMF応答を受信する必要があります。したがって、イニシエーターは、いずれの場合もこのステップの一部として影響を受けるすべてのタスクを締めくくり、影響を受けるタスクが終了した後に受け取ったTMF応答を破棄する必要があります。
The target iSCSI layer:
ターゲットISCSI層：
a. MUST wait for responses on currently valid target-transfer tags of the affected tasks from the issuing initiator. MAY wait for responses on currently valid target-transfer tags of the affected tasks from third-party initiators.
a. 発行イニシエーターからの影響を受けたタスクの現在有効なターゲット移動タグの応答を待つ必要があります。サードパーティのイニシエーターからの影響を受けたタスクの現在有効なターゲット転送タグの応答を待つことができます。
b. MUST wait (concurrent with the wait in Step a) for all commands of the affected tasks to be received based on the CmdSN ordering. SHOULD NOT wait for new commands on third-party affected sessions -- only the instantiated tasks have to be considered for the purpose of determining the affected tasks. In the case of target-scoped requests (i.e., TARGET WARM RESET and TARGET COLD RESET), all of the commands that are not yet received on the issuing session in the command stream however can be considered to have been received with no command waiting period -- i.e., the entire CmdSN space up to the CmdSN of the task management function can be "plugged".
b. CMDSNの注文に基づいて、影響を受けるタスクのすべてのコマンドを待機する必要があります（ステップaの待機）。サードパーティの影響を受けるセッションの新しいコマンドを待つべきではありません。影響を受けるタスクを決定する目的で、インスタンス化されたタスクのみを考慮する必要があります。ターゲットスコープのリクエストの場合（つまり、ターゲットウォームリセットとターゲットコールドリセット）、コマンドストリームの発行セッションでまだ受信されていないすべてのコマンドは、コマンド待機期間なしで受信されたと見なすことができます - つまり、タスク管理関数のCMDSNまでのCMDSNスペース全体を「プラグイン」することができます。
c. MUST propagate the TMF request to and receive the response from the target SCSI layer.
c. TMF要求を伝播し、ターゲットSCSIレイヤーから応答を受信する必要があります。
d. MUST provide the Response Fence behavior for the TMF Response on the issuing session as specified in Section 3.3.2.
d. セクション3.3.2で指定されているように、発行セッションでTMF応答の応答フェンスの動作を提供する必要があります。
e. MUST provide the Response Fence behavior on the first post-TMF Response on third-party sessions as specified in Section 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses, then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).
e. セクション3.3.2で指定されているように、サードパーティのセッションで最初のTMF後の応答で応答フェンスの動作を提供する必要があります。一部のタスクが非ISSSI I_T_L Nexusesに由来する場合、ターゲットが影響を受けるすべてのタスクがイニシエーターにステータスを返すことを保証する手段は、特定の非ISSSI輸送プロトコルによって定義されます。
Technically, the TMF servicing is complete in Step d. Data transfers corresponding to terminated tasks may however still be in progress on third-party iSCSI sessions even at the end of Step e. The TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step d, and MAY be sent at the end of Step d despite these outstanding data transfers until after Step e.
技術的には、TMFサービスはステップdで完了します。ただし、終了したタスクに対応するデータ転送は、ステップeの終わりであっても、サードパーティのISCSIセッションでまだ進行中である可能性があります。TMF応答は、ステップDの終了前にターゲットISCSI層によって送信されてはならず、ステップEの後までこれらの未解決のデータ転送にもかかわらず、ステップDの最後に送信できます。
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. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.
このセクションで定義されているプロトコルの動作は、このドキュメントに準拠するすべてのISCSI実装によって実装する必要があります。このセクションで定義されているプロトコルの動作は、ISCSIセッションでISCSI実装が、そのセッションで「ファスタボート」の鍵を繰り返す（セクション9.1）キーを交渉するときに展示する必要があります。中止タスクセット、クリアタスクセット、論理ユニットリセット、ターゲットウォームリセット、ターゲットコールドリセットTMFリクエストの実行は、指定されたパーティの指定された順序で次の一連のアクションで構成されます。
The initiator iSCSI layer:
イニシエーターISCSIレイヤー：
a. MUST NOT send any more Data-Out PDUs for affected tasks on the issuing connection of the issuing iSCSI session once the TMF is sent to the target.
a. TMFがターゲットに送信されたら、発行ISCSIセッションの発行接続に関する影響を受けたタスクのデータアウトPDUをこれ以上送信しないでください。
b. SHOULD process any responses received for affected tasks in the normal fashion. This is acceptable because the responses are guaranteed to have been sent prior to the TMF response.
b. 影響を受けたタスクに対して受信した回答を通常の方法で処理する必要があります。これは、TMF応答の前に応答が送信されたことが保証されているため、受け入れられます。
c. MUST respond to each Async Message PDU with AsyncEvent=5 as defined in Section 8.1.
c. セクション8.1で定義されているように、各AsyncメッセージPDUにAsynceVent = 5を使用して応答する必要があります。
d. MUST treat the TMF response as terminating all affected tasks for which responses have not been received, and MUST discard any responses for affected tasks received after the TMF response is passed to the SCSI layer (although the semantics defined in this section ensure that such an out-of-order scenario will never happen with a compliant target implementation).
d. TMF応答を、応答が受信されていないすべての影響を受けたタスクを終了するように扱う必要があり、TMF応答がSCSI層に渡された後に受け取った影響を受けるタスクの応答を破棄する必要があります（ただし、このセクションで定義されているセマンティクスは、そのようなことを保証することを保証する必要があります。-Of-Orderシナリオは、準拠したターゲットの実装では決して起こりません）。
The target iSCSI layer:
ターゲットISCSI層：
a. MUST wait for all commands of the affected tasks to be received based on the CmdSN ordering on the issuing session. SHOULD NOT wait for new commands on third-party affected sessions -- only the instantiated tasks have to be considered for the purpose of determining the affected tasks. In the case of target-scoped requests (i.e., TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received on the issuing session in the command stream can be considered to have been received with no command waiting period -- i.e., the entire CmdSN space up to the CmdSN of the task management function can be "plugged".
a. 発行セッションでのCMDSN注文に基づいて、影響を受けるタスクのすべてのコマンドが受信されるのを待つ必要があります。サードパーティの影響を受けるセッションの新しいコマンドを待つべきではありません。影響を受けるタスクを決定する目的で、インスタンス化されたタスクのみを考慮する必要があります。ターゲットスコープリクエストの場合（つまり、ターゲットウォームリセットとターゲットコールドリセット）、コマンドストリームの発行セッションでまだ受信されていないすべてのコマンドは、コマンド待機期間なしで受信されたと見なすことができます - つまり、タスク管理関数のCMDSNまでのCMDSN空間全体を「プラグイン」することができます。
b. MUST propagate the TMF request to and receive the response from the target SCSI layer.
b. TMF要求を伝播し、ターゲットSCSIレイヤーから応答を受信する必要があります。
c. MUST leave all active "affected TTTs" (i.e., active TTTs associated with affected tasks) valid.
c. すべてのアクティブな「影響を受けるTTTS」（つまり、影響を受けるタスクに関連付けられたアクティブなTTT）を有効にしておく必要があります。
d. MUST send an Asynchronous Message PDU with AsyncEvent=5 (Section 8.1) on:
d. AsynceVent = 5（セクション8.1）を使用して非同期メッセージPDUを送信する必要があります。
i) each connection of each third-party session to which at least one affected task is allegiant if TaskReporting=FastAbort is operational on that third-party session, and
i) TaskReporting = FastAbortがそのサードパーティセッションで動作している場合、少なくとも1つの影響を受けるタスクがallagiantである各サードパーティセッションの各接続と
ii) each connection except the issuing connection of the issuing session that has at least one allegiant affected task.
ii）少なくとも1つのAllegiantの影響を受けたタスクを持つ発行セッションの発行接続を除く各接続。
If there are multiple affected LUs (say, due to a target reset), then one Async Message PDU MUST be sent for each such LU on each connection that has at least one allegiant affected task. The LUN field in the Asynchronous Message PDU MUST be set to match the LUN for each such LU.
複数の影響を受けるLUSがある場合（たとえば、ターゲットリセットのため）、少なくとも1つのallegiantの影響を受けるタスクを持つ各接続で、そのようなLUそれぞれに1つの非同期メッセージPDUを送信する必要があります。非同期メッセージPDUのLUNフィールドは、そのようなLUごとにLUNに一致するように設定する必要があります。
e. MUST address the Response Fence flag on the TMF Response on the issuing session as defined in Section 3.3.2.
e. セクション3.3.2で定義されているように、発行セッションのTMF応答に関する応答フェンスフラグに対処する必要があります。
f. MUST address the Response Fence flag on the first post-TMF Response on third-party sessions as defined in Section 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses, then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).
f. セクション3.3.2で定義されているように、サードパーティのセッションでの最初のポストTMF応答の応答フェンスフラグに対処する必要があります。一部のタスクが非ISSSI I_T_L Nexusesに由来する場合、ターゲットが影響を受けるすべてのタスクがイニシエーターにステータスを返すことを保証する手段は、特定の非ISSSI輸送プロトコルによって定義されます。
g. MUST free up the affected TTTs (and STags, if applicable) and the corresponding buffers, if any, once it receives each associated NOP-Out acknowledgement that the initiator generated in response to each Async Message.
g. 影響を受けるTTTS（および該当する場合はSTAG）と、各非同期メッセージに応答してイニシエーターが生成したという各関連するNOP-OUTの確認を受け取ったら、対応するバッファーを解放する必要があります。
Technically, the TMF servicing is complete in Step e. Data transfers corresponding to terminated tasks may however still be in progress even at the end of Step f. A TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step e, and MAY be sent at the end of Step e despite these outstanding Data transfers until Step g. Step g specifies an event to free up any such resources that may have been reserved to support outstanding data transfers.
技術的には、TMFサービスはステップeで完了します。ただし、終了したタスクに対応するデータ転送は、ステップFの終わりでも進行中である可能性があります。TMF応答は、ステップEの終了前にターゲットISCSIレイヤーによって送信されてはなりません。ステップGまでこれらの未解決のデータ転送にもかかわらず、ステップEの終わりに送信できます。ステップGは、未解決のデータ転送をサポートするために予約されている可能性のあるリソースを解放するイベントを指定します。
Appendix F.1 of [RFC3720] specifies the clearing effects of target and LU resets on "Incomplete TTTs" as "Y". This meant that a target warm reset or a target cold reset or an LU reset would clear the active TTTs upon completion. However, the TaskReporting=FastAbort (Section 9.1) semantics defined by this section do not guarantee that the active TTTs are cleared by the end of the reset operations. In fact, the new semantics are designed to allow clearing the TTTs in a "lazy" fashion after the TMF Response is delivered. Thus, when TaskReporting=FastAbort is operational on a session, the clearing effects of reset operations on "Incomplete TTTs" is "N".
[RFC3720]の付録F.1は、「Y」として「不完全なTTT」に対するターゲットとLUリセットのクリアリング効果を指定しています。これは、ターゲットウォームリセットまたはターゲットコールドリセットまたはLUリセットが完了時にアクティブなTTTをクリアすることを意味しました。ただし、このセクションで定義されたTaskReporting = FastAbort（セクション9.1）セマンティクスは、アクティブなTTTがリセット操作の終了までにクリアされることを保証するものではありません。実際、新しいセマンティクスは、TMF応答が配信された後、「怠zy」ファッションでTTTをクリアすることを可能にするように設計されています。したがって、TaskReporting = FastAbortがセッションで動作している場合、「不完全なTTT」に対するリセット操作のクリアリング効果は「N」です。
If an iSCSI target implementation is capable of supporting TaskReporting=FastAbort functionality (Section 9.1), it may end up in a situation where some sessions have TaskReporting=RFC3720 operational (RFC 3720 sessions) while some other sessions have TaskReporting=FastAbort operational (FastAbort sessions) even while accessing a shared set of affected tasks (Section 4.1.1).
ISCSIターゲットの実装がタスクレポーティング= FastAbort機能（セクション9.1）をサポートできる場合、一部のセッションが= RFC3720の運用（RFC 3720セッション）がある場合、他のセッションではタスクレポーティング=ファーストアボートの運用（ファーストアボートセッション）がある場合に終了する可能性があります。）影響を受けるタスクの共有セットにアクセスしている場合でも（セクション4.1.1）。
If the issuing session is an RFC 3720 session, the iSCSI target implementation is FastAbort-capable, and the third-party affected session is a FastAbort session, the following behavior SHOULD be exhibited by the iSCSI target layer:
発行セッションがRFC 3720セッションである場合、ISCSIターゲットの実装がFASTABORT利用可能であり、サードパーティの影響を受けるセッションはFASTABORTセッションです。
a. Between Steps c and d of the target behavior in Section 4.1.2, send an Asynchronous Message PDU with AsyncEvent=5 (Section 8.1) on each connection of each third-party session to which at least one affected task is allegiant. If there are multiple affected LUs, then send one Async Message PDU for each such LU on each connection that has at least one allegiant affected task. When sent, the LUN field in the Asynchronous Message PDU MUST be set to match the LUN for each such LU.
a. セクション4.1.2のターゲット挙動のステップCとDの間に、少なくとも1つの影響を受けるタスクがallagiantである各サードパーティセッションの各接続について、非同期メッセージPDUをAsynceVent = 5（セクション8.1）で送信します。影響を受けたLUSが複数ある場合は、少なくとも1つのAllegiantの影響を受けたタスクを持つ各接続に、そのようなLUそれぞれに1つの非同期メッセージPDUを送信します。送信されると、非同期メッセージPDUのLUNフィールドは、そのようなLUごとにLUNに一致するように設定する必要があります。
b. After Step e of the target behavior in Section 4.1.2, free up the affected TTTs (and STags, if applicable) and the corresponding buffers, if any, once each associated NOP-Out acknowledgement is received that the third-party initiator generated in response to each Async Message sent in Step a.
b. セクション4.1.2のターゲット挙動のステップEの後、影響を受けるTTTS（および該当する場合はSTAGS）と、それぞれの関連するNOP-Outの確認が受け取られた場合、対応するバッファーがいれば、サードパーティのイニシエーターが生成されたサードパーティのイニシエーターが受け取られた場合は、ステップaで送信された各非同期メッセージへの応答。
If the issuing session is a FastAbort session, the iSCSI target implementation is FastAbort-capable, and the third-party affected session is an RFC 3720 session, the following behavior MUST be exhibited by the iSCSI target layer: Asynchronous Message PDUs MUST NOT be sent on the third-party session to prompt the FastAbort behavior.
発行セッションがFASTABORTセッションである場合、ISCSIターゲットの実装はFASTABORT利用可能であり、サードパーティの影響を受けるセッションはRFC 3720セッションである場合、次の動作はISCSIターゲット層によって示す必要があります。サードパーティのセッションで、ファスタボートの動作を促します。
If the third-party affected session is a FastAbort session and the issuing session is a FastAbort session, the initiator in the third-party role MUST respond to each Async Message PDU with AsyncEvent=5 as defined in Section 8.1. Note that an initiator MAY thus receive these Async Messages on a third-party affected session even if the session is a single-connection session.
サードパーティの影響を受けるセッションがファーストアボートセッションであり、発行セッションがファスタボートセッションである場合、サードパーティの役割のイニシエーターは、セクション8.1で定義されているように、AsynceVent = 5で各AsyncメッセージPDUに応答する必要があります。したがって、イニシエーターは、セッションが単一接続セッションであっても、サードパーティの影響を受けたセッションでこれらの非同期メッセージを受信する可能性があることに注意してください。
Both in clarified semantics (Section 4.1.2) and updated semantics (Section 4.1.3), there may be outstanding data transfers even after the TMF completion is reported on the issuing session. In the case of iSCSI/iSER [iSER], these would be tagged data transfers for STags not owned by any active tasks. Whether or not real buffers support these data transfers is implementation-dependent. However, the data transfers logically MUST be silently discarded by the target iSCSI layer in all cases. A target MAY, on an implementation-defined internal timeout, also choose to drop the connections on which it did not receive the expected Data-Out sequences (Section 4.1.2) or NOP-Out acknowledgements (Section 4.1.3) so as to reclaim the associated buffer, STag, and TTT resources as appropriate.
明確なセマンティクス（セクション4.1.2）と更新されたセマンティクス（セクション4.1.3）の両方で、発行セッションでTMF完了が報告された後でも、未解決のデータ転送がある可能性があります。ISCSI/ISER [ISER]の場合、これらはアクティブなタスクが所有していないSTAGのデータ転送にタグ付けされます。実際のバッファーがこれらのデータ転送をサポートするかどうかは、実装依存です。ただし、データは、すべての場合において、ターゲットISCSI層によって論理的に転送される必要があります。ターゲットは、実装定義の内部タイムアウトで、予想されるデータアウトシーケンス（セクション4.1.2）またはノップアウトの確認（セクション4.1.3）を受信しなかった接続をドロップすることも選択できます。必要に応じて、関連するバッファ、STAG、およびTTTリソースを取り戻します。
There are fundamentally three basic objectives behind the semantics specified in Sections 4.1.2 and 4.1.3.
セクション4.1.2および4.1.3で指定されたセマンティクスの背後には、基本的に3つの基本的な目的があります。
1. Maintaining an ordered command flow I_T nexus abstraction to the target SCSI layer even with multi-connection sessions.
1. 順序付けられたコマンドフローI_T Nexus抽象化をターゲットSCSIレイヤーに維持します。
o Target iSCSI processing of a TMF request must maintain the single flow illusion. Target behavior in Step b of Section 4.1.2 and Step a of Section 4.1.3 correspond to this objective.
o TMF要求のターゲットISCSI処理は、単一のフロー錯覚を維持する必要があります。セクション4.1.2のステップBおよびセクション4.1.3のステップAのターゲットの動作は、この目的に対応しています。
2. Maintaining a single ordered response flow I_T nexus abstraction to the initiator SCSI layer even with multi-connection sessions when one response (i.e., TMF response) could imply the status of other unfinished tasks from the initiator's perspective.
2. 1つの応答（つまり、TMF応答）がイニシエーターの観点からの他の未完成のタスクの状態を暗示する場合でも、単一の順序付けられた応答フローI_T Nexus抽象化をイニシエーターSCSIレイヤーに維持することが、マルチ接続セッション（つまり、TMF応答）を意味する場合でも維持されます。
o The target must ensure that the initiator does not see "old" task responses (that were placed on the wire chronologically earlier than the TMF Response) after seeing the TMF response. The target behavior in Step d of Section 4.1.2 and Step e of Section 4.1.3 correspond to this objective.
o ターゲットは、TMF応答を確認した後、イニシエーターが「古い」タスク応答（TMF応答よりも時系列に配置された）を表示しないようにする必要があります。セクション4.1.2のステップDおよびセクション4.1.3のステップEのターゲット動作は、この目的に対応しています。
o Whenever the result of a TMF action is visible across multiple I_T_L nexuses, [SAM2] requires the SCSI device server to trigger a UA on each of the other I_T_L nexuses. Once an initiator is notified of such an UA, the application client on the receiving initiator is required to clear its task state (clause 5.5 in [SAM2]) for the affected tasks. It would thus be inappropriate to deliver a SCSI Response for a task after the task state is cleared on the initiator, i.e., after the UA is notified. The UA notification contained in the first SCSI Response PDU on each affected Third-party I_T_L nexus after the TMF action thus MUST NOT pass the affected task responses on any of the iSCSI sessions accessing the LU. The target behavior in Step e of Section 4.1.2 and Step f of Section 4.1.3 correspond to this objective.
o TMFアクションの結果が複数のI_T_L Nexusesにわたって表示される場合はいつでも、[SAM2]は、SCSIデバイスサーバーが他の各I_T_LネクサーのUAをトリガーする必要があります。イニシエーターにそのようなUAが通知されると、受信イニシエーターのアプリケーションクライアントは、影響を受けるタスクのタスク状態（[SAM2]の条項5.5）をクリアする必要があります。したがって、タスク状態がイニシエーターでクリアされた後、つまりUAに通知された後、タスクにSCSI応答を提供することは不適切です。したがって、TMFアクションの後に影響を受ける各パーティI_T_L Nexusの最初のSCSI応答PDUに含まれるUA通知は、LUにアクセスするISCSIセッションのいずれかで影響を受けるタスク応答を渡すべきではありません。セクション4.1.2のステップEおよびセクション4.1.3のステップFのターゲット動作は、この目的に対応しています。
3. Draining all active TTTs corresponding to affected tasks in a deterministic fashion.
3. 影響を受けるタスクに対応するすべてのアクティブなTTTを決定的な方法で排出します。
o Data-Out PDUs with stale TTTs arriving after the tasks are terminated can create a buffer management problem even for traditional iSCSI implementations, and is fatal for the connection for iSCSI/iSER implementations. Either the termination of affected tasks should be postponed until the TTTs are retired (as in Step a of Section 4.1.2), or the TTTs and the buffers should stay allocated beyond task termination to be deterministically freed up later (as in Steps c and g of Section 4.1.3).
o タスクが終了した後に登場する古いTTTのデータアウトPDUは、従来のISCSIの実装でもバッファ管理の問題を引き起こす可能性があり、ISCSI/ISERの実装の接続に致命的です。影響を受けたタスクの終了は、TTTSが廃止されるまで延期する必要があります（セクション4.1.2のステップAのように）、またはTTTSとバッファーは、タスク終了を超えて、後で決定論的に解放されるように割り当てられ続ける必要があります（ステップCおよびステップCおよびように。セクション4.1.3のg）。
The only other notable optimization is the plugging. If all tasks on an I_T nexus will be aborted anyway (as with a target reset), there is no need to wait to receive all commands to plug the CmdSN holes. The target iSCSI layer can simply plug all missing CmdSN slots and move on with TMF processing. The first objective (maintaining a single ordered command flow) is still met with this optimization because the target SCSI layer only sees ordered commands.
他の唯一の顕著な最適化はプラグのみです。とにかく（ターゲットリセットと同様に）I_Tネクサスのすべてのタスクが中止される場合、CMDSN穴をプラグインするすべてのコマンドを受信するのを待つ必要はありません。ターゲットISCSI層は、欠落しているすべてのCMDSNスロットを単純に接続し、TMF処理で先に進むことができます。ターゲットSCSI層には順序付けられたコマンドのみが表示されるため、最初の目的（単一の順序付けられたコマンドフローを維持する）は、この最適化でまだ満たされています。
The negotiation of the key ErrorRecoveryLevel is not required for Discovery sessions -- i.e., for sessions that negotiated "SessionType=Discovery" -- because the default value of 0 is necessary and sufficient for Discovery sessions. It is however possible that some legacy iSCSI implementations might attempt to negotiate the ErrorRecoveryLevel key on Discovery sessions. When such a negotiation attempt is made by the remote side, a compliant iSCSI implementation MUST propose a value of 0 (zero) in response. The operational ErrorRecoveryLevel for Discovery sessions thus MUST be 0. This naturally follows from the functionality constraints that [RFC3720] imposes on Discovery sessions.
Key ErrorreCoveryLevelの交渉は、発見セッション（つまり、「SessionType = Discovery」を交渉したセッション）には必要ありません。ただし、一部のレガシーISCSI実装では、ディスカバリーセッションでerrorrecoverylevelキーの交渉を試みる可能性があります。このような交渉の試みがリモート側によって行われる場合、準拠したISCSI実装は、それに応じて0（ゼロ）の値を提案する必要があります。したがって、発見セッションの運用上のerrorrecoverylevelは0でなければなりません。これは、[RFC3720]が発見セッションに課す機能の制約から自然に続きます。
Discovery sessions are intended to be relatively short-lived. Initiators are not expected to establish multiple Discovery sessions to the same iSCSI Network Portal (see [RFC3720]). An initiator may use the same iSCSI Initiator Name and ISID when establishing different unique sessions with different targets and/or different portal groups. This behavior is discussed in Section 9.1.1 of [RFC3720] and is, in fact, encouraged as conservative reuse of ISIDs. The ISID RULE in [RFC3720] states that there must not be more than one session with a matching 4-tuple: <InitiatorName, ISID, TargetName, TargetPortalGroupTag>. While the spirit of the ISID RULE applies to Discovery sessions the same as it does for Normal sessions, note that some Discovery sessions differ from the Normal sessions in two important aspects:
発見セッションは、比較的短命であることを目的としています。イニシエーターは、同じISCSIネットワークポータルに複数の発見セッションを確立することは期待されていません（[RFC3720]を参照）。イニシエーターは、異なるターゲットおよび/または異なるポータルグループで異なる一意のセッションを確立する際に、同じISCSIイニシエーター名とISIDを使用する場合があります。この動作は、[RFC3720]のセクション9.1.1で説明されており、実際、ISIDの保守的な再利用として奨励されています。[RFC3720]のISIDルールは、一致する4つのタプル：<initiatorname、isid、targetName、targetportalgroupag>を使用して、複数のセッションが必要ではないことを述べています。ISIDルールの精神は、通常のセッションと同じように発見セッションに適用されますが、発見セッションには2つの重要な側面の通常のセッションとは異なることに注意してください。
Because [RFC3720] allows a Discovery session to be established without specifying a TargetName key in the Login Request PDU (let us call such a session an "Unnamed" Discovery session), there is no Target Node context to enforce the ISID RULE.
[RFC3720]は、ログイン要求PDUのターゲット名キーを指定せずにディスカバリーセッションを確立できるため（このようなセッションを「名前のない」発見セッションと呼びましょう）、ISIDルールを施行するターゲットノードコンテキストはありません。
Portal Groups are defined only in the context of a Target Node. When the TargetName key is NULL-valued (i.e., not specified), the TargetPortalGroupTag thus cannot be ascertained to enforce the ISID RULE.
ポータルグループは、ターゲットノードのコンテキストでのみ定義されます。したがって、ターゲット名キーがnull-valued（つまり、指定されていない）の場合、ターゲットポートアルグラットグをISIDルールを実施するために確認することはできません。
The following sections describe the two scenarios -- Named Discovery sessions and Unnamed Discovery sessions -- separately.
次のセクションでは、ディスカバリーセッションと名前のない発見セッションという名前の2つのシナリオについて、個別に説明しています。
For Unnamed Discovery sessions, neither the TargetName nor the TargetPortalGroupTag is available to the targets in order to enforce the ISID RULE. So the following rule applies.
名前のないディスカバリーセッションでは、ISIDルールを実施するために、TargetNameもTargetNameもターゲットが利用できません。したがって、次のルールが適用されます。
UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the following 4-tuple for Unnamed Discovery sessions: <InitiatorName, ISID, NULL, TargetAddress>. The following semantics are implied by this uniqueness requirement.
無名のISIDルール：ターゲットは、名前のない発見セッションのために、次の4タプルの一意性を実施する必要があります。次のセマンティクスは、この一意性要件によって暗示されています。
Targets SHOULD allow concurrent establishment of one Discovery session with each of its Network Portals by the same initiator port with a given iSCSI Node Name and an ISID. Each of the concurrent Discovery sessions, if established by the same initiator port to other Network Portals, MUST be treated as independent sessions -- i.e., one session MUST NOT reinstate the other.
ターゲットは、特定のISCSIノード名とISIDを備えた同じイニシエーターポートによって、各ネットワークポータルとの1つの発見セッションを同時に確立できるようにする必要があります。同時発見セッションのそれぞれは、同じイニシエーターポートによって他のネットワークポータルに確立された場合、独立したセッションとして扱わなければなりません。つまり、あるセッションは他のセッションを復活させてはなりません。
A new Unnamed Discovery session that has a matching <InitiatorName, ISID, NULL, TargetAddress> to an existing Discovery session MUST reinstate the existing Unnamed Discovery session. Note thus that only an Unnamed Discovery session may reinstate an Unnamed Discovery session.
既存のディスカバリーセッションに一致する<initiatorname、isid、null、targetAddressを備えた新しい名前のない発見セッションは、既存の無名の発見セッションを復活させる必要があります。したがって、名前のない発見セッションのみが無名のディスカバリーセッションを復活させる可能性があることに注意してください。
For a Named Discovery session, the TargetName key is specified by the initiator and thus the target can unambiguously ascertain the TargetPortalGroupTag as well. Since all the four elements of the 4- tuple are known, the ISID RULE MUST be enforced by targets with no changes from [RFC3720] semantics. A new session with a matching <InitiatorName, ISID, TargetName, TargetPortalGroupTag> thus will reinstate an existing session. Note in this case that any new iSCSI session (Discovery or Normal) with the matching 4-tuple may reinstate an existing Named Discovery iSCSI session.
指定されたディスカバリーセッションの場合、ターゲット名キーはイニシエーターによって指定されているため、ターゲットはターゲットポートアルグラットグも明確に確認できます。4タプルの4つの要素はすべて知られているため、[RFC3720]セマンティクスからの変更なしで、ISIDルールはターゲットによって施行されなければなりません。一致する<initiatorname、isid、targetName、targetportalgrouptag>を使用した新しいセッションは、既存のセッションを復活させます。この場合、一致する4タプルを備えた新しいISCSIセッション（発見または通常）は、既存の名前付きDiscovery ISCSIセッションを復活させる可能性があることに注意してください。
Targets SHOULD NOT send any responses other than a Text Response and Logout Response on a Discovery session, once in Full Feature Phase.
ターゲットは、完全な機能フェーズに1回、ディスカバリーセッションでテキスト応答とログアウト応答以外の応答を送信する必要はありません。
Implementation Note: A target may simply drop the connection in a Discovery session when it would have requested a Logout via an Async Message on Normal sessions.
実装注：ターゲットは、通常のセッションで非同期メッセージを介してログアウトを要求した場合に、ディスカバリーセッションで接続を単純にドロップする場合があります。
[SAM2] and [SAM3] specifications incorrectly note in their informative text that TPGT value should be non-zero, although [RFC3720] allows the value of zero for TPGT. This section is to clarify that a zero value is expressly allowed as a legal value for TPGT. This discrepancy currently stands corrected in [SAM4].
[SAM2]および[SAM3]仕様は、TPGT値がゼロではないことを有益なテキストに誤って記録しますが、[RFC3720]はTPGTのゼロの値を許可します。このセクションは、TPGTの法的価値としてゼロ値が明示的に許可されていることを明確にすることです。この矛盾は現在、[SAM4]で修正されています。
During the Login Phase, the SessionType key is offered by the initiator to choose the type of session it wants to create with the target. The target may accept or reject the offer. Depending on the type of the session, a target may decide on resources to allocate and the security to enforce, etc. for the session. If the SessionType key is thus going to be offered as "Discovery", it SHOULD be offered in the initial Login request by the initiator.
ログインフェーズ中、sessionTypeキーは、ターゲットで作成するセッションのタイプを選択するために、イニシエーターによって提供されます。ターゲットは、オファーを受け入れるか拒否する場合があります。セッションの種類に応じて、ターゲットは、セッションのために割り当てるリソースと実施するセキュリティなどを決定する場合があります。したがって、sessionTypeキーが「ディスカバリー」として提供される場合、イニシエーターによる最初のログイン要求で提供される必要があります。
[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 proposed 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.
[RFC3720]は、2つのISCSIノード間のネゴシエーションテキストキー交換中に、NotSurstoredを有効な答えとして定義します。NotUnderSoudには、送信側が提案された重要なセマンティクスを理解していないという意味があります。このセクションでは、Notuntoundが宣言的キーとネゴシエートされたキーの両方にとって有効な答えであることを明確にしようとしています。一般的なISCSI哲学は、ISCSIキーの理解が処理に先行することです。したがって、テキストキーの交換で、交渉または宣言のISCSIキーの提案者は、notuntoredの応答を適切に処理できる必要があります。
The proper way to handle a NotUnderstood response depends on where the key is specified and whether the key is declarative vs. negotiated. 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 a lack of comprehension by the receiver.
notuntoundの応答を処理する適切な方法は、キーが指定されている場所と、キーが宣言的対交渉であるかどうかによって異なります。[RFC3720]で定義されているすべてのキーは、すべての準拠の実装でサポートする必要があります。したがって、[RFC3720]キーのいずれかについての非測定された回答は、プロトコルエラーと見なされ、それに応じて処理する必要があります。他のすべての後の鍵については、Notuntourdedの回答が交渉された鍵の交渉を締めくくりますが、宣言的な鍵の場合、Notuntoredの回答は、宣言者に受信者による理解不足を通知します。
In either case, a NotUnderstood answer always requires that the protocol behavior associated with that key not be used within the scope of the key (connection/session) by either side.
どちらの場合でも、notuntoundの回答では、常にキーに関連付けられたプロトコルの動作が、どちらの側でもキー（接続/セッション）の範囲内で使用されないことが必要です。
There was some uncertainty around the number of outstanding Login Response PDUs on a connection. [RFC3720] offers the analogy of SCSI linked commands to Login and Text negotiations in Sections 5.3 and 10.10.3, respectively, but does not make it fully explicit. This section is to offer a clarification in this regard.
接続上の未解決のログイン応答PDUの数については、いくつかの不確実性がありました。[RFC3720]は、それぞれセクション5.3と10.10.3のログインとテキストの交渉を行うために、SCSIリンクコマンドの類推を提供しますが、完全に明示的ではありません。このセクションは、この点で明確化を提供します。
There MUST NOT be more than one outstanding Login Request, Login Response, Text Request, or Text Response PDU on an iSCSI connection. An outstanding PDU in this context is one that has not been acknowledged by the remote iSCSI side.
ISCSI接続には、未解決のログインリクエスト、ログイン応答、テキストリクエスト、またはテキスト応答PDUが1つ以上ないはずです。この文脈での優れたPDUは、リモートISCSI側によって認められていないものです。
An ITT value of 0xffffffff is reserved and MUST NOT be assigned for a task by the initiator. The only instance in which it may be seen on the wire is in a target-initiated NOP-In PDU (and in the initiator response to that PDU, if necessary). Section 10.19 in [RFC3720] mentions this in passing but is noted here again to make it obvious since the semantics apply to the initiators in general.
0xffffffffffのITT値は予約されており、イニシエーターがタスクに割り当ててはなりません。ワイヤーで見られる唯一のインスタンスは、ターゲットが開始したNOP-in PDUにあります（および必要に応じて、そのPDUに対するイニシエーター応答に）。[RFC3720]のセクション10.19は、これを通過することで言及していますが、セマンティクスが一般的に開始者に適用されるため、ここで再び明確にします。
Section 6.6 of [RFC3720] discusses format error handling. This section elaborates on the "inconsistent" PDU field contents noted in [RFC3720].
[RFC3720]のセクション6.6は、フォーマットエラー処理について説明します。このセクションでは、[RFC3720]に記載されている「一貫性のない」PDUフィールドの内容について詳しく説明します。
All initiator-detected PDU construction errors MUST be considered as format errors. Some examples of such errors are:
すべてのイニシエーターで検出されたPDU構造エラーは、フォーマットエラーと見なす必要があります。このようなエラーの例は次のとおりです。
- NOP-In with a valid TTT but an invalid LUN
- 有効なTTTを使用したNop-Inしかし無効なLUN
- NOP-In with a valid ITT (i.e., a NOP-In response) and also a valid TTT
- 有効なITT（つまり、NOP-in応答）と有効なTTTを備えたnop-in
- SCSI Response PDU with Status=CHECK CONDITION, but DataSegmentLength = 0
- ステータス=条件を確認したSCSI応答PDUですが、datasementlength = 0
Section 6.7 of [RFC3720] discusses digest error handling. It states that "No further action is necessary for initiators if the discarded PDU is an unsolicited PDU (e.g., Async, Reject)" on detecting a payload digest error. This is incorrect.
[RFC3720]のセクション6.7では、消化エラー処理について説明します。ペイロードダイジェストエラーの検出に関して、「廃棄されたPDUが未承諾PDU（例えば、非同期、拒否）である場合、開始者にはそれ以上のアクションは必要ない」と述べています。これは間違っています。
An Asynchronous Message PDU or a Reject PDU carries the next StatSN value on an iSCSI connection, advancing the StatSN. When an initiator discards one of these PDUs due to a payload digest error, the entire PDU including the header MUST be discarded. Consequently, the initiator MUST treat the exception like a loss of any other solicited response PDU -- i.e., it MUST use one of the following options noted in [RFC3720]:
非同期メッセージPDUまたは拒否PDUは、ISCSI接続に次の統計値を運び、統計を進めます。イニシエーターがペイロードダイジェストエラーのためにこれらのPDUの1つを破棄する場合、ヘッダーを含むPDU全体を破棄する必要があります。したがって、イニシエーターは、例外を他の勧誘された応答PDUの損失のように扱う必要があります。つまり、[RFC3720]で記載されている次のオプションのいずれかを使用する必要があります。
a) Request PDU retransmission with a status SNACK.
a) ステータススナックでPDUの再送信をリクエストします。
b) Logout the connection for recovery and continue the tasks on a different connection instance.
b) リカバリのために接続をログアウトし、別の接続インスタンスでタスクを継続します。
c) Logout to close the connection (abort all the commands associated with the connection).
c) 接続を閉じるためのログアウト（接続に関連付けられたすべてのコマンドを中止します）。
There has been some uncertainty on the extent to which incoming messages have to be checked for protocol errors, beyond what is strictly required for processing the inbound message. This section addresses this question.
インバウンドメッセージを処理するために厳密に必要なものを超えて、受信メッセージのプロトコルエラーをチェックする必要がある程度については、いくつかの不確実性がありました。このセクションでは、この質問について説明します。
Unless [RFC3720] or this document requires it, an iSCSI implementation is not required to do an exhaustive protocol conformance check on an incoming iSCSI PDU. The iSCSI implementation especially is not required to double-check the remote iSCSI implementation's conformance to protocol requirements.
[RFC3720]またはこのドキュメントがそれを必要としない限り、ISCSIの実装は、着信ISCSI PDUで徹底的なプロトコル適合チェックを行う必要はありません。ISCSIの実装は、特に、リモートISCSI実装のプロトコル要件への適合性を再確認するために必要はありません。
This section defines additional semantics for the Asynchronous Message PDU defined in Section 10.9 of [RFC3720] using the same conventions.
このセクションでは、同じ規則を使用して[RFC3720]のセクション10.9で定義されている非同期メッセージPDUの追加のセマンティクスを定義します。
The following new legal value for the AsyncEvent is defined:
Asynceventの次の新しい法的価値が定義されています。
5: all active tasks for LU with a matching LUN field in the Async Message PDU are being terminated.
5：ASYNCメッセージPDUに一致するLUNフィールドを備えたLUのすべてのアクティブなタスクが終了しています。
The receiving initiator iSCSI layer MUST respond to this Message by taking the following steps in order.
受信イニシエーターISCSIレイヤーは、次の手順を順番に取ることにより、このメッセージに応答する必要があります。
i) Stop Data-Out transfers on that connection for all active TTTs for the affected LUN quoted in the Async Message PDU.
i) ASYNCメッセージPDUで引用された影響を受けたLUNのすべてのアクティブなTTTの接続のデータアウト転送を停止します。
ii) Acknowledge the StatSN of the Async Message PDU via a NOP-Out PDU with ITT=0xffffffff (i.e., non-ping flavor), while copying the LUN field from the Async Message to NOP-Out.
ii）itt = 0xffffffffff（すなわち、非Pingフレーバー）を使用して、nop-out pduを介してAsyncメッセージPDUの統計を確認しながら、lunフィールドを非同期メッセージからnop-outにコピーします。
The new AsyncEvent defined in this section however MUST NOT be used on an iSCSI session unless the new TaskReporting text key defined in Section 9.1 was negotiated to FastAbort on the session.
ただし、このセクションで定義されている新しいAsynceventは、セクション9.1で定義された新しいタスクレポートキーがセッションでファスタボートと交渉されない限り、ISCSIセッションで使用してはなりません。
Section 10.17.1 of [RFC3720] specifies the Reject reason code of 0x0b with an explanation of "Negotiation Reset". At this point, we do not see any legitimate iSCSI protocol use case for using this reason code. Thus, reason code 0x0b MUST be considered as deprecated and MUST NOT be sent by implementations that comply with the requirements of this document. An implementation receiving reason code 0x0b MUST treat it as a negotiation failure that terminates the Login Phase and the TCP connection, as specified in Section 6.10 of [RFC3720].
[RFC3720]のセクション10.17.1は、「ネゴシエーションリセット」の説明とともに、0x0Bの拒否理由コードを指定しています。この時点で、この理由コードを使用するための正当なISCSIプロトコルの使用ケースはありません。したがって、理由コード0x0Bは非推奨と見なされ、このドキュメントの要件に準拠する実装によって送信されないでください。実装理由0x0Bを受信すると、[RFC3720]のセクション6.10で指定されているように、ログインフェーズとTCP接続を終了する交渉障害として扱う必要があります。
Section 5.4 of [RFC3720] states:
[RFC3720]のセクション5.4は次のとおりです。
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening operational parameter negotiation reset, except for responses to specific keys that explicitly allow repeated key declarations (e.g., TargetAddress).
イニシエーターもターゲットも、繰り返されるキー宣言（ターゲットアドレスなど）を明示的に許可する特定のキーへの応答を除き、介在する操作パラメーターネゴシエーションリセットを使用せずに、交渉シーケンスの間にパラメーターを複数回宣言または交渉しようとする必要はありません。
The deprecation of reason code 0x0b eliminates the possibility of an operational parameter negotiation reset, causing the phrase "without an intervening operational parameter negotiation reset" in [RFC3720] to refer to an impossible event. The quoted phrase SHOULD be ignored by receivers that handle reason code 0x0b in the manner specified in this section.
理由コード0x0Bの非推奨は、[RFC3720]の「介在する運用パラメーターネゴシエーションリセットなし」というフレーズを、不可能なイベントを指す「介在する運用パラメーターネゴシエーションリセットなし」というフレーズを引き起こします。引用されたフレーズは、このセクションで指定された方法で理由コード0x0Bを処理する受信機によって無視する必要があります。
This section follows the same conventions as Section 12 of [RFC3720].
このセクションは、[RFC3720]のセクション12と同じ規則に従います。
Use: LO Senders: Initiator and Target Scope: SW
使用：LO送信者：イニシエーターとターゲットスコープ：SW
Irrelevant when: SessionType=Discovery TaskReporting=<list-of-values> Default is RFC3720. Result function is AND.
無関係な場合：sessionType = discovery taskReporting = <list-values>デフォルトはRFC3720です。結果関数はです。
This key is used to negotiate the task completion reporting semantics from the SCSI target. The following table describes the semantics that an iSCSI target MUST support for respective negotiated key values. Whenever this key is negotiated, at least the RFC3720 and ResponseFence values MUST be offered as options by the negotiation originator.
このキーは、SCSIターゲットからのタスク完了レポートセマンティクスをネゴシエートするために使用されます。次の表は、ISCSIターゲットがそれぞれのネゴシエートされたキー値をサポートしなければならないというセマンティクスを説明しています。このキーがネゴシエートされるたびに、少なくともRFC3720およびResponseFence値は、交渉発信者によってオプションとして提供される必要があります。
+--------------+------------------------------------------+
| Name | Description |
+--------------+------------------------------------------+
| RFC3720 | RFC 3720-compliant semantics. Response |
| | fencing is not guaranteed and fast |
| | completion of multi-task aborting is not |
| | supported |
+--------------+------------------------------------------+
| ResponseFence| Response Fence (Section 3.3.1) semantics |
| | MUST be supported in reporting task |
| | completions |
+--------------+------------------------------------------+
| FastAbort | Updated fast multi-task abort semantics |
| | defined in Section 4.1.3 MUST be |
| | supported. Support for Response Fence is|
| | implied -- i.e., Section 3.3.1 semantics |
| | MUST be supported as well |
+--------------+------------------------------------------+
When TaskReporting is not negotiated to FastAbort, the [RFC3720] TMF semantics as clarified in Section 4.1.2 MUST be used.
タスクレポーティングがFastAbortと交渉されない場合、セクション4.1.2で明確にされた[RFC3720] TMFセマンティクスを使用する必要があります。
This document does not introduce any new security considerations other than those already noted in [RFC3720]. Consequently, all the iSCSI-related security text in [RFC3723] is also directly applicable to this document.
このドキュメントでは、[RFC3720]ですでに記載されているもの以外の新しいセキュリティ上の考慮事項は導入されていません。その結果、[RFC3723]のすべてのISCSI関連のセキュリティテキストも、このドキュメントに直接適用されます。
This document creates the following iSCSI-related registries for IANA to manage.
このドキュメントでは、IANAが管理するISCSI関連のレジストリを作成します。
1. iSCSI Opcodes
1. ISCSIオプコード
2. iSCSI Login/Text Keys
2. ISCSIログイン/テキストキー
3. iSCSI Asynchronous Events
3. ISCSI非同期イベント
4. iSCSI Task Management Function Codes
4. ISCSIタスク管理機能コード
5. iSCSI Login Response Status Codes
5. ISCSIログイン応答ステータスコード
6. iSCSI Reject Reason Codes
6. ISCSIは理由コードを拒否します
7. iSER Opcodes
7. ISER OPCODES
Each of the following sections describes a registry, its sub-registries if any, and their administration policies in more detail. IANA has registered what this document calls the main "registries" as sub-registries of a larger iSCSI registry. However, wherever registry-to-sub-registry relationships are specified by this document, they have been preserved intact.
次の各セクションでは、レジストリ、そのサブ登録があれば、およびその管理政策についてさらに詳しく説明しています。IANAは、このドキュメントがメインの「レジストリ」と呼ばれるものを、より大きなISCSIレジストリのサブレジストリとして登録しています。ただし、このドキュメントでレジストリとサブの関係が指定されている場合は、それらはそのまま保存されています。
[RFC3720] specifies three iSCSI-related registries -- extended key, authentication methods, and digests. This document recommends that these registries be published together with the registries defined by this document. Further, this document recommends that the three [RFC3720] registries be listed in between items 6 and 7 in the registry list above.
[RFC3720]は、3つのISCSI関連レジストリを指定します。拡張キー、認証方法、および消化率。このドキュメントでは、これらのレジストリをこのドキュメントで定義されたレジストリと一緒に公開することを推奨しています。さらに、このドキュメントでは、3つの[RFC3720]レジストリを上記のレジストリリストの項目6と7の間にリストすることを推奨しています。
Name of the registry: "iSCSI Opcodes"
レジストリの名前：「iscsi opcodes」
Namespace details: Numerical values that can fit in one octet with the most significant two bits (bits 0 and 1) already designated by [RFC3720], bit 0 being reserved and bit 1 for immediate delivery. Bit 2 is designated to identify the originator of the opcode. Bit 2 = 0 for initiator and Bit 2 = 1 for target.
名前空間の詳細：既に[RFC3720]で指定されている最も重要な2ビット（ビット0および1）、ビット0が予約され、即時配信のためにビット1を持つ1つのオクテットに収まる数値値。ビット2は、オペコードのオリジネーターを識別するために指定されています。イニシエーターのビット2 = 0、ターゲットのビット2 = 1。
Information that must be provided to assign a new value: An IESG-approved standards-track specification defining the semantics and interoperability requirements of the proposed new value and the fields to be recorded in the registry.
新しい値を割り当てるために提供する必要がある情報：提案された新しい値のセマンティクスと相互運用性要件を定義するIESGが承認した標準トラック仕様、およびレジストリに記録されるフィールド。
Allocation request guidance to requesters:
リクエスターへの割り当てリクエストガイダンス：
1) If the initiator opcode and target opcode used to identify the request and response of a new type of protocol operation are requested, assign the same lower five bits (i.e., Bit 3 through Bit 7) for both opcodes, e.g., 0x13 and 0x33.
1) 新しいタイプのプロトコル操作のリクエストと応答を識別するために使用されるイニシエーターオペコードとターゲットオペコードが要求される場合、両方のオプコード、例えば0x13および0x33に同じ下の5ビット（つまり、ビット3からビット7）を割り当てます。
2) If only the initiator opcode or target opcode is requested to identify a one-way protocol message (i.e., request without a response or a "response" without a request), assign an unused number from the appropriate category (i.e., Bit 2 set to 0 or 1 for initiator category or target category) and add the other pair member (i.e., same opcode with Bit 2 set to 1 or 0, respectively) to "no opcode pair is available" list.
2) イニシエーターオペコードまたはターゲットオペコードのみが一方向プロトコルメッセージを識別するように要求されている場合（つまり、応答なしまたは「応答」リクエストなしで「応答」）、適切なカテゴリから未使用番号を割り当てます（つまり、ビット2をに設定します。イニシエーターカテゴリまたはターゲットカテゴリの0または1）および他のペアメンバー（つまり、ビット2をそれぞれ1または0に設定した同じオペコード）を「オペコードペアなしで使用できない」リストに追加します。
3) If there are no other opcodes available in the appropriate "Reserved to IANA" list to assign on a request for a new opcode except the reserved opcodes in the "no opcode pair is available" list, allocate the opcode from the appropriate category (initiator or target) of the "no opcode pair is available" list.
3) 「opcodeペアなし」リストの予約済みオペコードを除き、新しいオプコードのリクエストに割り当てるために適切な「IANAに予約されたIANA」リストに利用可能な他のオペコードがない場合、適切なカテゴリ（イニシエーターまたはイニシエーターまたはターゲット）「OpCodeペアなし」リストのリスト。
Fields to record in the registry: Assigned value, Who can originate (Initiator or Target), Operation Name, and its associated RFC reference.
レジストリに記録するフィールド：割り当てられた値、（イニシエーターまたはターゲット）、操作名、およびそれに関連するRFCリファレンスを発信できる人。
Initial registry contents:
初期レジストリの内容：
0x00, Initiator, NOP-Out, [RFC3720]
0x00、イニシエーター、nop-out、[rfc3720]
0x01, Initiator, SCSI Command, [RFC3720]
0x01、イニシエーター、SCSIコマンド、[RFC3720]
0x02, Initiator, SCSI Task Management function request, [RFC3720]
0x02、イニシエーター、SCSIタスク管理機能要求、[RFC3720]
0x03, Initiator, Login Request, [RFC3720]
0x03、イニシエーター、ログイン要求、[RFC3720]
0x04, Initiator, Text Request, [RFC3720]
0x04、イニシエーター、テキストリクエスト、[RFC3720]
0x05, Initiator, SCSI Data-Out, [RFC3720]
0x05、イニシエーター、SCSIデータアウト、[RFC3720]
0x06, Initiator, Logout Request, [RFC3720]
0x06、イニシエーター、ログアウトリクエスト、[RFC3720]
0x10, Initiator, SNACK Request, [RFC3720] 0x1c-0x1e, Initiator, Vendor specific codes, [RFC3720]
0x10、イニシエーター、スナックリクエスト、[RFC3720] 0x1c-0x1e、イニシエーター、ベンダー固有のコード、[RFC3720]
0x20, Target, NOP-In, [RFC3720]
0x20、ターゲット、nop-in、[rfc3720]
0x21, Target, SCSI Response, [RFC3720]
0x21、ターゲット、SCSI応答、[RFC3720]
0x22, Target, SCSI Task Management function response, [RFC3720]
0x22、ターゲット、SCSIタスク管理機能応答、[RFC3720]
0x23, Target, Login Response, [RFC3720]
0x23、ターゲット、ログイン応答、[RFC3720]
0x24, Target, Text Response, [RFC3720]
0x24、ターゲット、テキスト応答、[RFC3720]
0x25, Target, SCSI Data-In, [RFC3720]
0x25、ターゲット、SCSIデータイン、[RFC3720]
0x26, Target, Logout Response, [RFC3720]
0x26、ターゲット、ログアウト応答、[RFC3720]
0x31, Target, Ready To Transfer (R2T), [RFC3720]
0x31、ターゲット、転送準備完了（R2T）、[RFC3720]
0x32, Target, Asynchronous Message, [RFC3720]
0x32、ターゲット、非同期メッセージ、[RFC3720]
0x3c-0x3e, Target, Vendor specific codes, [RFC3720]
0x3C-0x3E、ターゲット、ベンダー固有のコード、[RFC3720]
0x3f, Target, Reject, [RFC3720]
0x3f、ターゲット、拒否、[rfc3720]
Reserved to IANA: 0x07-0x0f, 0x13-0x1b (initiator codes) 0x27-0x2f, 0x33-0x3b (target codes)
IANAに予約されています：0x07-0x0f、0x13-0x1b（イニシエーターコード）0x27-0x2f、0x33-0x3b（ターゲットコード）
No opcode pair is available: 0x11, 0x12, 0x1f (initiator codes) 0x30 (target codes)
OPCODEペアは使用できません：0x11、0x12、0x1f（イニシエーターコード）0x30（ターゲットコード）
Allocation Policy:
割り当てポリシー：
Standards Action ([IANA]): This is required for defining the semantics of the opcode.
標準アクション（[IANA]）：これは、オペコードのセマンティクスを定義するために必要です。
Expert Review ([IANA]): This is required for selecting the specific opcode(s) to allocate in order to ensure compliance with the earlier "Allocation request guidance to requesters".
Expert Review（[IANA]）：これは、以前の「リクエスターへの割り当てリクエストガイダンス」に準拠するために、特定のオペコードを選択するために割り当てるために必要です。
Name of the registry: "iSCSI Text Keys"
レジストリの名前：「iscsiテキストキー」
Namespace details: Key=value pairs with "Key" names in UTF-8 Unicode, and the permissible "value" options for the "Key" are Key-dependent. [RFC3720] defines the rules on key names and allowed values.
名前空間の詳細：UTF-8 Unicodeの「キー」名を持つキー=値ペア、および「キー」の許容「値」オプションはキー依存です。[RFC3720]は、キー名と許可された値に関するルールを定義します。
Information that must be provided to assign a new value: An IESG-approved standards-track specification defining the semantics and interoperability requirements of the proposed new Key per [RFC3720] key specification template and the fields to be recorded in the registry.
新しい値を割り当てるために提供する必要がある情報：IESGが承認した標準トラック仕様[RFC3720]キー仕様テンプレートごとに提案された新しいキーのセマンティクスと相互運用性要件を定義し、レジストリに記録するフィールド。
Assignment policy:
割り当てポリシー：
If the requested Key name is not already assigned and is roughly representative of its proposed semantics, it may be assigned to the requester.
要求されたキー名がまだ割り当てられておらず、提案されたセマンティクスを大まかに代表している場合、それはリクエスターに割り当てられる場合があります。
Given the arbitrary nature of text strings, there is no maximum reserved by IANA for assignment in this registry.
テキスト文字列の任意の性質を考えると、このレジストリでの割り当てのためにIANAが最大限に予約することはありません。
Fields to record in the registry: Assigned Key Name and its associated RFC reference.
レジストリに記録するフィールド：割り当てられたキー名とそれに関連するRFCリファレンス。
Initial registry contents:
初期レジストリの内容：
AuthMethod, [RFC3720]
authmethod、[rfc3720]
HeaderDigest, [RFC3720]
HeaderDigest、[RFC3720]
DataDigest, [RFC3720]
Datadigest、[RFC3720]
MaxConnections, [RFC3720]
MaxConnections、[RFC3720]
SendTargets, [RFC3720]
SendTargets、[RFC3720]
TargetName, [RFC3720]
TargetName、[RFC3720]
InitiatorName, [RFC3720]
initiatorname、[rfc3720]
TargetAlias, [RFC3720]
ターゲットリアス、[RFC3720]
InitiatorAlias, [RFC3720]
イニシエーターリアス、[RFC3720]
TargetAddress, [RFC3720]
TargetAddress、[RFC3720]
TargetPortalGroupTag, [RFC3720]
TargetPortalGrouptag、[RFC3720]
InitialR2T, [RFC3720]
initialr2t、[rfc3720]
ImmediateData, [RFC3720]
Immediata、[rfc3720]
MaxRecvDataSegmentLength, [RFC3720] MaxBurstLength, [RFC3720]
maxrecvdatasegementlength、[rfc3720] maxburstlength、[rfc3720]
FirstBurstLength, [RFC3720]
FirstBurstLength、[RFC3720]
DefaultTime2Wait, [RFC3720]
defaulttime2wait、[rfc3720]
DefaultTime2Retain, [RFC3720]
defaulttime2retain、[rfc3720]
MaxOutstandingR2T, [RFC3720]
maxout Stastingr2t、[rfc3720]
DataPDUInOrder, [RFC3720]
datapduinorder、[rfc3720]
DataSequenceInOrder, [RFC3720]
datasequenceinorder、[rfc3720]
ErrorRecoveryLevel, [RFC3720]
errorrecoverylevel、[rfc3720]
SessionType, [RFC3720]
sessionType、[RFC3720]
RDMAExtensions, [iSER]
rdmaextensions、[iser]
TargetRecvDataSegmentLength, [iSER]
TargetRecvDatasegementlength、[iser]
InitiatorRecvDataSegmentLength, [iSER]
initiatorrecvdatasegementlength、[iser]
MaxOutstandingUnexpectedPDUs, [iSER]
maxout Stastingunexpectedpdus、[iser]
TaskReporting, this document
タスクレポート、このドキュメント
Allocation Policy:
割り当てポリシー：
Standards Action ([IANA])
標準アクション（[IANA]）
Name of the registry: "iSCSI Asynchronous Events"
レジストリの名前：「iscsi非同期イベント」
Namespace details: Numerical values that can fit in one octet.
名前空間の詳細：1つのオクテットに収まる数値値。
Information that must be provided to assign a new value: An IESG-approved standards-track specification defining the semantics and interoperability requirements of the proposed new Event and the fields to be recorded in the registry.
新しい価値を割り当てるために提供する必要がある情報：提案された新しいイベントのセマンティクスと相互運用性要件を定義するIESGが承認した標準トラック仕様と、レジストリに記録されるフィールド。
Assignment policy:
割り当てポリシー：
If the requested value is not already assigned, it may be assigned to the requester.
要求された値がまだ割り当てられていない場合、リクエスターに割り当てられます。
6-247: range reserved by IANA for assignment in this registry.
6-247：このレジストリでの割り当てのためにIANAによって予約された範囲。
Fields to record in the registry: Assigned Event number, Description and its associated RFC reference.
レジストリに記録するフィールド：割り当てられたイベント番号、説明、および関連するRFCリファレンス。
Initial registry contents:
初期レジストリの内容：
0, SCSI Async Event, [RFC3720]
0、SCSI ASYNCイベント、[RFC3720]
1, Logout Request, [RFC3720]
1、ログアウトリクエスト、[RFC3720]
2, Connection drop notification, [RFC3720]
2、接続ドロップ通知、[RFC3720]
3, Session drop notification, [RFC3720]
3、セッションドロップ通知、[RFC3720]
4, Negotiation Request, [RFC3720]
4、交渉リクエスト、[RFC3720]
5, Task termination, this document
5、タスク終了、このドキュメント
248-254, Vendor-unique, this document
248-254、ベンダーユニーク、このドキュメント
255, Vendor-unique, [RFC3720]
255、Vendor-Unique、[RFC3720]
Allocation Policy:
割り当てポリシー：
Standards Action ([IANA])
標準アクション（[IANA]）
Name of the registry: "iSCSI TMF Codes"
レジストリの名前：「ISCSI TMFコード」
Namespace details: Numerical values that can fit in 7 bits.
名前空間の詳細：7ビットに収まる数値。
Information that must be provided to assign a new value: An IESG-approved standards-track specification defining the semantics and interoperability requirements of the proposed new Code and the fields to be recorded in the registry.
新しい値を割り当てるために提供されなければならない情報：提案された新しいコードとレジストリに記録されるフィールドのセマンティクスと相互運用性要件を定義するIESG承認の標準トラック仕様。
Assignment policy:
割り当てポリシー：
If the requested value is not already assigned, it may be assigned to the requester.
要求された値がまだ割り当てられていない場合、リクエスターに割り当てられます。
9-127: range reserved by IANA for assignment in this registry.
9-127：このレジストリでの割り当てのためにIANAによって予約された範囲。
Fields to record in the registry: Assigned Code, Description, and its associated RFC reference.
レジストリに記録するフィールド：割り当てられたコード、説明、および関連するRFCリファレンス。
Initial registry contents:
初期レジストリの内容：
1, ABORT TASK, [RFC3720]
1、タスクを中止、[RFC3720]
2, ABORT TASK SET, [RFC3720]
2、タスクセットを中止、[RFC3720]
3, CLEAR ACA, [RFC3720]
3、clear aca、[rfc3720]
4, CLEAR TASK SET, [RFC3720]
4、クリアタスクセット、[RFC3720]
5, LOGICAL UNIT RESET, [RFC3720]
5、論理ユニットリセット、[RFC3720]
6, TARGET WARM RESET, [RFC3720]
6、ターゲットウォームリセット、[RFC3720]
7, TARGET COLD RESET, [RFC3720]
7、ターゲットコールドリセット、[RFC3720]
8, TASK REASSIGN, [RFC3720]
8、タスクの再割り当て、[RFC3720]
Allocation Policy:
割り当てポリシー：
Standards Action ([IANA])
標準アクション（[IANA]）
Name of the registry: "iSCSI Login Response Status Codes"
レジストリの名前：「ISCSIログイン応答ステータスコード」
Namespace details: Numerical values; Status-Class (one octet), Status-Detail (one octet) for each possible value of Status-Class except for Vendor-Unique Status-Class (0x0f).
名前空間の詳細：数値値。ステータスクラス（1オクテット）、ベンダーユニークステータスクラス（0x0F）を除き、ステータスクラスの可能性のある各値のステータス - デテール（1オクテット）。
Information that must be provided to assign a new value: An IESG-approved specification defining the semantics and interoperability requirements of the proposed new Code, its Status-Class affiliation (only if a new Status-Detail value is being proposed for a Status-Class), Status-Class definition (only if a new Status-Class is being proposed), and the fields to be recorded in the registry.
新しい値を割り当てるために提供する必要がある情報：提案された新しいコードのセマンティクスと相互運用性要件を定義するIESGが承認した仕様であるそのステータスクラスの提携（ステータスクラスの新しいステータス - デテール値が提案されている場合のみ）、ステータスクラス定義（新しいステータスクラスが提案されている場合のみ）、およびレジストリに記録されるフィールド。
Assignment policy:
割り当てポリシー：
If the requested value is not already assigned, it may be assigned to the requester.
要求された値がまだ割り当てられていない場合、リクエスターに割り当てられます。
4-14 and 16-255: range reserved by IANA for assignment in this registry.
4-14および16-255：このレジストリでの割り当てのためにIANAによって予約されています。
Fields to record in the Status-Class main registry: Assigned Code, Description, and its associated RFC reference.
ステータスクラスメインレジストリに記録するフィールド：割り当てられたコード、説明、および関連するRFCリファレンス。
Fields to record in the Status-Detail sub-registries: Status-Class, Assigned Code, Description, and its associated RFC reference.
ステータスデテールサブレジストリに記録するフィールド：ステータスクラス、割り当てられたコード、説明、および関連するRFCリファレンス。
Initial registry contents (Status-Class):
初期レジストリコンテンツ（ステータスクラス）：
0x00, Success, [RFC3720]
0x00、成功、[RFC3720]
0x01, Redirection, [RFC3720]
0x01、リダイレクト、[RFC3720]
0x02, Initiator Error, [RFC3720]
0x02、イニシエーターエラー、[RFC3720]
0x03, Target Error, [RFC3720]
0x03、ターゲットエラー、[RFC3720]
0x0f, Vendor-Unique, this document
0x0f、ベンダーユニーク、このドキュメント
Initial sub-registry contents (Status-Detail for Status-Class=0x00):
初期サブレジストリコンテンツ（ステータスクラスのステータス - デテール= 0x00）：
0x00, 0x00, Success, [RFC3720]
0x00、0x00、成功、[RFC3720]
1-255: range reserved by IANA for assignment in Status-Class=0 sub-registry.
1-255：ステータスクラス= 0サブレジストリの割り当てのためにIANAによって予約されています。
Initial sub-registry contents (Status-Detail for Status-Class=0x01):
初期サブレジストリコンテンツ（ステータスクラスのステータス - デテール= 0x01）：
0x01, 0x01, Temporary move, [RFC3720]
0x01、0x01、一時的な移動、[rfc3720]
0x01, 0x02, Permanent move, [RFC3720]
0x01、0x02、永続的な動き、[rfc3720]
3-255: range reserved by IANA for assignment in Status-Class=1 sub-registry.
3-255：ステータスクラスの割り当て= 1サブレジストリの割り当てのためにIANAによって予約されています。
Initial sub-registry contents (Status-Detail for Status-Class=0x02):
初期サブレジストリコンテンツ（ステータスクラスのステータス - デテール= 0x02）：
0x02, 0x00, Miscellaneous, [RFC3720]
0x02、0x00、その他、[rfc3720]
0x02, 0x01, Authentication failure, [RFC3720]
0x02、0x01、認証障害、[RFC3720]
0x02, 0x02, Authorization failure, [RFC3720]
0x02、0x02、認証失敗、[RFC3720]
0x02, 0x03, Not found, [RFC3720]
0x02、0x03、見つかりません、[rfc3720]
0x02, 0x04, Target removed, [RFC3720]
0x02、0x04、ターゲット削除、[RFC3720]
0x02, 0x05, Unsupported version, [RFC3720]
0x02、0x05、サポートされていないバージョン、[rfc3720]
0x02, 0x06, Too many connections, [RFC3720]
0x02、0x06、接続が多すぎる[RFC3720]
0x02, 0x07, Missing parameter, [RFC3720] 0x02, 0x08, Can't include in session, [RFC3720]
0x02、0x07、欠落パラメーター、[rfc3720] 0x02、0x08、セッションに含めることはできません[RFC3720]
0x02, 0x09, Unsupported session type, [RFC3720]
0x02、0x09、サポートされていないセッションタイプ、[RFC3720]
0x02, 0x0a, Non-existent session, [RFC3720]
0x02、0x0a、存在しないセッション、[RFC3720]
0x02, 0x0b, Invalid during login, [RFC3720]
0x02、0x0b、ログイン中に無効、[RFC3720]
12-255: range reserved by IANA for assignment in Status-Class=2 sub-registry.
12-255：ステータスクラス= 2サブレジストリの割り当てのためにIANAによって予約されています。
Initial sub-registry contents (Status-Detail for Status-Class=0x03):
初期サブレジストリコンテンツ（ステータスクラスのステータス - デテール= 0x03）：
0x03, 0x00, Target error, [RFC3720]
0x03、0x00、ターゲットエラー、[RFC3720]
0x03, 0x01, Service unavailable, [RFC3720]
0x03、0x01、サービスが利用できない、[RFC3720]
0x03, 0x02, Out of resources, [RFC3720]
0x03、0x02、リソースから、[RFC3720]
3-255: range reserved by IANA for assignment in Status-Class=3 sub-registry.
3-255：ステータスクラス= 3サブレジストリの割り当てのためにIANAによって予約されています。
Allocation Policy:
割り当てポリシー：
Standards Action ([IANA])
標準アクション（[IANA]）
Name of the registry: "iSCSI Reject Reason Codes"
レジストリの名前：「ISCSI拒否理由コード」
Namespace details: Numerical values that can fit in a single octet.
名前空間の詳細：単一のオクテットに収まる数値値。
Information that must be provided to assign a new value: A published specification defining the semantics and interoperability requirements of the proposed new Code and the fields to be recorded in the registry.
新しい値を割り当てるために提供する必要がある情報：提案された新しいコードとレジストリに記録されるフィールドのセマンティクスと相互運用性要件を定義する公開された仕様。
Assignment policy:
割り当てポリシー：
If the requested value is not already assigned, it may be assigned to the requester.
要求された値がまだ割り当てられていない場合、リクエスターに割り当てられます。
13-255: range reserved by IANA for assignment in this registry.
13-255：このレジストリでの割り当てのためにIANAによって予約された範囲。
Fields to record in the registry: Assigned Code, Description, and its associated RFC reference.
レジストリに記録するフィールド：割り当てられたコード、説明、および関連するRFCリファレンス。
Initial registry contents:
初期レジストリの内容：
0x01, Reserved, [RFC3720]
0x01、予約済み、[RFC3720]
0x02, Data digest error, [RFC3720]
0x02、データ消化エラー、[RFC3720]
0x03, SNACK Reject, [RFC3720]
0x03、スナック拒否、[RFC3720]
0x04, Protocol Error, [RFC3720]
0x04、プロトコルエラー、[RFC3720]
0x05, Command not supported, [RFC3720]
0x05、サポートされていないコマンド、[RFC3720]
0x06, Immediate command reject, [RFC3720]
0x06、即時コマンド拒否、[rfc3720]
0x07, Task in progress, [RFC3720]
0x07、進行中のタスク、[RFC3720]
0x08, Invalid data ack, [RFC3720]
0x08、無効なデータACK、[RFC3720]
0x09, Invalid PDU field, [RFC3720]
0x09、無効なPDUフィールド、[RFC3720]
0x0a, Long op reject, [RFC3720]
0x0a、long op拒否、[rfc3720]
0x0b, "Deprecated reason code", this document
0x0b、「非推奨理由コード」、このドキュメント
0x0c, Waiting for Logout, [RFC3720]
0x0c、ログアウトを待っている、[rfc3720]
Allocation Policy:
割り当てポリシー：
Standards Action ([IANA])
標準アクション（[IANA]）
Name of the registry: "iSER Opcodes"
レジストリの名前：「iser opcodes」
Namespace details: Numerical values that can fit in 4 bits.
名前空間の詳細：4ビットに収まる数値値。
Information that must be provided to assign a new value: An IESG-approved specification defining the semantics and interoperability requirements of the proposed new value and the fields to be recorded in the registry.
新しい値を割り当てるために提供する必要がある情報：提案された新しい値のセマンティクスと相互運用性要件を定義するIESGが承認した仕様と、レジストリに記録されるフィールド。
Assignment policy:
割り当てポリシー：
If the requested value is not already assigned, it may be assigned to the requester.
要求された値がまだ割り当てられていない場合、リクエスターに割り当てられます。
4-15: range reserved by IANA for assignment in this registry.
4-15：このレジストリでの割り当てのためにIANAによって予約された範囲。
Fields to record in the registry: Assigned value, Operation Name, and its associated RFC reference.
レジストリに記録するフィールド：割り当てられた値、操作名、および関連するRFCリファレンス。
Initial registry contents:
初期レジストリの内容：
0x1, iSCSI control-type, [iSER]
0x1、iscsiコントロールタイプ、[iser]
0x2, iSER Hello, [iSER]
0x2、iserこんにちは、[iser]
0x3, iSER HelloReply, [iSER]
0x3、iser helloreply、[iser]
Allocation Policy:
割り当てポリシー：
Standards Action ([IANA])
標準アクション（[IANA]）
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[RFC3720] Satran、J.、Meth、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE. Zeidner、「インターネットスモールコンピューターシステムインターフェイス（ISCSI）」、RFC 3720、2004年4月。
[SPC3] ANSI INCITS 408-2005, SCSI Primary Commands-3.
[SPC3] ANSIは408-2005、SCSIプライマリコマンド-3を挿入します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[iSER] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., and P. Thaler, "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)", RFC 5046, October 2007.
[Iser] Ko、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、Shah、H。、およびP. Thaler、 "Internet Small Computer System Interface（ISCSI）リモートダイレクトメモリアクセス（RDMA）拡張）」、RFC 5046、2007年10月。
[RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery", RFC 3721, April 2004.
[RFC3721] Bakke、M.、Hafner、J.、Hufferd、J.、Voruganti、K。、およびM. Krueger、「インターネットスモールコンピューターシステムインターフェイス（ISCSI）命名と発見」、RFC 3721、2004年4月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC3723] Aboba、B.、Tseng、J.、Walker、J.、Rangan、V。、およびF. Travostino、「IPを介したブロックストレージプロトコルの保護」、RFC 3723、2004年4月。
[RFC3722] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004.
[RFC3722] Bakke、M。、「インターネット小型コンピューターシステムインターフェイス（ISCSI）名前の文字列プロファイル」、RFC 3722、2004年4月。
[SAM2] ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM-2).
[SAM2] ANSIは366-2003、SCSIアーキテクチャモデル2（SAM-2）を挿入します。
[SAM3] ANSI INCITS 402-2005, SCSI Architecture Model-3 (SAM-a3).
[SAM3] ANSIは402-2005、SCSIアーキテクチャモデル-3（SAM-A3）を挿入します。
[SAM4] T10 Project: 1683-D, SCSI Architecture Model-4 (SAM-4), Work in Progress.
[SAM4] T10プロジェクト：1683-D、SCSIアーキテクチャモデル-4（SAM-4）、進行中の作業。
Acknowledgements
謝辞
The IP Storage (IPS) Working Group in the Transport Area of the IETF has been responsible for defining the iSCSI protocol (apart from a host of other relevant IP Storage protocols). The editor acknowledges the contributions of the entire working group.
IETFの輸送エリアにあるIPストレージ（IPS）ワーキンググループは、ISCSIプロトコルの定義を担当しています（他の関連するIPストレージプロトコルのホストとは別に）。編集者は、ワーキンググループ全体の貢献を認めています。
The following individuals directly contributed to identifying [RFC3720] issues and/or suggesting resolutions to the issues clarified in this document: David Black, Gwendal Grignou, Mike Ko, Dmitry Fomichev, Bill Studenmund, Ken Sandars, Bob Russell, Julian Satran, Rob Elliott, Joseph Pittman, Somesh Gupta, Eddy Quicksall, Paul Koning. This document benefited from all of these contributions.
以下の個人は、[RFC3720]の問題の特定に直接貢献し、および/またはこの文書で明確になった問題に対する解決策の提案に貢献しました：David Black、Gwendal Grignou、Mike Ko、Dmitry Fomichev、Bill Studenmund、Ken Sandars、Bob Russell、Julian Satran、Rob Elliott、Joseph Pittman、Somesh Gupta、Eddy Quicksall、Paul Koning。このドキュメントは、これらすべての貢献の恩恵を受けました。
Editor's Address
編集者のアドレス
Mallikarjun Chadalapaka Hewlett-Packard Company 8000 Foothills Blvd. Roseville, CA 95747-5668, USA Phone: +1-916-785-5621 EMail: cbm@rose.hp.com
Mallikarjun Chadalapaka Hewlett-Packard Company 8000 Foothills Blvd.カリフォルニア州ローズビル95747-5668、米国電話：1-916-785-5621メール：cbm@rose.hp.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。