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

From: "Julian Satran" <[email-masked]>
Date: Tue, 12 Mar 2002 21:42:24 +0200

Luben has a good point about range notation. Julo

John Hufferd/San Jose/IBM@IBMUS
Sent by: [email-masked]
12-03-02 20:37
Please respond to John Hufferd

        To:     Paul Koning <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: iSCSI: Text/Operational keys: booleans and ranges

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: [email-masked]

Paul Koning <[email-masked]>@ece.cmu.edu on 03/12/2002 09:13:06 AM

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    Re: iSCSI: Text/Operational keys: booleans and ranges

>>>>> "Luben" == Luben Tuikov <[email-masked]> 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

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 12 Mar 2002 16:44:35 -0800

Julian,

I agree with your proposal to denote ranges with ":".

Also, as somewhat of a digression, I think we need to say 
something about the legality (or lack there of) of a negotiation 
involving multiple ranges as in:

Key=a:b, c:d, e:f

My not-too-strong opinion is that it could be useful to allow this...
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
[email-masked]

---

From: Paul Koning <[email-masked]>
Date: Wed, 13 Mar 2002 10:06:43 -0500

>>>>> "Mallikarjun" == Mallikarjun C <[email-masked]> writes:

 Mallikarjun> Julian, I agree with your proposal to denote ranges with
 Mallikarjun> ":".

 Mallikarjun> Also, as somewhat of a digression, I think we need to
 Mallikarjun> say something about the legality (or lack there of) of a
 Mallikarjun> negotiation involving multiple ranges as in:

 Mallikarjun> Key=a:b, c:d, e:f

 Mallikarjun> My not-too-strong opinion is that it could be useful to
 Mallikarjun> allow this...

We don't have an identified requirement for this.  We don't have a
reason for adding this to a spec that is supposed to be as close to
frozen as we can possibly get.  

This is NOT the time to keep adding features just "because it could be
useful".

The spec as currently written describes the use of exactly one range.
Leave it that way.  I don't have a problem with changing the delimiter
to ':' but I DO strongly object to any further extensions.

     paul