Updated Responses to Comments about FCP, X3T10-204, Revision 1

Bob Snively Bob.Snively at Eng.Sun.COM
Thu Apr 27 02:22:01 PDT 1995


				Document X3T10/95-204, Revision 1



To:	John Lohmeyer
	Chairperson, X3T10
	Symbios Logic Inc.
	1635 Aeroplaza Drive
	Colorado Springs, Colorado 80916



Subject:	Proposed response to public review comments on FCP



The accompanying pages document the proposed response to those public 
review comments received about the draft proposed American National Standard 
entitled Fibre Channel Protocol for SCSI, document X3T10/993D, Revision 10, 
dated November 28, 1994.



The comments are identified by letters indicating the reviewer and by numbers 
identifying the comments from each reviewer. The first section is a table 
summarizing the comments and the response to each comment. The second 
section is the text of the original comment and a formal response to the 
comment, with accompanying explanations and justifications.



Sincerely,





Robert N. Snively, technical editor 

Sun Microsystems
Mail Stop MPK 12-204
2550 Garcia Ave.
Mountain View, CA 94043-1100

phone:	415-786-6694

e-mail:	bob.snively at sun.com

-----------------------------------------------------------------------------

Response to Public Review Comments


1)	Summary of responses:



The following table summarizes the public review comments received about the dpANS 
Fibre Channel Protocol for SCSI, document X3T10/993D, Revision 10, dated 
November 28, 1994.

 
Comment	T/E	Title of Comment			Sections	Proposed
							Changed		Resolution

HP 1	T	Provide Task Management Response	Many		Accept
HP 2	T	Target Reset effects PRLI				Withdrawn
HP 3	E	Clarify "Ambiguous Exchange"				Rejected

IBM 1	E	Section C.1, wording change		C.1		Accept
IBM 2	E	Section C.2, wording change		C.2		Accept
IBM 3	E	Section C.2, wording change		C.2		Accept
IBM 4	E	Section C, wording change		C		Accept
IBM 5	E	Section C.2, wording change		C.2		Accept
IBM 6	E	Section C.2, wording change		C.2		Accept
IBM 7	E	Section C.2, wording change		C.2		Accept
IBM 8	E	Annex C, wording change			C		Accept
IBM 9	E	Annex C, wording change			C		Accept
IBM 10	E	Section C.3, wording change		C.3		Accept
IBM 11	E	Section C.3.2, wording change		C.3.2		Accept
IBM 12	E	Section C.3.2, wording change		C.3.2		Accept
IBM 13	E	Section C.3.2, wording change		C.3.2		Accept

U 1	T	In Order Delivery			TBD		Accept

LLNL1	E	Comment on 2				2		Accepted
LLNL2	E	Comment on 3.1				2		Partial
LLNL3	E	Comment on 3.1.3 and 3.1.4		3.1.3/4		Accepted
LLNL4	E	Comment on 3.1.15			3.1.1.5		Accepted
LLNL5	E	Comment on 3.1.25			3.1.25		Accepted
LLNL6	T	Comment on 4.2				7.4.4,.5	Partial
LLNL7	E	Comment on 4.3				4.3		Accepted
LLNL8	E	Comment on 5.1				5.1		Accepted
LLNL9	E	Comment on 5.2, Table 6			5.2		Accepted
LLNL10	E	Comment on 5.5.6			5.5.6		Accepted
LLNL11	E	Comment on 5.5.11			5.5.11		Accepted
LLNL12	E	Comment on 6.1				6.1		Accepted
LLNL13	E	Comment on 6.2.2 - 6.2.4		6.2.2, .4	Accepted
LLNL14	E	Comment on 6.2.5			6.2.5		Accepted
LLNL15	T	Comment on 6.2.5			6.2.5		Accepted
LLNL16	E	Comment on 6.2.6.9 and 6.2.9.10		6.2.6.9		Accepted
LLNL17	E	Comment on 6.3				6.3		Accepted
LLNL18	T	Comment on 6.3				6.3		Accepted
LLNL19	E	Comment on 7.1.2.2			7.1.2.2		Accepted
LLNL20	E	Comment on 7.4						Rejected
LLNL21	E	Comment on C.2				C.2		Accepted

FSI 1	E	Add FQXID						Rejected
FSI 2	E	FQXID Definition					Rejected
FSI 3	E	Definition of Ports					Rejected
FSI 4	E	Unsolicited Command					Rejected
FSI 5	E	Starting Exchange					Rejected
FSI 6	E	Linking							Rejected
FSI 7	E	Task Management				TBD		Accepted
FSI 8	E	Task Management						Accepted

