SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: keys/parameter dependence





    I think we can leave it to individual keys and say only that dependencies and how to handle them are specified with keys.

    Julo


    pat_thaler@agilent.com
    Sent by: owner-ips@ece.cmu.edu

    06/01/2002 03:02 AM
    Please respond to pat_thaler

           
            To:        John Hufferd/San Jose/IBM@IBMUS, mkrikis@yahoo.com
            cc:        Mike.Donohoe@quantum.com, ips@ece.cmu.edu
            Subject:        RE: iSCSI: keys/parameter dependence

           


    John,

    The part that might cause interoperability problems is different
    interpretations of which parameters action or acceptance is dependent on
    others. For instance, does the sentence mean that InitialR2T should be sent
    before FirstBurstSize and that FirstBurstSize doesn't need a response when
    the response to InitialR2T was Yes?

    If the sentence is left in, then it should be clarified by adding something
    such as:
    "The definition of a key specifies whether the key is dependent on any other
    keys."
    and if any of our current keys are dependent, add to those keys
    "This key is dependent on <key names>."
    If none are currently dependent, it would be reasonable to add to 11 "Currently,
    no Login/Text Operational keys are dependent."

    Pat

    -----Original Message-----
    From: John Hufferd [mailto:hufferd@us.ibm.com]
    Sent: Friday, May 31, 2002 2:38 PM
    To: Martins Krikis
    Cc: Mike Donohoe; 'ips@ece.cmu.edu'
    Subject: Re: iSCSI: keys/parameter dependence



    I do not see a problem with the Text, the previous key=value pairs are ones
    that were in previous PDUs or key=value pairs that were scanned previous to
    the current pair being scanned.  It is not clear that we have to write any
    thing else to help people understand the concept of previous.  I think we
    are straining at a nat here, and it is not worth the effort.

    I do not see the problem.

    .
    .
    .
    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


    Martins Krikis <mkrikis@yahoo.com>@ece.cmu.edu on 05/31/2002 01:15:26 PM

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


    To:    Mike Donohoe <Mike.Donohoe@quantum.com>, "'ips@ece.cmu.edu'"
          <ips@ece.cmu.edu>
    cc:
    Subject:    Re: iSCSI: keys/parameter dependence



    --- Mike Donohoe <Mike.Donohoe@quantum.com> wrote:

    > From 12-95 4.3.3 pg 80 (and also in 4.4 pg 83):
    >
    > Whenever parameter action or acceptance are
    > dependent on other parameters,
    > the dependent parameters MUST be sent after the
    > parameters on
    > which they depend. If they are sent within the same
    > command, a
    > response for a parameter might imply responses for
    > others.

    I've been ignoring this paraghaph having been
    convinced that there are no dependencies among
    the operational parameters (those allowed to be
    used in the operational stage of login), and that
    any dependencies for security parameters would
    be naturally observed by security protocols (i.e.,
    first send me this, I'll send you that, now
    send this, etc.).

    However, I think you raised some good questions.
    I think this paragraph should be removed.
    Here are the reasons:

    "(sent) after" isn't defined. It is unclear
    whether "in higher numbered bytes within the

    same PDU" qualifies as "after" or whether only
    "in a PDU sent at a later time" would. It's
    probably irrelevant, since due to the introduction
    of the C-bit, parameters can be accumulated and
    processed one "batch" at a time, without any
    specific order within the "batch" and they will
    quite likely not be processed PDU by PDU.
    Therefore, the text about them being sent in
    "the same command" is likely irrelevant, too,
    since many implementation simply won't check that.

    But what's really dangerous here is that an
    implementation that perceives some parameters
    as dependent may take the "might imply" text
    as an endorsement for sending back less key=value
    pairs than was received, which could make the
    other side never commit due to missing responses.
    We certainly don't want to allow for such a
    non-interoperability in the specification.

    So, could we please get rid of this whole
    paragraph?

    Thanks,

    Martins Krikis, Intel Corp.

    Disclaimer: these opinions are mine and may not
               be those of my employer.


    __________________________________________________
    Do You Yahoo!?
    Yahoo! - Official partner of 2002 FIFA World Cup
    http://fifaworldcup.yahoo.com








Home

Last updated: Sun Jun 02 09:18:50 2002
10454 messages in chronological order