Re: FMarker, RFMarkInt and SFMarkInt negotiation

[Martins Krikis <mkrikis@yahoo.com>]

--- Julian Satran <Julian_Satran@il.ibm.com> wrote:
> What would the IT and TI add? The information is
> already available in the 
> PDU (IT and IT PDUS are different).

They would add clarity and consistency to text
negotiation. 

The concepts being negotiated are
"fixed interval markers for the initiator to target
direction" and "fixed interval markers for the target
to initiator direction". So why should the keys used
in negotiating these concepts be different depending
on who sent them? If I'm implementing negotiation, I
now have to do an extra mapping from a key (e.g.,
RFMarkInt) to the concept (ITFMarkInt or TIFMarkInt)
and this mapping is different for initiators and
targets (for the same operation, where operations
are send/receive). Plus, if the sequence I mentioned

  (initiator offers) FMarker=receive; RFMarkInt=17,51
  (target responds)  FMarker=send;    SFMarkInt=34

is correct, then it does not fit well in section
2.2.4, where the general format seems to mandate
answering with the same KEY (not the same concept).
A little further down there is also a requirement
to answer numerical negotiations with the "required
key". If the "required key" may or may not be the
same key that was received, this should be mentioned.
(Of course, one could argue that this is not a
numerical negotiation, because ranges are allowed,
not just single numbers, but this, too is not obvious
to the casual reader.)

What I was proposing was simply naming the keys
after the concepts and avoiding the extra mapping
step and seeming conflicts with 2.2.4. I am a pedant.

As to FMarker, its negotiation is very different
from everything else in that it may look like a list
negotiation because of the list of possible values
given, but it isn't. It is yet another special-case
parameter, and one that RFMarkInt and SFMarkInt
depend on. 

I was suggesting getting rid of it altogether by
allowing RFMarkInt/SFMarkInt (or, better yet,
ITFMarkInt, TIFMarkInt) to carry value 0, which
would mean that markers are not in use in the
respective direction.

Just because all the information is there and because
implementation is possible, it doesn't mean that it
cannot be organized more logically and simplify
implementations.

IMO, key names should match concept names regardless
of how and by whom they are being used; and all
parameter dependencies for operational phase should
be eliminated.

  Martins Krikis, Intel Corp.

Disclaimer: these opinions are my own and not
            necessarily those of my employer.

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