Re: [storm] iSCSI and Unicode (newprep BOF)

<Black_David@emc.com> Tue, 23 March 2010 17:23 UTC

Return-Path: <Black_David@emc.com>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680D53A6CB0 for <storm@core3.amsl.com>; Tue, 23 Mar 2010 10:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.219
X-Spam-Level:
X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puu91Wc5CvlQ for <storm@core3.amsl.com>; Tue, 23 Mar 2010 10:23:35 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 14D423A6CA3 for <storm@ietf.org>; Tue, 23 Mar 2010 10:23:34 -0700 (PDT)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o2NHNqeV025289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Mar 2010 13:23:52 -0400
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 23 Mar 2010 13:23:37 -0400
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o2NHNTdX020274; Tue, 23 Mar 2010 13:23:35 -0400
Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 13:23:30 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Mar 2010 13:23:29 -0400
Message-ID: <C2D311A6F086424F99E385949ECFEBCB020DAA1B@CORPUSMX80B.corp.emc.com>
In-Reply-To: <D8CEBB6AE9D43848BD2220619A43F326538EF2@M31.equallogic.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [storm] iSCSI and Unicode (newprep BOF)
Thread-Index: AcrKL8paRodDqgKHQVq2eNKhUajyAQASD8BAAAuYuMA=
References: <C2D311A6F086424F99E385949ECFEBCB01FA6ADD@CORPUSMX80B.corp.emc.com> <D8CEBB6AE9D43848BD2220619A43F326538EF2@M31.equallogic.com>
From: <Black_David@emc.com>
To: <Paul_Koning@Dell.com>, <storm@ietf.org>
X-OriginalArrivalTime: 23 Mar 2010 17:23:30.0986 (UTC) FILETIME=[8EF208A0:01CACAAD]
X-EMM-EM: Active
Subject: Re: [storm] iSCSI and Unicode (newprep BOF)
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: Tue, 23 Mar 2010 17:23:36 -0000

Paul,

Thanks for the quick response.

> Re "Any update SHOULD be backward compatible with RFC 3722" -- I don't understand the "SHOULD".  The
> obvious word is "MUST".  More precisely -- and maybe this is where the "SHOULD" came in? -- an IQN
> that was legal under RFC 3722 must still be legal, and two names that under the old rules were
> considered different must still be different.

The "SHOULD" is there to a significant extent so that I can plead "I'm not a Unicode expert" ;-).  At the iSCSI protocol level, I expect everything to be backwards-compatible because iSCSI names aren't checked for stringprep compliance on login (the iSCSI name string comparison for equality is basically opaque wrt Unicode issues).

Moving up to the iSCSI name input level (human involvement), it is possible that things have changed in Unicode so that the same Unicode input string will need to map to a different newprep output string vs. stringprep output string for reasons involving Unicode.  If that's the case (and especially if some previously valid inputs have to be prohibited), then everything will need to be carefully explained and documented with advice on how to cope ... but I hesitate to lead with a "MUST", as the IDN folks have much deeper knowledge of what's going on here, what needed to be done with Unicode domain names, and why (a "MUST" risks freezing iSCSI @ an old version of Unicode).

> Do you have a pointer to places to start to learn what newprep is all about?

Look for newprep materials here: https://datatracker.ietf.org/meeting/77/materials.html

Today's meeting is a BOF to talk about whether there's a problem and what to do about it.  If the conclusion is that something needs to be done, details will emerge.

Thanks,
--David


> -----Original Message-----
> From: Paul Koning [mailto:Paul_Koning@Dell.com]
> Sent: Tuesday, March 23, 2010 7:03 AM
> To: Black, David; storm@ietf.org
> Subject: RE: [storm] iSCSI and Unicode (newprep BOF)
> 
> Re "Any update SHOULD be backward compatible with RFC 3722" -- I don't understand the "SHOULD".  The
> obvious word is "MUST".  More precisely -- and maybe this is where the "SHOULD" came in? -- an IQN
> that was legal under RFC 3722 must still be legal, and two names that under the old rules were
> considered different must still be different.
> 
> Do you have a pointer to places to start to learn what newprep is all about?
> 
> 	paul
> 
> > -----Original Message-----
> > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf
> > Of Black_David@emc.com
> > Sent: Monday, March 22, 2010 10:23 PM
> > To: storm@ietf.org
> > Cc: Black_David@emc.com
> > Subject: [storm] iSCSI and Unicode (newprep BOF)
> >
> > I'll be giving a short presentation on iSCSI and Unicode to the newprep
> > BOF tomorrow afternoon in Anaheim:
> > http://www.ietf.org/proceedings/10mar/slides/newprep-2.pdf
> >
> > The short story here is that Unicode and international domain names
> > have moved beyond the stringprep technique that iSCSI uses (RFC 3722 is
> > the stringprep profile for iSCSI), so this BOF is exploring a framework
> > update to stringprep that should allow iSCSI to move forward with
> > Unicode changes.
> >
> > For anyone interested in exploring further, the rest of the materials
> > for this BOF would be a good place to start.
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > 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
> > ----------------------------------------------------
> >
> > _______________________________________________
> > storm mailing list
> > storm@ietf.org
> > https://www.ietf.org/mailman/listinfo/storm