DEC 1	E	Section 3.1.5				3.1.5		Accepted
DEC 2	E	Section 3.1.7				3.1.7		Accepted
DEC 3	E	Section 3.1.9				3.1.9		Accepted
DEC 4	E	Section 3.1.10				3.1.10		Accepted
DEC 5	E	Section 3.1.12						Rejected
DEC 6	E	Section 3.1.13						Rejected
DEC 7	E	Section 3.1.15				3.1.15		Accepted
DEC 8	E	Section 3.1.18						Rejected
DEC 9	E	Section 3.1.20				3.1.20		Accepted
DEC 10	E	Section 3.1.25				3.1.25		Accepted
DEC 11	T	Definition of Tag			3.1.28		Partial
DEC 12	E	Section 3.1.33				3.1.33		Partial
DEC 13	E	Section 3.1.34				3.1.34		Accepted
DEC 14	T	Table 2					Table 2		Accepted
DEC 15	T	SAM Protocol Services					Rejected
DEC 16	T	SAM Protocol Specific Responses				Rejected
DEC 17	T	Asynchronous Event Reporting				Rejected

EMX 1	T	Annex A Extended Link Services				X3T11
EMX 2	E	Annex A Extended Link Services		A.2		Accepted
EMX 3	E	Annex A Extended Link Services		A.2		Accepted
EMX 4	E	Annex A Extended Link Services		A.3		Accepted
EMX 5	E	Section 6, PRLO/PRLI fields		6.2.6, .7	Accepted
EMX 6	I	Annex A Extended Link Services				Review

Text of public review comments and proposed response:



HP Section. Comments by Hewlett Packard, Kurt Chan



HP 1 	(Technical)		Provide Task Management Response

In the description of Task Management Functions on page 60 of the SCSI-3 Architecture 
Model (SAM), service responses are required which indicate the status of the function:

	- Function Complete
	-Function Rejected
	-Service Delivery or Target Failure

SAM requires that one of the above service responses be returned for every task management 
function. However, FCP provides no means of providing that response. There are valid reasons 
why such a response is needed for multi-initiator, class 3 environments in Fibre Channel 
(examples provided upon request). It is inappropriate to rely on link layer acknowledgments 
(on class 1 or class 2 ACKs) to provide this service.

Therefore we suggest the following changes be made to FCP to make it compliant with SAM, 
and to provide a reliable, class of service-independent FC-4:

Table 5, Page 10

- Change T1 to: Command Request and Task Management Function

- Delete or Reserve T5. If this change is unacceptable for backwards compatibility, add a PRLI 
login option which specifies whether T1 or T5 is used to perform task management (see next 
page).


Table 6, Page 11

- Change I4 to: Command or Task Management Function Response.


7.1.2.2, Page 25

Change the first sentence to: "A task management function shall not be requested in the same 
Exchange as a SCSI Command."


7.4.5, Page 33

Modify RSP_CODE = 00 and add codes 04 and 05 to table 20:

	RSP_CODE					Definition

	  00			No Failure or Task Management Function Complete
	  04			Task Management Function Not Supported
	  05			Task Management Function Failed

Insert the following text below table 20:

The task management function may or may not have been performed by the target if 
RSP_CODE is returned or if no FCP_RSP is returned before the Exchange is aborted. Values 
04 and 05 are not valid responses to SCSI commands.


B.1.9, page 53

Change the example to T1 instead of T5 and add the I4 response. Delete the last sentence of the 
first paragraph.

T1/I4 as a PRLI Option:

If a PRLI option is preferred for backward compatibility, add the following:

- Add note to table 5, page 10: "Using T1 to transfer Task Management functions is only 
allowable when enabled via PRLI."

- Add note to table 6, page 11: "Using I4 to transfer Task Management functions is only 
allowable when enabled via PRLI."

- Add as PRLI bit 7, word 3 to table 8, page 17: "Task Management Request Response sent as 
T1/I4." Add description of this PRLI option:

Setting this bit indicates a request for the SCSI Initiator to transmit Task Management 
Functions using T1, and for the SCSI Target to respond to Task Management Functions using 
I4.

The text then provides the behaviors selected if Word 3, Bit 7 is to be defined.



HP 1:		Response to comment HP 1.

The comment is accepted. The PRLI option is not selected, so all implementations are required 
to make use of the T1/I4 mechanism for transmitting Task Management Functions. No 
modification to the PRLI text is required.


HP 2	(Technical)		 Target Reset effect on login parameters

Login parameters should be in the set of objects within a Target which are restored to 
their default conditions upon receipt of Target Reset. 

After review, HP has withdrawn this comment.


HP 3	(Technical)		Clarify "Ambiguous Exchange"

The wording regarding "ambiguous exchanges" should be clarified by making error 
recovery within FCP profile-specific. Various profiles are explicit and complete in 
defining error recovery. The standard should only provide mechanisms by which the 
appropriate level of error recovery for the application can be assured. The following 
modifications should help clarify this.

Section 7.1.2.2

Attempts to define the term "ambiguous exchange" and the use of this concept to invoke 
error recovery is confusing and overly complex. Replace the last two paragraphs of 
TARGET RESET with:

