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

[<[e-mail]>]

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:[e-mail]]
> Sent: Tuesday, March 23, 2010 3:34 PM
> To: Black, David; [e-mail]
> 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
>