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
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| 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.
Show full document text