David,

I did not mean to imply that the recipient shall verify the rule. The words say that the sender shall follow the rule.
Existing implementations do not enforce any rules about the S_ID in the REC payload. I don't think you can expect enforcement by the recipient, because that would then make existing implementations non-compliant. If the originator breaks the rules, unexpected results can be expected. If you expect the recipient to enforce the rule, then you need to say what happens when the rule is broken. Since this would require changes in existing implementations, I don't think we can say anything about enforcement.

Bob, I am fine with your words too. I think they mean the same thing.


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
Inactive hide details for Bob.Nixon@Emulex.ComBob.Nixon@Emulex.Com


          Bob.Nixon@Emulex.Com
          Sent by: t11_3-bounces@listserve.com

          08/31/2006 09:00 AM

To

<David.Peterson@mcdata.com>, <t10@t10.org>, <t11_3@mail.t11.org>

cc


Subject

RE: [T11.3] FC-LS/FCP-4: Proposed REC behavior

Rather than say who shall do it, we should simply say what it shall be. Unless we excuse either side explicitly (which we should not do) then the sender is required to get it right, and the receiver is required to protect itself. In the first paragraph of the description, change

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

to

The S_ID specified in the Exchange originator S_ID field of the Payload of the request Sequence shall be the same as either the S_ID or the D_ID in the Frame Header of the request Sequence.

- bob

-----Original Message-----
From: owner-t10@t10.org [mailto:owner-t10@t10.org]On Behalf Of David Peterson
Sent: Thursday, August 31, 2006 8:21 AM
To: t10@t10.org; t11_3@mail.t11.org
Subject: RE: [T11.3] FC-LS/FCP-4: Proposed REC behavior

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)