The TARGET RESET is transmitted by the initiator (exchange originator) using a new 
exchange. Additional FC-PH recovery may be necessary following TARGET RESET.


Section 7.1.2.2

Attempts to define the term "ambiguous exchange" and the use of this concept to invoke 
error recovery is confusing and overly complex. Replace the last two paragraphs of 
CLEAR TASK SET with:

The CLEAR TASK SET is transmitted by the initiator (exchange   originator) using a new 
exchange. Additional FC-PH recovery may be   necessary following CLEAR TASK SET.


Section 7.1.2.2

Attempts to define the term "ambiguous exchange" and the use of this concept to invoke 
error recovery is confusing and overly complex. Replace the second and third 
paragraphs of ABORT TASK SET with:

The ABORT TASK SET is transmitted by the initiator (exchange   originator) using a new 
exchange. Additional FC-PH recovery may be   necessary following ABORT TASK SET.


HP 3:		Response to comment HP 3.

The comment is rejected. For the operation of these task management functions to be 
sufficiently standard to operate correctly, the two ends of the link must each reset any 
command which may be in an unknown (ambiguous) state. Alternatively, all 
outstanding commands must always be aborted by the initiator.




IBM Section. Comments by IBM, George Penokie

IBM 1 	(Editorial)		Section C.1, wording change

Page 58, Section C.1 - The statement "based on the SCSI committee's RAID addressing 
model" should read "based on the addressing model contained within the SCSI-3 
Controller Commands Standard (X3T10/1047D)".

IBM 1: Response to comment IBM 1.

Accepted.


IBM 2 	(Editorial)		Section C.2, wording change

Page 58, Section C.2 - The section name should be changed to "Definition of SCSI-3 
Controller Commands (SCC) addressing model".

IBM 2: Response to comment IBM 2.

Accepted.


IBM 3 	(Editorial)		Section C.2, wording change

Page 58, Section C.2 - In the first sentence the statement "RAID addressing model" 
should be "SCC addressing model" and the statement "SCSI disk array (SDA)" should 
be "SCSI-3 storage array". In the last sentence the statement "of an SDA logical unit, 
all physical SCSI logical units, and volume logical units." should be "of an SCSI-3 
storage array, all peripheral device logical unit numbers, and all volume set logical unit 
numbers."

IBM 3: Response to comment IBM 3.

Accepted.


IBM 4 	(Editorial)		Section C, wording change

Rest of Annex C - All "SDA" should be changed to "SCSI-3 storage array".

IBM 4: Response to comment IBM 4.

Accepted.


IBM 5 	(Editorial)		Section C.2, wording change

Page 58, Section C.2, equations at end of page - The following should be changed as 
indicated:

P = Peripheral device

V = Volume Set

B = SCSI bus within the SCSI-3 Storage Array

IBM 5: Response to comment IBM 5.

Accepted.


IBM 6 	(Editorial)		Section C.2, wording change

Page 58, Section C.2, last sentence on page - The statement "address of a Volume" 
should be "address of a volume set".

IBM 6: Response to comment IBM 6.

Accepted.


IBM 7 	(Editorial)		Section C.2, wording change

Page 59, Section C.2, Table 44 - "Physical logical unit/SDA" should be "Peripheral 
device logical unit/SCSI-3 storage array" and "Volume logical unit" should be "Volume 
set logical unit."

IBM 7: Response to comment IBM 7.

Accepted.


IBM 8 	(Editorial)		Annex C, wording change

Rest of Annex C - All "RAID" should be changed to "SCSI-3 storage array".

IBM 8: Response to comment IBM 8.

Accepted.


IBM 9 	(Editorial)		Annex C, wording change

Rest of Annex C - All "physical device" should be changed to "peripheral device".

IBM 9: Response to comment IBM 9.

Accepted.


IBM 10 	(Editorial)		Section C.3, wording change

Page 59, Section C.3, first sentence - The statement "logical volumes" should be 
"volume sets".

IBM 10: Response to comment IBM 10.

Accepted.


IBM 11 	(Editorial)		Section C.3.2, wording change

Page 60, Section C.3.2 - The title of this section should be "Addressing of volume set 
logical unit: example".

IBM 11: Response to comment IBM 11.

Accepted.


IBM 12 	(Editorial)		Section C.3.2, wording change

Page 60, Section C.3.2, first and second sentence - The statement "more disk drive 
Volumes. Volumes managed" should be "more volume sets. Volume sets managed".

IBM 12: Response to comment IBM 12.

Accepted.


IBM 13 	(Editorial)		Section C.3.2, wording change

Page 60 and 61, Section C.3.2 - The term "physical logical unit" should be "peripheral 
device logical unit" contained within the body of the standard. If it remains it may 
cause confusion.

IBM 13: Response to comment IBM 13.

Accepted.



Unisys Corporation Section, Comments by Jerry Witalka


U 1 	(Technical)		In Order Delivery

