Re: [Ips] I-D ACTION:draft-ietf-ips-iser-00.txt

Section 7.3.6 clause 4.b appears to make an inappropriate requirement
on the local interface.

>    4.  If the iSER-ORD value at the target is set to greater than 0,
>        the iSER Layer at the target MUST transform the R2T PDU into an
>        RDMA Read Request Message.  While transforming the R2T PDU, the
>        iSER Layer at the target MUST ensure that the number of
>        outstanding RDMA Read Request Messages does not exceed iSER-ORD
>        value.  To transform the R2T PDU, the iSER Layer at the target:
>
>        a.  MUST derive the local STag and local Tagged Offset from the
>            DataDescriptorOut that qualified the Get_Data invocation.
>
>        b.  MUST use the local STag as the Data Sink STag of the RDMA
>            Read Request Message.

It would be legitimate to require that the Data Sink STag must be used 
for the
RDMA Read Request *operation* submitted to RDMAP.  However the
RDMAP layer should be free to form the wire Data Sink STag used in
an RDMA Read Message on its own.  There are security benefits when
supporting transport neutral APIs.

Clause a) hints at the desirability of this type of flexible mapping. 
However,
as drafted this flexibility would only be available at the iSER layer. 
The option
to flexibly map a target Data Descriptor to a local STag is just as 
important
for the RDMAP layer itself, and when dealing with the RDMA Read Data
Sink STag the protocol provides the required flexibility to the 
implementation.
The iSER draft should recognize this flexibility. This is actually a 
documentation
issue, since obviously the iSER level cannot prevent the RDMAP layer 
from
implementing such an optimization. But false implications can still 
mislead
those developing wire validation suites, which might lead to false 
detections
of "protocol violations" that were in fact totally legal and 
interoperable.