Re: iSCSI: Text/Operational keys: booleans and ranges

["John Hufferd" <hufferd@us.ibm.com>]

I agree with Paul, leave good enough alone for now.  We are trying to get
to last call, and changes which not absolutely needed are causing time to
elapse which is not worth the change.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


Paul Koning <ni1d@arrl.net>@ece.cmu.edu on 03/12/2002 09:13:06 AM

Sent by:    owner-ips@ece.cmu.edu


To:    ips@ece.cmu.edu
cc:
Subject:    Re: iSCSI: Text/Operational keys: booleans and ranges



>>>>> "Luben" == Luben Tuikov <luben@splentec.com> writes:

 Luben> 1. Is it possible to make all Boolean Text/Operational keys's
 Luben> value range be ``0'' and ``1'', rather than the current
 Luben> ``Yes'', ``No''.

 Luben> Since those are _Boolean_ values, what will be the objection
 Luben> to this?

 Luben> A user interface will probably display ``Yes'' and ``No'', but
 Luben> in the protocol, why burden implementations with string
 Luben> comparison, case-sensitive on top of this, rather than use
 Luben> strtol(), this making content check easier (strtol() will
 Luben> detect range errors, e.g. ``OFMarker=hello'').

That's a reasonable enough proposal, but I'm not convinced it's worth
changing at this time.

 Luben> 2. Why not make integer ranges, like OFMarkInt, use dash,
 Luben> ``-'' ASCII: 0x2d, like ``1-65535'', indicating all values in
 Luben> the interval.

Same comment -- a bit less strongly since this is a last minute
addition.  A dash, or a colon, would be ok.  (Double colon?  No
thanks.)

 Luben> The reason is that in the future there may be a
 Luben> text/operational key which can take only a set of distinct
 Luben> integer values, but no range, e.g. ``SomeBit=0,4,8,16'', That
 Luben> is ``SomeBit'' is still an integer variable but in negotiation
 Luben> it can choose between certain disctinct values. Furthermore
 Luben> the standard text/operational code which many of you already
 Luben> have written will work in this situation, only add
 Luben> atoi()/strtol() at the end...

I'm assuming you're not proposing the addition of "sets of distinct
values" as a negotiation option in V1, right?

It's time to stop making changes, even small changes, and freeze the
spec.  If it's not broken, let it stand.

 paul