My current reading of the FCP specification requires all Initiators to support an 
FCP_XFER_RDY DATA_RO field that specifies out of order data delivery (SAM 
random buffer access). I believe this is an unacceptable burden for those Initiators that 
are required to support unlimited scatter/gather operations. Our host software is 
allowed to specify scatter gather boundaries of a single main storage word. 
Theoretically, we could be given a single 10000 byte disk read request that could be 
mapped to a 200 entry scatter/gather list specifying 200 different main storage buffer 
locations. If we had to support out of order data delivery, it could take an unacceptable 
amount of processing time to pore through the scatter/gather list and figure out where 
the starting storage address is for this Data IU as opposed to always processing the 
scatter/gather list sequentially.

Given this, I would like to request a change to FCP to allow an Initiator to require in 
order data delivery (SAM sequential buffer access) for all data transfers. SIP has 
effectively provided this functionality with the Enable Modify Data Pointer (EMDP) bit 
in the Disconnect/Reconnect mode page. The definition of this bit in the SCSI-3 
Primary Commands could be expanded to require the FCP_XFER_RDY DATA_RO 
field specify in order data delivery or a new bit could be added to the Process Login 
FCP Service parameter page to require in order data delivery.

U 1: Response to comment U 1.

The committee recommends that the use of the Enable Modify Data Pointer bit in the 
Disconnect/Reconnect mode page be defined for FCP. Implementation of this bit will 
not be made mandatory in FCP for the following reasons.

1)	The architecture described in this comment does not make maximum use of parallel 
access disk systems that may return data most efficiently out of order. As a result, the 
performance of systems that require that all delivery of data be in order may suffer. 

2)	Class 2 and Class 3 data may be delivered out of order by some fabrics. The fabric 
login process that requests in order delivery on a frame by frame basis is outside the definition 
of FCP, but might be required for systems like those described.



Lawrence Livermore National Laboratories Section, Comments by Lansing Sloan


LLNL 001 (Editorial) Comment on 2 

We believe FC-PH may be listed as a normative reference now (and deleted from clause 
8).

LLNL 001: Response to comment LLNL 001.

Accepted. (Verify with editors).


LLNL 002 (Editorial) Comment on 3.1

Many of the definitions include the text "[SAM]". Some have "[FC- PH]" or "[FC-
AL]". Such text seems helpful but should the meanings should be explained, or the text 
deleted. Many of the terms with "[SAM]" are also defined in SAM Revision 016, 
though not necessarily in SAM's "definitions" clause 4.1.

LLNL 002: Response to comment LLNL 002.


Partial. Section 2 explains how the references are generated and does 
not specify where in the referenced document the referenced information 
is found. The editor will use ANSI standard references. Brackets are 
acceptable to avoid the repetitive wording: "As specified by..." Section 3 
will get an additional indication that some of these are definitions from 
other documents collected here for the convenience of the reader.



LLNL 003 (Editorial) Comment on 3.1.3 and 3.1.4 

The terms "autosence buffer pointer" and "autosense returned flag" have "[SAM]" in 
their definitions in the FCP document but do not appear to be defined in SAM Revision 
016. (Both appear in SAM 012 clause 9.1 but not in SAM 016 clause 6.3.)

LLNL 003: Response to comment LLNL 003.

Since they are not used in the FC-4 document either, they should be deleted. Accepted.


LLNL 004 (Editorial) Comment on 3.1.15 

Since operation associators are 64 bits long, not 32, the FQXID with operation 
associators is a 176-bit concatenation, not 112.

LLNL 004: Response to comment LLNL 004.

Accepted.


LLNL 005 (Editorial) Comment on 3.1.25 

The terms "SCSI command service" has "[SAM]" in its definition in the FCP document 
but does not appear to be defined in SAM Revision 016. (It is in SAM 012 clause 9.1 
but not in SAM 016 clause 6.3, where it appears to have been replaced by "Execute 
Command" or "Send SCSI Command protocol service".)

LLNL 005: Response to comment LLNL 005.

The proper term is Execute Command. FCP will be changed accordingly. Accepted. The 
definition will have to be modified in a number of places in FCP.


LLNL 006 (Technical) Comment on 4.2, 4th paragraph, 2nd sentence 

This sentence states that if an unusual condition has been detected then SCSI 
REQUEST SENSE and FCP response information are returned. Is SCSI REQUEST 
SENSE supposed to be returned even if Auto-sense is not specified? (If the answer is 
yes, that should be made explicit in FCP, since it sort of contradicts SAM.)           
Similarly, if FCP response information is supposed to be returned regardless of auto-
sense, that should be stated. (SAM presumably does not cover this.) Clauses 7.4, 7.4.5, 
and/or 7.4.6 may be better places to clarify this.

LLNL 006: Response to comment LLNL 006.

Section 7.4.6 specifies that the proper FCP_SNS_INFO shall be presented when 
the SCSI status byte of CHECK CONDITION or COMMAND TERMINATED is presented as 
specified by SAM. It further indicates that FCP devices should always use autosense. 
Three additional issues have been identified while working with Mr. Sloane to 
resolve this problem.

1) There is no specification defining when FCP Response Information must be 
provided. Section 7.4.5 will be modified to indicate that FCP Response Information 
is provided when any of the RSP_CODE conditions are detected by the target.

