Subject: RE: iSCSI: Negotiation clarifications still needed

From: [email-masked]
Date: Tue, 28 May 2002 16:17:25 -0600

Martin,

You don't have to send a declaration but there is no reason to 
prohibit you from doing so. If you would rather not check type,
then don't send any new keys when one is incomplete.

Thank you for pointing out that MaxRecvPDUDataSize isn't marked
declaritive. It is subject to declaration so it should be marked
declaritive and another label should be used to indicate
that the key can be send during SecurityNegotiation stage.

I suggest that keys that can be sent during SecurityNegatiation stage
should have SN added to Use because use has the other information 
about when a key can be sent.

I think clearly identifying which keys are not subject to negotiation
is on topic for clarifying negotiation. 

Declarations are involved in the spanning/non-spanning issue. When 
one has gotten only a partial key one doesn't know whether it is 
a declaration or a negotiation.

Pat

-----Original Message-----
From: Martins Krikis [mailto:[email-masked]]
Sent: Tuesday, May 28, 2002 2:42 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: iSCSI: Negotiation clarifications still needed

--- [email-masked] wrote:

> One could add after the second sentence "It may send
> key-value responses
> and declarations."

I would rather not involve declarations here. It
seems like a good idea to remind that responses
may be sent, but I don't like having to start
checking key types in order to figure out whether
I should send it (or whether I can "nail" the other
side for sending it :-)).

> the sentence:
> "Keys which are subject to declaration rather than
> negotiation are marked declarative."

This isn't entirely true, because MaxRecvPDUDataSize
is subject to declaration but isn't marked declarative
at the moment. 

I actually suggest not involving declarations in
the non-spanning issue. Yes, we may end up sending a 
key or two later than would be possible otherwise,
but the property that all keys (whether declarative
or not) can be treated the same way by far outweighs
this.

> Ideally one would use different labels to
> indicate that a key was subject to declaration and
> that it could be sent in SecurityNegotiation stage.

True, but we're getting off-topic.

P.S. Just because I'm commenting on this does not
     mean that I've changed my mind about my own
     proposal---I still think it is simplest.

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

---

From: Martins Krikis <[email-masked]>
Date: Tue, 28 May 2002 15:51:05 -0700 (PDT)

--- [email-masked] wrote:

> prohibit you from doing so.

I know that I don't have to. That's why I said
"should" and not "MUST". I should have said "ought",
perhaps. But there is a reason to prohibit this.
The reason is that then all keys can be treated the
same way regarding whether they can be originated
(or spanned, or whatever, depending on which variation
on this theme we end up with).

> If you would rather not
> check type,

I know. But w/o checking type I can't "nail" the 
other side for breaking the rules :-).

> is on topic for clarifying negotiation. 

This is all very good, but we didn't have to mix
this issue with the spanning issue. It is IMHO
off-topic w.r.t. the spanning issue, which this
thread has migrated into. For clarifying negotiation,
yes, very much on topic.

> Declarations are involved in the
> spanning/non-spanning issue.

Not unless you start involving them.

> When 

OK. And I prefer ignoring whether a key is a
declaration or a negotiation even when I have
received it complete or am planning to originate
it. I have flags telling which sides may use
the key, and I have functions for choosing
a value. I don't have to care about declarations
currently and would love to keep it that way.

I think you're just making your own scheme
subtly more difficult to describe and slightly
more difficult to implement for those that want
to take full advantage of the little additional 
performance benefit that it offers. I see, of
course, that it works. And I can implement it,
and it probably won't even take too long to do
that. The point is that this extra optimization
is yet another (very slight) complication in the
protocol. You are further optimizing a "corner
case", when we really should have opted for the
absolute simplicity in this "corner case".

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