SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: Last Call process



    > 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.
    
    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.
    
    > 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.
    
    > What has changed in the past month that made DH-CHAP relevant?  For a
    > long time now, the iSCSI drafts have mentioned only SRP and (classic)
    > CHAP, with the former mandatory and the latter optional.  The IPR
    > issue has been resolved (for SRP), so that can't be the trigger.
    
    The IPR issue has not been 100% resolved.  Please re-read:
    
    http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09466.html
    
    > 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.
    
    Thanks,
    --David
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
    black_david@emc.com         Cell: +1 (978) 394-7754
    ---------------------------------------------------
    


Home

Last updated: Thu Apr 04 15:18:20 2002
9501 messages in chronological order