SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: profiles - a way to simplify iSCSI



    
    
    Somesh,
    
    You are still missing my point. Profiles are not proposed "in addition" to
    what we have but instead of.
    They are not meant to remove features that where introduced for a
    legitimate reason or another but rather to limit
    the variability in implementations and testing.
    
    Julo
    
    "Somesh Gupta" <someshg@yahoo.com> on 22-06-2001 21:16:33
    
    Please respond to someshg@yahoo.com
    
    To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
    cc:
    Subject:  RE: profiles - a way to simplify iSCSI
    
    
    
    
    Julian,
    
    I think a number of our colleagues are speaking about the
    complexity of the spec as it stands today and the need
    to reduce the complexity.
    
    As I said, if a reasonable profile gets agreed upon (I apologise
    in advance but I have not seen the ability to say no to feature
    creep here), then that will become the de-facto standard. And
    everything else will be an appendage.
    
    We might as well do that to start with.
    
    It is much better to do that, and as Steph suggested, add
    features that are required in a newer rev of the spec. It is
    not as if standards don't evolve.
    
    John Vrabel's message indicates a very good starting point
    for pruning the spec (I disagree on the asynch messages).
    
    Somesh
    
    > -----Original Message-----
    > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    > julian_satran@il.ibm.com
    > Sent: Friday, June 22, 2001 8:15 AM
    > To: ips@ece.cmu.edu
    > Subject: RE: profiles - a way to simplify iSCSI
    >
    >
    >
    >
    > Robert,
    >
    > Profiles are meant INSTEAD -OF not in addition to the current set of
    > features.
    > I appreciate your concerns but I think that I must have misstated the
    > profile intention.
    > A profile will be an exact mapping of a set of functions we have today.
    > As such it will be SIMPLER both to implement and test.
    >
    > Julo
    >
    > "Robert Griswold" <rgriswold@crossroads.com> on 22-06-2001 17:19:47
    >
    > Please respond to "Robert Griswold" <rgriswold@crossroads.com>
    >
    > To:   Julian Satran/Haifa/IBM@IBMIL
    > cc:   ips@ece.cmu.edu
    > Subject:  RE: profiles - a way to simplify iSCSI
    >
    >
    >
    >
    > Julian:
    >
    > Well, drawing on my experience from the consumer storage specs
    > (ATA/ATAPI/MMC), profiles and features lead to huge interoperability
    > problems.  The issue for robust (full featured) targets and initiators
    > is they have to chase down every single interpretation of feature sets,
    > some that they don't even care about, so the devices are not caught in
    > transport or command sequences they have no idea about.  I am in
    > agreement with David Black and others who have specified that the iSCSI
    > transport needs simplicity rather than complexity; I fear that providing
    > still more optional implementations would lead to more problems.  If we
    > believe the hype from the press, then iSCSI will make for cheap targets,
    > which means fast product schedules and low engineering and test coverage
    > from companies that could ship millions of little iSCSI boxes.  A
    > tighter iSCSI specification might help keep some of these potential
    > interoperability problems from becoming wildfires.
    >
    > Bob
    >
    > Robert Griswold
    > Technologist
    > Crossroads Systems, Inc.
    > 512-928-7272
    >
    >  -----Original Message-----
    > From:     julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
    > Sent:     Thursday, June 21, 2001 12:15 PM
    > To:  ips@ece.cmu.edu
    > Subject:  profiles - a way to simplify iSCSI
    >
    >
    >
    > Dear colleagues,
    >
    > iSCSI keeps getting richer in negotiable parameters/features.
    > Although flexibility is a great thing every new negotiable
    > parameter/feature get us all worrying about:
    >
    >    what it will break when used in combination with other
    >    parameters/features
    >    how are we going to test that all our combinations work as we think
    > that
    >    they are specified
    >    are we understanding/specifying the combinations the same way as
    > anybody
    >    else
    >
    >
    > I assume that many of you are wondering, as I do, if all this
    > flexibility
    > is really worth it's price.
    > Would the community not be better served by specifying profiles that are
    > a
    > complete-and-invariable combination of features and very small set of
    > numerical parameters?
    >
    > I would start with 2 profiles:
    >
    >    the minimal profile (only basic features)
    >    the maximum profile (all the features)
    >
    > and then (only if we are strongly convinced it is needed) add a middle
    > point.
    >
    > Please comment,
    > Julo
    >
    >
    >
    >
    >
    >
    
    _________________________________________________________
    Do You Yahoo!?
    Get your free @yahoo.com address at http://mail.yahoo.com
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:24 2001
6315 messages in chronological order