SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Some proposed vendor-specific (X-) keys



    Paul,
    
    I agree. This would also create a testing nightmare for initiator
    developers. If the initiator has adapts itself for n targets then 
    it has n different personalities that all need to be tested.
    
    We have interoperability testing to help us find and fix
    spec ambiguities that cause interoperability problems. 
    
    The way to build market for iSCSI is to have interoperability - 
    not to have cases wher Brand_x Target doesn't work with Brand_y 
    Initiator because Brand_y doesn't have the tweak profile for 
    Brand_x.
    
    Regards,
    Pat
    
    -----Original Message-----
    From: Paul Koning [mailto:ni1d@arrl.net]
    Sent: Thursday, June 06, 2002 1:06 PM
    To: bmastors@allocity.com
    Cc: ksandars@eurologic.com; ips@ece.cmu.edu
    Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys
    
    
    >>>>> "Bob" == Bob Mastors <bmastors@allocity.com> writes:
    
     Bob> I like it.  Otherwise the user has to configure the initiator
     Bob> with the target type and the target with the initiator type.  It
     Bob> is unlikely that this problem will disappear for a long time if
     Bob> ever.  As the threads on the C bit has shown there will be lots
     Bob> of ways to implement the spec and probably no device will
     Bob> correctly support all possibilities.  I am already putting "if
     Bob> (vendor)" code in my implementation. Maybe in a few years I will
     Bob> not need it. But until then it would be nice if I could
     Bob> dynamically determine vendor information for iscsi so the user
     Bob> does not have to configure it. 
    
    Oh boy, now I'm well and truly frightened.
    
    I read your message as saying that there isn't going to be
    interoperability for several years.  Sorather than create a serious
    incentive for implementers to fix their defects, we should implement a
    way to have them report which collection of defects they implement so
    we can invoke workaround collection #42.  Of course, the larger the
    collection of crocks we work around, the larger the number of bugs in
    implementations that everyone else will have to work around.
    
    In the words of a well known American, "Just Say NO".
    
         paul
    


Home

Last updated: Fri Jun 07 14:18:44 2002
10588 messages in chronological order