SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

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




    Luben has a good point about range notation. Julo


    John Hufferd/San Jose/IBM@IBMUS
    Sent by: owner-ips@ece.cmu.edu

    12-03-02 20:37
    Please respond to John Hufferd

           
            To:        Paul Koning <ni1d@arrl.net>
            cc:        ips@ece.cmu.edu
            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: 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








Home

Last updated: Tue Mar 12 20:18:12 2002
9077 messages in chronological order