2) There is a discrepancy in the definitions of the FCP_RSP_LEN field. 
Section 7.4.4 will be modified to indicate that FCP allows a length of zero, 
four, or eight when FCP Response Information is provided. Other lengths are 
reserved for future standardization.

3) The document is not perfectly clear about whether or not the FCP_RSP_LEN 
field is always provided, even if the FCP_RSP_LEN_VALID bit is set to zero. 
The text of section 7.4.4 will be clarified to indicate that both length fields 
are always present, whether or not they are valid.


LLNL 007 (Editorial) Comment on 4.3, 2nd paragraph, 2nd sentence 

The sentence says that task management functions... are always... the only IU in a new 
Exchange. According to 7.1.2.2, that's not true for "terminate task", which appears to 
be done only in existing Exchanges. Consider appending ", except for Terminate Task" 
to the end of the sentence.

LLNL 007: Response to comment LLNL 007.

Accepted.


LLNL 008 (Editorial) Comment on 5.1, 1st paragraph and Table 3 

Please state clearly in the paragraph what the FCP_Port address identifiers are. Please 
use words that clearly say "D_ID" and "S_ID" in table 3 are the identifiers. (The closest 
words found in a quick scan are in the definitions of "target identifier" and "initiator 
identifier".)

LLNL 008: Response to comment LLNL 008.

These abbreviations and definitions will be added to sections 3.1 and 3.2.


LLNL 009 (Editorial) Comment on 5.2, Table 6 

In the last line of the Note (and before the Key), delete the comma after "I2". Also 
delete "are usable to".

LLNL 009: Response to comment LLNL 009.

Accepted


LLNL 010 (Editorial) Comment on 5.5.6 

Delete the "is" that precedes "identifies".

LLNL 010: Response to comment LLNL 010.

Accepted.


LLNL 011 (Editorial) Comment on 5.5.11, 2nd sentence 

In "... Base Address is beginning address ...", insert "the" after "is".

LLNL 011: Response to comment LLNL 011.

Accepted.


LLNL 012 (Editorial) Comment on 6.1, second paragraph, second sentence 

Change "separated processes" to "separate processes" following the third instance of 
"logically".

LLNL 012: Response to comment LLNL 012.

Accepted.


LLNL 013 (Editorial) Comment on 6.2.2 through 6.2.4 

Each of these has words "for each FC-4" that I think are inappropriate in FCP. Clause 
6.2.4 has three instances of the phrase. The last paragraph before 6.1.1 certainly says 
the parameters for the other FC-4's are outside the scope of FCP (properly). Probably 
the five instances of "for each FC-4" should be replaced by "for FCP".

LLNL 013: Response to comment LLNL 013.

The intent was to indicate that a PRLI could be performed for more than one FC-4 at a 
time. The best way to do this would be to indicate in 6.2 at the end of the first paragraph 
that image pairs for more than one FC-4 can be included in each PRLI command. Then 
the term "for each FC-4" could be entirely removed.


LLNL 014 (Editorial) Comment on 6.2.5, first sentence 

Change "effects" to "affects."

LLNL 014: Response to comment LLNL 014.

Accepted.


LLNL 015 (Technical) Comment on 6.2.5, last paragraph, last sentence 

Should "default" precede "PRLI" in: "... PRLI shall be present at the completion of 
PLOGI"?

LLNL 015: Response to comment LLNL 015.

The intent of this phrase is to indicate that implicit PRLI, if implemented, is present at 
the completion of PLOGI. The sentence will be changed to read:

If default PRLI information is complete enough so that N_Port login (PLOGI) is sufficient to 
perform an implicit PRLI, then PLOGI shall establish the same reset state and Unit Attention 
condition that would normally be established by PRLI.


LLNL 016 (Editorial) Comment on 6.2.6.9 and 6.2.6.10 

In the first paragraph, fourth sentence, of each, a sentence starts with "If either the 
originator or the responder do not...". Change "do" to "does" in each clause.

LLNL 016: Response to comment LLNL 016.

Accepted.


LLNL 017 (Editorial) Comment on 6.3 

In the second and third paragraphs, change "No further communication under the 
affected FC-4..." to "No further FCP communication...".

LLNL 017: Response to comment LLNL 017.

Accepted.


LLNL 018 (Technical) Comment on 6.3, next to last paragraph 

The first sentence talks about "... the referenced process image...", and the other two 
sentences talk about a "PA". However, the content of this paragraph seems equally 
appropriate to communication between entities neither of which requires a PA. If so, the 
paragraph should be rewritten so that it does not seem to apply only when PAs are used. 
The best correction is unclear, but replacing "PA" with "image pair" may help.

LLNL 018: Response to comment LLNL 018.

The first case shall be changed to refer to "communication with an image that..."
The second case shall be changed to refer to "image.."
Accepted.


LLNL 019 (Editorial) Comment on 7.1.2.2, first paragraph 

Replace the first sentence with something like: "Except for TERMINATE TASK, a Task 
management function shall be transmitted by the initiator (Exchange Originator) using 
a new Exchange. There is no response from the target for a Task Management 
function."

LLNL 019: Response to comment LLNL 019.

Accepted.


LLNL 020 (Editorial) Comment on 7.4, first sentence 

Insert "payload" after "IU" or in place of "IU".

LLNL 020: Response to comment LLNL 020.

IU is the correct term. Rejected.


LLNL 021 (Editorial) Comment on C.2 

In the second line below Table 43, there should be one colon (not two) following 
"Generalized Address." 

LLNL 021: Response to comment LLNL 021.

Accepted.



FSI Consulting Services Section, Comments by Gary Stephens


FSI 1 (Editorial) Add FQXID

Page 2, 3.1.15 Add the term "(FQXID)" behind the term name to be consistent with 
other places where the abbreviation appears behind the term.

FSI 1: Response to comment FSI 1.

Already contained in section 3.2, Abbreviations. The convention is, except for the 
glossary and the abbreviations, that the abbreviation is enclosed in parentheses after the 
defining words the first time the abbreviation is used in the text. Change is not needed.


FSI 2 (Editorial) FQXID definition

Page 2, 2.1.15 In the process of a full Fibre Channel exchange, both the S_ID and D_ID 
fields may change. This optional function makes it difficult to specify a fixed name for 
the FQXID as specified in option b). Add some text to the standard to explain the 
migration of these values in a full Fibre Channel implementation. Such use is not 
prohibited by the standard and therefore must be described and mapped to FCP 
constructs.

