|
Sorry Pat, I read
your response too quickly and misinterpreted the definition of "negotiation
sequence". I agree with you, the text you suggest is
appropriate.
In addition, it
would be nice if section 11 had an explicit "Use" indication
distinguishing keys that can be repeated w/in a declaration sequence
(targetAddress, targetAlias, targetName) and keys that cannot be
repeated.
You mentioned that
you couldn' t find text that says the SendTargets command can be repeated w/in a
declaration sequence - in fact, Appendix D paragraph
6 says:
"A SendTargets
command consists of a single Text request PDU.
This
PDU contains exactly one text key and value. The text key MUST
be SendTargets. The expected response depends
upon the value, as
well as whether the session is a
discovery or operational session."
This seems OK to me,
if an initiator wants information about another target, it can just initiate
another SendTargets "negotiation sequence"??
Marj
-----Original Message-----
From:
KRUEGER,MARJORIE (HP-Roseville,ex1)
[mailto:marjorie_krueger@hp.com]
Sent: Wednesday, June 19, 2002 11:32
AM
To: 'THALER,PAT (A-Roseville,ex1)'; Julo-Actcom;
ips@ece.cmu.edu
Subject: RE: iSCSI: Negotiating a parameter more than
once
In the context of the two keys that are valid during
FFP, neither of these suggested edits to that paragraph make sense.
Currently, there is no "negotiation" key that's valid in FFP, and the
"declarative" keys that are valid, - SendTargets and
MaxPDUDataLength *can* validly be repeated. If an initiator opens a
discovery session, it may keep it open, and it may repeat SendTargets requests
as it deems necessary to keep it's target information up to date. In the
course of a SendTargets response, the target validly repeats certain
keys. The MaxPDUDataLength key can be sent by the initiator as often as
the PMTU changes.
Why not just delete this paragraph? In the
future if there are keys added that are valid during FFP, the RFC that
specifies those keys can specify whether or not they can be
"renegotiated".
Marjorie
Krueger
Networked Storage Architecture
Networked Storage Solutions
Org.
Hewlett-Packard
Julian,
If declarations
should not be repeated (except for those where it is explicitly allowed),
then it should be "negotiate or declare" because "negotiate" doesn't cover
declarations. Alternatively, one could add an explicit definition that
"Negotiate" includes both declarations and negotiations. Secondly,
SendTargets is not a valid example for login as it is FFPO. I think the
only parameter explicitly allowed to be duplicated during Login is
TargetAddress (when returned as a result of a redirect). Furthermore, I can
not find any explicit statement that SendTargets may be repeated during a
FFP negotiation sequence. Only TargetName and TargetAddress have explicit
text allowing them to be repeated (in Appendix B for both and in the
description of redirection for LoginResponse for
TargetAddress).
Therefore, I
suggest:
For
4.3:
Neither the initiator nor the target
should attempt to declare or negotiate a parameter more than once during
login except for responses to specific keys that explicitly allow repeated
key declarations (e.g. TargetAddress). If detected by the target this MUST
result in a Login reject (initiator error). The initiator MUST drop the
connection
For
4.4:
Neither the initiator nor the target should attempt to declare or
negotiate a parameter more than once during any negotiation sequence without
an intervening reset except for responses to specific keys that explicitly
allow repeated key declarations (e.g. TargetAddress). If detected by the
target this MUST result in a Reject with a reason of "protocol error". The
initiator MUST reset the negotiation as outlined above.
Pat
Pat,
4.3 and 4.4 cover two diferent
phases.
Parameters should not be negotiated or declared
twice.
I think that you refer to the responses to
SendTargets - those contain more than an instance of the declarations and
have to outlined.
How about the following text in
4.4:
Neither the initiator nor the target should attempt to negotiate a
parameter more than once during login except for responses to specific keys
that explicitly allow repeated key declarations (e.g. SendTargets). If
detected by the target this MUST result in a Login reject (initiator error).
The initiator MUST drop the connection.
and in
4.4:
Neither the initiator nor the target should attempt to negotiate a
parameter more than once during any negotiation sequence without an
intervening reset except for responses to specific keys that explicitly
allow repeated key declarations. If detected by the target this MUST result
in a Reject with a reason of "protocol error". The initiator MUST reset the
negotiation as outlined above.
Julo
|
