RE: iSCSI: Negotiating a parameter more than once

[Martins Krikis <mkrikis@yahoo.com>]

<marjorie_krueger@hp.com> wrote:

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

I don't see why the repetition of SendTargets and
MaxRecvDataSegmentLength must happen in the same
"negotiation sequence". If a node wants to repeat
them, it can easily cause it to happen in a new
sequence. Thus, I think that the paragraphs in
question do make sense and that only the keys sent
in response to SendTargets should be allowed to be
repeated.

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

The paragraphs are needed because they are the only
rules disallowing renegotiation and redeclaration
(in the same negotiation sequence). 

As to the future keys, I'd like them too to be
non-renegotiable. 


Martins Krikis, Intel Corp.

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


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