FSI 2: Response to comment FSI 2.

The conventions relating the S_ID and D_ID to the originator's N_Port ID and the 
responder's N_Port ID as a function of initiative are well defined by the referenced 
documents. There are no other valid changes in S_ID/D_ID values within an FCP 
Exchange. This change is not required.


FSI 3 (Editorial) Definition of ports

Page 4, 4. 1, paragraph 4, line 2. The phrase "by a pair of N_Ports"' to "by a pair of 
FCP_Ports or a set of FCP_Ports using initial process associators". See comment 2.

General The term N_Port should be removed from the document except in the definition 
of FCP_Port. The term N_Port does not include the definition of an NL_Port for FC-
AL. The definition of FCP_Port should include the NL_Port for FC-AL.

FSI 3: Response to comment FSI 3.

After reviewing the text, the meaning described above appears to be included correctly. 
This change is not required.


FSI 4 (Editorial) Unsolicited Command

Page 5, Table 1. row 4 Remove the term Unsolicited in the FCP equivalent column. The 
command service request can be used for either an unsolicited command (i.e., the first 
one for a new task) and also for subsequent linked commands which are solicited by the 
previous FCP_RESPONSE IU.

FSI 4: Response to comment FSI 4.

The term is correct as defined in FC-PH. The same category is used for both the first 
command and subsequent linked commands. No change is required.


FSI 5 (Editorial) Starting Exchange

Page 5, 4.2, paragraph 2 line 1 Change "starts an exchange by sending" to "starts an 
exchange for the first request by sending".

FSI 5: Response to comment FSI 5.

The statement appears to be correct. X_ID reassignment, which might appear to be an 
exception, is actually included in this statement, since reassignment of the X_ID does 
not terminate an exchange, but extends it under a different name. Command linking, 
which might appear to be an exception, is actually not part of this statement, since this 
indicates how an exchange begins. No change is required.


FSI 6 (Editorial) Linking

Page 5, 4.2, paragraph 2, line 3. Change "The FCP_CMND" to "The first FCP_CMND". 
Each FCP_CMND does not start an exchange in the case of linking.

FSI 6: Response to comment FSI 6.

The reference is correct as stated. The FCP I/O Operation for linked commands starts 
with the first command in the link and continues with subsequent commands. No change 
is required.


FSI 7 (Editorial) Task Management

Page 7, Table 2 Must be updated to match SAM functions for task management along 
with corresponding text additions.

FSI 7: Response to comment FSI 7.

Accepted. The task management definitions in SAM will be reviewed and any new 
information or changes will be reflected if required in FCP.


FSI 8 (Editorial) Task Management

Page 10, 5.3, Table 5 Adjust the T1 IU to include confirmed task management.

FSI 8: Response to comment FSI 8.

Accepted, See HP 1



Digital Equipment Corporation Section, Comments by Charles Monia


DEC 1 (Editorial) Section 3.1.5

