Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture
RFC 4850
Document | Type |
RFC - Proposed Standard
(April 2007; No errata)
Obsoleted by RFC 7143
Updates RFC 3720
|
|
---|---|---|---|
Author | Dave Wysochanski | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4850 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Lars Eggert | ||
Send notices to | (None) |
Network Working Group D. Wysochanski Request for Comments: 4850 Network Appliance, Inc. Updates: 3720 April 2007 Category: Standards Track Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This document describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs. Wysochanski Standards Track [Page 1] RFC 4850 iSCSI Node Architecture April 2007 1. Introduction 1.1. Overview This document describes a declarative Public Extension Key, as defined by Section 12.22 of RFC 3720 [2], that may be used to communicate additional iSCSI node information to the peer node in a session. The information carried in the described key has been found to be valuable in real iSCSI customer environments as initiator and target vendors collaborate to resolve technical issues and better understand the interaction of iSCSI implementations. The key has been modeled after the HTTP "Server" and "User-Agent" header fields as specified in Sections 14.38 and 14.43 of RFC 2616 [3], with the text-value(s) of the key roughly equivalent to Product Tokens in Section 3.8 of RFC 2616 [3]. Note, however, that the text- value(s) in the key's list-of-values MUST conform to the Text Format as specified in Section 5.1 of RFC 3720 [2]. The key is sent during operational parameter negotiation of an iSCSI session's login phase. The intended use of this key is to provide enhanced logging and support capabilities, and to enable collection of iSCSI implementation and usage information. 1.2. Terminology 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 RFC 2119 [1]. 2. Definition The definition of the key is as follows, conforming to Sections 11 and 12 of RFC 3720 [2], with example list-of-values conforming to Section 5.1 of RFC 3720 [2]. The key is defined with a use of "LO", making it a Leading Only key, and does not modify Sections 11 or 12 of RFC 3720 [2]. Thus, the key MUST only be sent on the leading connection, MUST NOT be changed after the leading connection login, and MUST only be sent after the security negotiation login stage has completed (during operational negotiation login stage). The key may be sent during normal or discovery sessions. Wysochanski Standards Track [Page 2] RFC 4850 iSCSI Node Architecture April 2007 2.1. X#NodeArchitecture Use: LO, Declarative Senders: Initiator and Target Scope: SW X#NodeArchitecture=<list-of-values> Examples: X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5 X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686 The initiator or target declares the details of its iSCSI node architecture to the remote endpoint. These details may include, but are not limited to, iSCSI vendor software, firmware, or hardware versions, the OS version, or hardware architecture. The length of the key value (total length of the list-of-values) MUST NOT be greater than 255 bytes. X#NodeArchitecture MUST NOT be redeclared. 3. Implementation Functional behavior of the iSCSI node (this includes the iSCSI protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT depend on the presence, absence, or content of the key. The key MUST NOT be used by iSCSI nodes for interoperability, or exclusion of other nodes. To ensure proper use, key values SHOULD be set by theShow full document text