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

<Black_David@emc.com> Tue, 23 March 2010 22:28 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 9CECD3A692D for <storm@core3.amsl.com>; Tue, 23 Mar 2010 15:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.844
X-Spam-Level:
X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=1.625, BAYES_00=-2.599, 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 NW942yoLkbCt for <storm@core3.amsl.com>; Tue, 23 Mar 2010 15:28:48 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 9160C3A68C0 for <storm@ietf.org>; Tue, 23 Mar 2010 15:28:48 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o2NMT6KE011853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Mar 2010 18:29:06 -0400
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 23 Mar 2010 18:28:54 -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 o2NMSsOU007723; Tue, 23 Mar 2010 18:28:54 -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 18:28:54 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Mar 2010 18:28:52 -0400
Message-ID: <C2D311A6F086424F99E385949ECFEBCB020DAC2D@CORPUSMX80B.corp.emc.com>
In-Reply-To: <D8CEBB6AE9D43848BD2220619A43F326538F55@M31.equallogic.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [storm] iSCSI and Unicode (newprep BOF)
Thread-Index: AcrKL8paRodDqgKHQVq2eNKhUajyAQASD8BAAAuYuMAABglLsAAGSzNg
References: <C2D311A6F086424F99E385949ECFEBCB01FA6ADD@CORPUSMX80B.corp.emc.com> <D8CEBB6AE9D43848BD2220619A43F326538EF2@M31.equallogic.com> <C2D311A6F086424F99E385949ECFEBCB020DAA1B@CORPUSMX80B.corp.emc.com> <D8CEBB6AE9D43848BD2220619A43F326538F55@M31.equallogic.com>
From: <Black_David@emc.com>
To: <Paul_Koning@Dell.com>, <storm@ietf.org>
X-OriginalArrivalTime: 23 Mar 2010 22:28:54.0322 (UTC) FILETIME=[38813920:01CACAD8]
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 22:28:49 -0000

Paul,

I concur with your reasoning, example and strong desire for "MUST".

The newprep BOF is starting now - I'll report on results.

Thanks,
--David

> -----Original Message-----
> From: Paul Koning [mailto:Paul_Koning@Dell.com]
> Sent: Tuesday, March 23, 2010 3:34 PM
> 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.
> >
> > 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).
> 
> If so, then so be it.  I really do want MUST here.
> 
> Consider a simple example.  To avoid getting deep into Unicode, let's
> use an ASCII analogy.  Let's say the old rule is that names are
prepped
> by tolower() and the new rule says they are prepped by toupper().  And
> let's assume that this operation is done only when the target name is
> mentioned in some management UI as you suggested.  (I think we might
do
> it also at login, but it doesn't actually affect the outcome of the
> example in a way that matters.)
> 
> Ok, so in the old version, the admin asked me to create target Foo,
> which I prepped to "foo", so we now have that target.  Next the user
> tells the initiator to log in to Foo and the initiator preps that to
> "foo" which comes across the login protocol exchange and all is well.
> 
> Now we go to the new rule.  The admin sets up a new initiator, and
tell
> it to connect to Foo.  That initiator UI preps the string, which
results
> in "FOO".  That comes across in the login.  We do binary compare at
> login time, so the result of the login operation is "no such target".
> 
> You might think you can cure this problem by re-prepping all
previously
> stored names with the new rules.  That works ONLY if (a) all
previously
> valid names are still valid, (b) all previously distinct names are
still
> distinct.
> 
> We clearly can't have a case where an existing iSCSI target becomes
> inaccessible because of new name rules; this is my reason for saying
> that any newprep changes MUST not have such an effect.
> 
> 	paul
>