All text after the first sentence is explanatory material which

is outside the scope of the definition and should be deleted.

DEC 1: Response to comment DEC 1.

Accepted.


DEC 2(Editorial) Section 3.1.7

See comment 001.

DEC 2: Response to comment DEC 2.

Accepted.


DEC 3 (Editorial) Section 3.1.9

See comment 001

DEC 3: Response to comment DEC 3.

Accepted.


DEC 4 (Editorial) Section 3.1.10

See comment 001.

DEC 4: Response to comment DEC 4.

Accepted.


DEC 5 (Editorial) Section 3.1.12

See comment 001.

DEC 5: Response to comment DEC 5.

This section summarizes the definition of a very bulky section of FC-PH. This 
information is important to an understanding of the choices and definitions made in 
FCP, so I recommend that it remain unchanged.


DEC 6 (Editorial) Section 3.1.13

See comment 001.

DEC 6: Response to comment DEC 6.

This clarification is an appropriate part of the definition because it relates SCSI and 
FC-PH concepts, so I recommend it remain unchanged.


DEC 7 (Editorial) Section 3.1.15

See comment 001

DEC 7: Response to comment DEC 1.

Accepted.


DEC 8 (Editorial) Section 3.1.18

See comment 001.

DEC 8: Response to comment DEC 8.

This clarification is an appropriate part of the definition because it relates SCSI and 
FC-PH concepts, so I recommend it remain unchanged.


DEC 9 (Editorial) Section 3.1.20

See comment 001.

DEC 9: Response to comment DEC 9.

Accepted.


DEC 10 (Editorial) Section 3.1.25

See comment 001.

DEC 10: Response to comment DEC 10.

Accepted


DEC 11 (Technical) Definition of tag

Section 3.1.28

The definition for "tag" in the first sentence should be changed
to: "The initiator-specified component of the task identifier."

All text following the first sentence should be deleted.

DEC 11: Response to comment DEC 11.

The first sentence should be changed as requested to match up with SAM. The 
clarifying sentence beyond that is an appropriate part of the definition because it relates 
SCSI and FC-PH concepts, so I recommend it remain unchanged.


DEC 12 (Editorial) Section 3.1.33

See comment 001.

DEC 12: Response to comment DEC 12.

The second sentence only will be deleted. The third sentence is an appropriate part of 
the definition because it relates SCSI and FC-PH concepts, so I recommend it remain 
unchanged.


DEC 13 (Editorial) Section 3.1.34

See comment 001.

DEC 13: Response to comment DEC 13.

Accepted


DEC 14 (Technical) Table 2

The names in parentheses in column 1 appear to be the names of
SIP messages corresponding to the specified task management
functions. These names should be deleted.

DEC 14: Response to comment DEC 14.

Accepted.


DEC 15 (Technical) SAM Protocol Services 



In clauses 6.3 and 7.7 of SAM, protocol services to be provided
by an LLP are defined that support the command and task
management functions. The FCP protocol description should
reference the service and it's arguments by name. I would expect
to see a clause in FCP for each applicable SAM task management
or command protocol service. In addition to showing the service
interface and its parameters, the clause should map each SAM
parameter into its FCP-equivalent and describe corresponding FCP
behavior.

DEC 15: Response to comment DEC 15.

This is not really a technical comment, but an editorial. The functionality required by 
SAM is included in FCP, but is not organized to explicitly relate the required services to 
the FCP implementation of those services. In some cases using Class 3 services and 
certain profiles, the SAM service is provided through a "Negative Acknowledgment". 
In those cases the proper behaviors are assumed until a time-out or other error 
indication indicates that the behavior was not complete. The FCP should not be 
rewritten to match the SAM format until FCP-2 is published.


DEC 16 (Technical) SAM Protocol Specific Responses

As required by clauses 6 and 7 of SAM, FCP should identify the
protocol-specific responses corresponding to the following
service responses:

Task Complete, Linked Command Complete, Linked Command Complete
(with flag), Service Delivery or Target Failure, Function
Complete.

DEC 16: Response to comment DEC 16.

This is not really a technical comment, but an editorial. The functions required by SAM 
are described by FCP, but not organized to explicitly relate the SAM responses to the 
FCP implementation of those responses. In particular, the Task Complete information is 
provided by the FCP_RSP. Linked Command Complete is provided by the same 
FCP_RSP indication as task complete, but with different IUs. Linked Command 
Complete with Flag is distinguished from Linked Command Complete by state 
information retained by the host adapter. While these editorial changes would be nice, 
the FCP should not be rewritten to match the SAM format until FCP-2 is published.


DEC 17 (Technical) Asynchronous Event Reporting

The mechanism for Asynchronous Event Reporting is not defined as
required by clause 6.6.4.1 of SAM.

DEC 17: Response to comment DEC 17.

