Subject: RE: [T11.3] FC-LS/FCP-4: Proposed REC behavior Date: Thu, 31 Aug 2006 10:20:45 -0500 From: "David Peterson" <David.Peterson@mcdata.com> To: <t10@t10.org>, <t11_3@mail.t11.org> X-Message-Number: 7203 Formatted message: HTML-formatted message Attachment #1: graycol.gif Attachment #2: ecblank.gif Howdy Roger, Don't see how your proposed change allows existing implementations to remain compliant either. Per your proposed change, it still implies the recipient FCP_Port needs to verify that the FC header S_ID field value is a valid address identifier for the target Exchange. In other words, without checking FC header S_ID field value, how can the recipient FCP_Port verify that the REC was issued by the Originator Nx_Port or Responder Nx_Port of the target Exchange? Not quite enough teeth for me. I'm looking to enforce that REC is not processed via a 3rd party request. Also note that FCP-4 already contains changes to PRLI (i.e., the REC_SUPPORTED bit). Thanks...Dave (no disclaimer) ________________________________ From: Roger Hathorn [mailto:rhathorn@us.ibm.com] Sent: Wednesday, August 30, 2006 3:53 PM To: David Peterson Cc: t10@t10.org; t11_3@mail.t11.org Subject: Re: [T11.3] FC-LS/FCP-4: Proposed REC behavior I suggest that the proposed text: A Read Exchange Consise Request shall only be accepted if the Originator Nx_Port or the Responder Nx_Port of the target Exchange makes the request be changed to: "A Read Exchange Consise Request shall only be issued by the Originator Nx_Port or the Responder Nx_Port of the target Exchange." to allow existing implementations to remain compliant. The text, as proposed, indicated that the recipient has to somehow check this. Roger G. Hathorn Senior Engineer, Storage Systems Development IBM Systems and Technology Group Tel: 520-799-5950 (T/L: 321-5950) Pager: 520-446-2741 or http://www.arch.com/cgi-bin/wwwpreproc.exe?PIN=5204462741 "David Peterson" <David.Peterson@mcdata.com> "David Peterson" <David.Peterson@mcdata.com> Sent by: t11_3-bounces@listserve.com 08/30/2006 10:29 AM To <t10@t10.org>, <t11_3@mail.t11.org> cc Subject [T11.3] FC-LS/FCP-4: Proposed REC behavior Howdy, To remove the ability for a third party to issue an REC, here is the proposed text for FC-LS: 4.2.42.1 Description 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. A Read Exchange Consise Request shall only be accepted if the Originator Nx_Port or the Responder Nx_Port of the target Exchange makes the request. The specification of OX_ID and RX_ID shall be provided for the destination Nx_Port to locate the status information requested. A Responder destination Nx_Port shall use the RX_ID and verify that the OX_ID is consistent, unless the RX_ID is unassigned (i.e., RX_ID = FFFFh). If the RX_ID is unassigned in the request, the Responder shall identify the Exchange by means of the S_ID specified in the Payload of the request Sequence and OX_ID. An Originator Nx_Port shall use the OX_ID and verify that the RX_ID is consistent. Please review the proposed text and be ready for a vote at the October T11 FC-LS working group meeting. Thanks...Dave (no disclaimer) _______________________________________________ T11_3 mailing list http://mailman.listserve.com/listmanager/listinfo/t11_3