So, since RES is now obsolete I would propose:

a. Exchange originating S_ID field value shall match the S_ID field value in the FC Header, or

b. obsolete the Exchange originating S_ID field in the REC payload (and the associated address fields in the Reply too).

...Dave

(no disclaimer)

From: Neil Wanamaker [mailto:Neil_Wanamaker@pmc-sierra.com]
Sent: Friday, April 21, 2006 12:56 PM
To: David Peterson; t10@t10.org; t11_3@t11.org
Subject: RE: [T11.3] FCP-3/FC-LS: Use of REC

The presence of the S_ID in the request is a legacy of having been adapted from RES, which had a similar capability.

Neil

From: t11_3-bounce@mailman.listserve.com [mailto:t11_3-bounce@mailman.listserve.com] On Behalf Of David Peterson
Sent: Friday, April 21, 2006 10:25 AM
To: t10@t10.org; t11_3@t11.org
Subject: [T11.3] FCP-3/FC-LS: Use of REC

Howdy,

FC-LS currently specifies the Exchange originating S_ID field in the REC payload may be different than the address identifier of the source (and destination) of the REC. From FC-LS rev 1.2 subclause 4.2.55.1:

"This ELS shall be used only for purposes specific to an FC-4. The REC (Read Exchange Concise) Extended Link Service requests an Nx_Port to return Exchange information for the RX_ID and OX_ID originated by the S_ID specified in the Payload of the request Sequence. The S_ID specified in the Payload of the request Sequence may differ from address identifiers of both the source and destination of the REC request itself."

This (third party) capability is problematic for FC-IFR implementations, since the information needed to perform address translation may not be known.

Does anyone have an inplementation where the REC payload Exchange originating S_ID field does not match the S_ID in the FC Header?

Thanks...Dave

(no disclaimer)