SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: default values



    I agree - especially in light of the fact that (as currently specified) an
    initiator can "change it's mind" about when it's ready to exit the OPN phase
    of login (section 5 states "In a negotiation sequence, the T bit settings in
    one pair of login request-responses have no bearing on the T bit settings of
    the next pair.  An initiator having T bit set to 1 in one pair and being
    answered with an T bit setting of 0 may issue the next request with T bit
    set to 0.") so the target can't even use the setting of the T bit to decide
    when to assume the initiator has "implied a default selection".
    
    Marjorie Krueger
    Networked Storage Architecture
    Networked Storage Solutions Org.
    Hewlett-Packard
    tel: +1 916 785 2656
    fax: +1 916 785 0391
    email: marjorie_krueger@hp.com 
    
    > -----Original Message-----
    > From: Black_David@emc.com [mailto:Black_David@emc.com]
    > Sent: Monday, October 15, 2001 4:03 PM
    > To: ips@ece.cmu.edu
    > Subject: iSCSI: default values
    > 
    > 
    > Default values may be difficult to define for text keys added after
    > the first stable version of the spec.  The problem is that an
    > originator who does not send a text key cannot distinguish between:
    > 
    > - a responder who understands the key and implements the default AND
    > - a responder who does not understand the key and does something
    > 	acceptable under a version of the spec prior to introduction
    > 	of the key.
    > 
    > This whole notion of omitting a key being equivalent to sending
    > it with its default value strikes me as potentially problematic.
    > I would have thought that omitting a text key was equivalent to
    > "Don't Care" with the default values being "RECOMMENDED" rather
    > than "MANDATORY".  This leads to the following rule, which I think
    > should go in regardless:
    > 
    > - An implementation whose operational correctness and/or performance
    > 	depends on the value of a text key MUST explicitly negotiate
    > 	that key.
    > 
    > This is somewhat like the old adage about voting - those who do not
    > vote should not complain about the results, and leads to more robust
    > negotiation exchanges because mismatched assumptions about defaults
    > get exposed.
    > 
    > I realize this yields additional messages in some cases, but would
    > suggest that the additional negotiation robustness is an offsetting
    > benefit.
    > 
    > Comments?
    > --David
    > ---------------------------------------------------
    > David L. Black, Senior Technologist
    > EMC Corporation, 42 South St., Hopkinton, MA  01748
    > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    > black_david@emc.com       Mobile: +1 (978) 394-7754
    > ---------------------------------------------------
    > 
    


Home

Last updated: Wed Oct 17 13:17:26 2001
7268 messages in chronological order