FMarker, RFMarkInt and SFMarkInt negotiation

[Martins Krikis <mkrikis@yahoo.com>]

Dear list members,

I seem to be having problems (or at least mild
surprises) reading A.3.1 to A.3.3 of draft 10.

Would you mind answering a few questions and hearing
out some beginner's ideas? Many thanks in advance.

Is it true that RFMarkInt when used by initiator 
means the intervals for the T->I direction, while
this same key used by target refers to the I->T
direction? Similarly (well, dually) for SFMarkInt?

That is, if initiator starts the negotiation and sends
  FMarker=receive; RFMarkInt=17,51
the target should answer with something like
  FMarker=send; SFMarkInt=34
(the numbers used are just examples).

I'm not sure that RFMarker is properly negotiated
if the answer for it comes with the key "SFMarker"...

The fact that FMarker=receive by originator
is the same as FMarker=send by responder isn't 
pretty either, but at least the given example
leaves no doubt. Or does it? What if send/receive
is always with respect to the target? It would
contradict the general principle that most everything
in iSCSI is named with respect to initiator, but
no example eliminates this possibility...

May I suggest that we use something like ITFMarkInt
and TIFMarkInt to unambiguously show which 
direction is being talked about?

I would also love to tinker with FMarker values
a bit, ideally get rid of it (thus getting rid of
a clear parameter dependency), and use ITFMarkInt=0
and TIFMarker=0 to denote that markers are not in
use in the respective direction.

Any comments will be greatly appreciated.

  Martins Krikis

P.S. I am not really a fan of features that are 
     useless for software implementations and that
     break protocol layering, but would like to at
     least understand how they are to be negotiated...


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com