RE: iSCSI: Last Call process

[Paul Koning <ni1d@arrl.net>]

Excerpt of message (sent 4 April 2002) by Black_David@emc.com:
> > I'm pretty unhappy about this.  What I see is that, at the last
> > minute, a new protocol is introduced (DH-CHAP), and we're suddenly
> > being told that iSCSI has been made dependent on that new protocol.
> 
> It has not been made dependent; the WG has been instructed to consider
> DH-CHAP, but has *not* been instructed to use it.  For example, if the
> DH-CHAP proposal falls apart on technical grounds shortly after the
> Internet-Draft appears, that'll be the end of our consideration of it.

Is "consideration" valid if we only consider draft 00?  Or, if
technical issues are found in draft 00, are we then obliged to
consider up to draft N, for some N > 0?
 
> Paul conveniently deleted the portion of my previous message that
> described why there may be no schedule impact to iSCSI from this.
> Here it is again:
> 
>   Mock WG Last Call for iSCSI can be done prior to or in parallel
>   with this consideration.  In practice, I doubt this'll cause a major
>   hold-up, as the odds of iSCSI making it through WG Last Call on the
>   first attempt are very small (i.e., we're probably going to need at
>   least two "Last Call" processes, and hence whether the first one is
>   called "real" or "mock" doesn't make much difference in practice).
> 
>   My intention is to start a mock WG Last Call on version 12 of iSCSI
>   once it hits the I-D servers independent of the current state of DH-CHAP,
>   SRP, etc.

I agree that if DH+CHAP goes very fast, there may be no schedule
impact.  Then again, there may be a schedule impact.  I never said
that there would be an impact, only that there was a risk of an
impact. 

> > Why isn't that a decision for the WG to make?
> 
> Because the IESG has made that decision.  If the WG wants to get into a
> process fight with the IESG over who gets to make that decision, the
> resulting delays will dwarf anything that could result from consideration
> of DH-CHAP.  I would not advise this course of action.

When and where did the IESG make that decision?  Is there some message
from the IESG that documents the decision?  Is there a BCP that
describes the decision?

I'll try to stay away from process debates... but frankly, it's
difficult to have discussions of design issues in the WG or the list
if there are considerations driving the process that the WG and the
list are not made aware of.

> The IPR issue has not been 100% resolved.  Please re-read:
> 
> http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09466.html

Ok, so that says that there isn't a commitment for a free license, if
a license from Phoenix and/or Lucent should turn out to be required.
In what way does that not resolve the IPR issue?  Pat Thaler quoted
the IPR section of the RFC process; it does not mention free
licensing, only non-discriminatory licensing.

> > Introducing new work and thereby risk delaying the iSCSI standard is
> > NOT a good thing to have happen at this time.  We need to get this
> > standard finished.
> 
> I got the latter message loud and clear some time ago.  In a perfect
> world, the current situation is not the one I would choose to be in, but
> it is necessary to play the hand that we've been dealt.  The alternative
> of starting a process fight with the IESG will be far worse, IMHO.

I'm not sure I precisely know the security properties that DH+CHAP
aims for.  Obviously, a superset of what classic CHAP has.  Is the
goal to match SRP, or to deliver a subset of what SRP provides?  

What I'm struggling with is this: what set of properties of SRP, and
properties of DH-CHAP might we observe when the draft comes out that
would cause us to pick DH-CHAP over SRP when we do the
"consideration"?  I don't see a plausible scenario right now that
would produce that outcome.  That's one reason why I'm not happy with
what we're going through right now; it has a bit of a "rock fetching"
feel to it rather than what it should be, a technical analysis.

     paul