Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture
RFC 4850

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

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 the