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

    Re: iSCSI: key negotiation - Unrecognized value?

    >>>>> "Luben" == Luben Tuikov <> writes:
     Luben> Marjorie, Julian, all, When a value doesn't belong to the
     Luben> valid set of assignable values to a key, but is offered, as
     Luben> Marjorie's example, shouldn't the following take place:
     Luben>  Originator-> MaxConnections=yes
     Luben>  Responder-> MaxConnections=NotUnderstood
    That doesn't sound right, because the spec says that NotUnderstood
    applies to keys, not to values.
    The best fit is "reject" though the wording of the spec doesn't really
    say that.  Actually, the spec is unconfortably fuzzy about all this
    stuff; for example, the fact that it says '...may use the constant
    "Reject"' is weird.  I assume that should be "...MAY use..." but why
    does it say "may" -- what other alternative is there?  
    For the case here, a single (non-list) key with a syntactically
    invalid value, I can't get particularly excited about the answer.
    Dealing elegantly with defective initiators isn't all that critical.
    Sure, if it's easy and reasonable (which it seems to be) let's
    generalize the wording for "Reject" so it clearly applies to this case.
     Luben> Also, isn't ``Reject'' used for a valid, assignable value, but
     Luben> for which the responder has no resources:
     Luben>  Originator-> MaxConnections=4294967296
     Luben>  Responder-> MaxConnections=Reject
    I don't think so.  That's a numeric negotiation, lower value wins.  So
    the responder must pick a number it supports <= the value supplied by
    the originator.  "Reject" would be valid if there is no such number.
    (That's not possible for this particular key.)
    A way to justify "reject" is with the argument that 4294967296 is not
    a valid integer string here because it is out of range.  True, and
    that would justify treating it as no different from initiator saying
    "yes" for this key.  Then again, I'd expect that a lot of responders
    would simply run the key through atoi(), observe that this worked, see
    that the value is too large, and reply with an acceptable value.


Last updated: Wed Feb 20 18:18:00 2002
8816 messages in chronological order