[storm] iSCSI SAM update: login key

<Black_David@emc.com> Fri, 26 March 2010 18:47 UTC

Return-Path: <Black_David@emc.com>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 5ECF43A69B8 for <storm@core3.amsl.com>; Fri, 26 Mar 2010 11:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.4
X-Spam-Status: No, score=-3.4 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id nMzEnv-FrU9F for <storm@core3.amsl.com>; Fri, 26 Mar 2010 11:47:54 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com []) by core3.amsl.com (Postfix) with ESMTP id 622EA3A689A for <storm@ietf.org>; Fri, 26 Mar 2010 11:47:54 -0700 (PDT)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com []) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o2QImHh8010664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <storm@ietf.org>; Fri, 26 Mar 2010 14:48:17 -0400
Received: from mailhub.lss.emc.com (nagas.lss.emc.com []) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for <storm@ietf.org>; Fri, 26 Mar 2010 14:48:06 -0400
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com []) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o2QIm3dV028072 for <storm@ietf.org>; Fri, 26 Mar 2010 14:48:06 -0400
Received: from CORPUSMX80B.corp.emc.com ([]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 14:48:04 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Fri, 26 Mar 2010 14:48:03 -0400
Message-ID: <C2D311A6F086424F99E385949ECFEBCB021629C4@CORPUSMX80B.corp.emc.com>
Thread-Topic: iSCSI SAM update: login key
thread-index: AcrNFN17PQ3xD5CNTO+maRmCN0ae/g==
From: <Black_David@emc.com>
To: <storm@ietf.org>
X-OriginalArrivalTime: 26 Mar 2010 18:48:04.0921 (UTC) FILETIME=[DE7C5290:01CACD14]
X-EMM-EM: Active
Cc: Black_David@emc.com
Subject: [storm] iSCSI SAM update: login key
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Mar 2010 18:47:55 -0000

Based on discussion in the Anaheim meeting, here's the proposal that emerged for the login key to negotiate usage of the new features in the iSCSI SAM update draft (draft-ietf-storm-iscsi-sam-00).

Past concerns (that I can recall) about this have been:
- Key needs to negotiate iSCSI PDU format/content changes only.
- Detecting device support or lack thereof for SCSI features
	should be handled at the SCSI level (e.g., via SCSI commands).
- Using a SAM version number in this iSCSI key is not a good idea.
- Would like something that can accommodate future changes.
- Changing the key name from what's in the draft may be desired.

The proposal that emerged is:

The key name will be PDUFormatLevel.  It's a numeric (not boolean) key with two defined values:
	- 1 = Current iSCSI (all four RFCs - 3720, 3980, 4850 and 5048,
		but no change to required vs. optional features).
	- 2 = Current iSCSI plus features in update draft.
Usage is Leading Only (LO), scope is Session Wide (SW).
Default value is 1, result function is Minimum.

This will be an IETF key whose values are assigned by IETF standards action (standards-track RFC); it is not linked to SAM versions (e.g., a new version of SAM is not a prerequisite to assigning the value 3).

This key also provides a clean way to handle definition of iSCSI version descriptors in SPC-4:
- 0960h would remain "iSCSI (no version claimed)"
- The range 0961h-097Fh would be defined as 0960h + value
	of PDUFormatLevel key used by the device.
That results in one place (IANA registry) covering both definitions (key & version descriptor).

In order to support iSCSI version descriptors, we would ask IANA to put the values of the PDUFormatLevel key into a separate registry with its own URL, and then ask T10 to modify SPC-4.  The latter is not an immediate action - I would not anticipate bringing the SPC-4 proposal for that to T10 until after the RFC is published and the IANA registry is created.

This was the sense of the room + WebEx in Anaheim.  Absence of objection on the list will confirm the above as the approach to be taken (rough consensus of the storm WG).

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754