Asynchronous Event Reporting is defined as a SEND command from a device that 
normally acts as a target, but is temporarily acting as an initiator. This is explained at 
the end of section 4.2. No changes are required.


Emulex Section, Comments by Greg Scherer

EMX 1 (Technical) Annex A (normative) Extended link services

Background for the comment:

In Annex A of FCP an FC-4 login/logout service is defined in order to 
implement specific FCP functionality. This login/logout service is stated 
to be generic and therefore designed to support multiple FC-4's within it's framework.

The login service (PRLI) supports FC-4 TYPE and or Process Associators to be 
exchanged during login, in order to differentiate between separate FC-4 logins 
(e.g. FCP, IPI, etc.), or even separate FC-4 image pairs (FCP image pair 1, 
FCP image pair 2, etc.). This architecturally allows two N_PORT's with 
independent FC-4's to communicate using independent FC-4 login parameters.

My issue comes from the fact that the logout service (PRLO) does not support 
FC-4 TYPE specific logout. This means that if two N_PORT's choose not to use 
Process Associators, (that will ensure image pair uniqueness), any PRLO (logout) 
|from a single FC-4 will affect all others. Although today there may not be many 
coexisting FC-4's that use PRLI/PRLO, I believe the intent in Annex A was to 
document an enabling service that could be used in a much broader scope in the future.

Specific comment:

In Annex A the PRLO / ACC payloads define Parameter Page Word 0 Bit 31:16 as 
RESERVED.   This is the same field in the PRLI / ACC payload that is defined 
as the FC-4 TYPE and TYPE code expansion. Without the TYPE and TYPE code 
expansion area defined in the PRLO / ACC payload it is not possible (without 
using Process Associators) to logout one FC-4 on a given N_PORT without 
potentially affecting others.

Recommendation:

Add FC-4 TYPE and TYPE code expansion fields to the PRLO / ACC payloads, as 
per the definition and field position of TYPE and TYPE code expansion fields 
defined in the PRLI / ACC payloads.

In any case, tables 11 and 12 (PRLO / ACC payloads listed in section 6) must 
be made to match tables 29 and 31 (from Annex A) as they currently contradict 
each other regarding the definition of Parameter Page Word 0 Bit 31:16 (TYPE 
and TYPE code expansion fields).

EMX 1: Response to comment EMX 1.

Since the actual standardization of this function is being carried forward 
as an FC-PH-2 activity, this will ultimately be a comment against that document. 
The editor will review FC-PH-2 for conformity and make those corrections that 
are presently defined. This is a desirable characteristic which should be 
carried forward.
The contradiction will be resolved. This comment is accepted in principle, but 
requires supporting activities from another organization to be completed.


EMX 2 (Editorial) Annex A (normative) Extended link services

Page 39 first bullet:
 - Word 0, Bit 14 Establish Image Pair
Should be bit 13 (as listed in table 24).

EMX 2: Response to comment EMX 2.

Accepted.


EMX 3 (Editorial) Annex A (normative) Extended link services

Page 41 fourth bullet:
 - Word 0, Bit 14 Establish Image Pair
                  Image pair established only if bit 14.......
Should be bit 13 (as listed in table 26).

EMX 3: Response to comment EMX 3.

Accepted.


EMX 4 (Editorial) Annex A (normative) Extended link services

Table 31 entry 7 is 13-0 should be 7-0:

Item 					Word 		Bit
 ------------------------------------------------------------------
Logout parm response page 		0-3 		31- 0
   Reserved 				0 		31-16
   Originator PA Valid			0 		15
   Responder PA Valid			0 		14
   Reserved 				0 		13-12
   Response code 			0 		11- 8
   Reserved 				0 		13- 0 <------

EMX 4: Response to comment EMX 4.

Accepted.


EMX 5 (Editorial) Section 6 PRLO / PRLI Field definitions

Tables 8 and 10 document Parameter Page payload Word 0 bit 13 as 
RESERVED. This same bit in tables 24 and 26 (of Annex A) is defined 
as "Establish Image Pair" an "Image Pair Established" respectively. 
The bit definitions in both sets of tables (8 / 24 and 10 / 26) and 
text should match.

EMX 5: Response to comment EMX 5.

Accepted. Section 6 will be updated.


EMX 6 (Improvement) Annex A (normative) Extended link services

I would like to see more detail in the general description for PRLI 
Parameter Page Word 0, bit 13 "Establish Image Pair". If this bit = 1 
(Establish Image Pair and exchange parameters), must bits 15-14 
(Process Associators) also be =1?   There is no indication in the 
text that they are tightly coupled, although I believe that they 
are. Relationships such as these should be clearly defined (even 
though potentially obvious).

EMX 6: Response to comment EMX 6.

This revision did not require Process Associators to establish an 
image pair. When the PA is invalid, then the image is of the whole 
node. This was kept vague so that either mechanism could be used. 
The editor will review the text with respect to the latest revision 
of FC-PH-2.




More information about the T10 mailing list