RESEND: Response to FCP Comments by Seagate, Please Review

Bob Snively Bob.Snively at eng.sun.com
Thu Jan 13 22:55:05 PST 1994


                     ADDITIONAL FCP REVIEW QUESTIONS	   

The following additional items were raised with respect to Revision 007 of
the FCP document.

The comments are addressed below.  The proposed resolution is provided with
each question.


Date: 30 Dec 93
Reviewer: Gene Milligan


001	E	Correct cover references

A minor nit, On the front page "individuals" and "Technical
Editors" should be made singular or the list of people made plural.
A convenient way to do this would be to move some of the people
|from page i to the front page. If noticed by X3, there could be
objection to the title FC Working Group Chair since the procedures
specifically prohibit the concept of any standing working groups.

Action:

The plural has been removed from the word editor.  The contact points are
redefined as:  "Information on the current status of this document may be
obtained from the points of contact on page i."

Dal Allan is re-labeled as:  Fibre Channel Coordinator

002	E	Improve purposes on cover

As an early implementor of the FCP I find the statement "Any
commercial or for-profit use is strictly prohibited." Please delete
it. We have aspirations of making a profit from FCP.

Action:

Wording is changed to:  "Any commercial or for-profit replication or republication of this
document is strictly prohibited."

003 E	Editorial fixes

In the Abstract change "proposal" to "standard". Capitalize
protocol in "Fibre Channel protocol" and consider deleting "requirements".

Action:

Accepted

004 E	Document status

I presume when forwarded the Document Status will be removed
|from the dpANS.

Action:

Accepted.

005 E	Numbering practice

Although X3T9.2 has adopted what I consider a bad practice
of not using document numbers on their drafts (pocket vetoes competitive
drafts and makes it difficult to distinguish between the project
description and the dpANS) X3 has not. The X3 number will be assigned
when FCP has been forwarded and accepted for processing by X3.
Consequently X3.993-199x is incorrect. For now use something like
X3.xxxx-199x.

Action:

The value specified is X3T9.2/993D.  This means that only X3T9.2 is taking
the responsibility for th enumbering.  If this is acceptable to the committee,
I will continue to use this method.

006 E	Forward

I think it is more than the FC protocols that are used and
suggest deleting "protocols" following "serial link".

Action:

The term "serial link protocols" is replaced with the word "services".

007	E	Scope

In the Scope I believe there are objects required by SAM that
are not actually passed through FCP. I suggest replacing "that
contain the objects required by" with "in accordance with".

Action:

Accepted.

008 E	Revision levels

SCSI-2 has two very pertinent revisions. 10h was the revision
the committee voted upon technically. The other is the latest
revision which is not 10k. All of the standards which have reached
X3 should have the X3T9 numbers replaced with the X3 numbers.
SCSI-2 is X3.131-1993 (check this with yourself - I think it was
blessed in 1993 and ink may have splattered upon paper in 1994).
FC-PH is X3.230-199x and is at lest revision 4.2.  FC-FG and FC-SB
are at least Revision 2.0. CAM is X3.232-199x. I assume FC-SB
is a competitor to SCSI and consequently a competitor to FCP.
Why is it listed? Why is FC-AL not listed as it should be? What
is the position relative to CAM-2?

Action:

FC-AL is now in FCP Rev 007a.  FC-SB is the IBM OEM channel document and is the
only place where PRLI/PRLO are presently described completely.  CAM-2 is
not at present a part of SCSI or SCSI-3 and should be completely
compatible with the SAM. The remaining document levels will be verified.

009 E	Base Address

In 3.1.5 is the base address actually a byte address or is
it a word address?

Action:

The base address is architected as a byte address.  In fact, most
implementations will actually use it as a sector or page address and very
few will use other than a 4-byte boundary.  The definition is not changed.

010	E	Transfer Extent

In 3.1.7 "transfer extent" is not clear terminology. I have
deduced that (SAM) indicates the definition is repeated from SAM.
However this definition is not.

Action:

The text is paraphrased from SAM, Rev 12, page 75.  The text will be changed to
read:

command byte count: upper limit on the extent of the data to be transferred by
the SCSI command.  Since the offset and byte count specified for each data transfer
may overlap, the total number of bytes moved for a command is not a reliable
indicator of the extent of the data transferred.

011	E	Annex S

In 3.1.15 is FC-PH not a sufficient reference without citing
Annex S? (I don't have my FC-PH handy but I thought Annex S was
an informative Annex which makes it suspect as a reference.)

Action:

FC-PH does not have a clear delineation of the services in any part of the
document except Annex S.  For that reason, I have referenced it specifically.
If someone had to try to interpret the service structure without the guidance
of Annex S, it would be very difficult.  I would prefer to make no change 
with respect to this reference.

012	E	FC-PH levels

In 3.1.16 I question the usage of FC-2 here and in 4.1 since
I recall the Fibre Channel levels being poorly documented within
FC-PH. Has the ambiguity in the level content been rectified in
FC-PH?

Action:

The levels remain poorly defined in FC-PH.  In section 3.1.15 (rev 007a) I will
change the text to indicate FC-PH instead of FC-2.  In section 4.1, Paragraph 3,
the first sentence will be changed to:  An Upper Layer Protocol (ULP) uses the 
services provided by FC-PH to execute the steps required to perform the
functions defined by the ULP.  In section 4.1, paragraph 4, the use of the word
"FC-2" will be replaced with the word "service".

013	E	Logical Unit Identifier

3.1.25 would be clearer if "external" were deleted. This definition
is SAM compatible but is not actually from SAM.

Action:

Accepted.

014	E	Logical Unit Number

In 3.1.26 the definition is watered down from SAM. Citing
the equivalence to the Entity Address is not very helpful since
that definition of Entity Address is not included in 3.1.

Action:

The definition has been rewritten in 007a to be:  An encoded 64-bit identifer
for a logical unit.

Should the entity address by renamed as the logical unit number throughout the
document?

015	E	SCSI Command Service

In 3.1.28 Where is "Execute SCSI Command remote procedure call" defined?

Action:

The SAM document defined this value.  While I agree that it will probably be
changed in SAM, that is the present definition of the service.  The
sentence could probably be changed to read:  a peer-to-peer confirmed service
requested by the applicatin client to perform an SCSI command.

016	E	Target Identifier

In 3.1.31 target identifier is more intuitive for SCSI than
Exchange Originator. Shouldn't Exchange Originator be defined
in 3.1?

Action:

This text was designed to help those knowledgable about FC, who
should already know what an Exchange Originator is.  Should all those terms
also be included in the document?  Unless the committee feels it is
essential, I would prefer to include them by reference.

017	E	Referene to service interface

I would prefer to delete the balance of the first sentence
of the third paragraph of 4.1 following the comma. This would
eliminate the troublesome FC-2 and Annex S, I think, without losing
any specificity or clarity.

Action:

See 012.  While not necessary to implementation, I believe this is an
important piece of guidance.

018	E	UI vs IU

In the third paragraph of 4.2 I presume "UI" should be "IU".

Action:

Corrected in 007a.

019	T	Class 3

I am aware of customers wanting Class 3 service with FCP.
I presume they have or will submit comments proposing changes
to FCP to accommodate Class 3 service. The customer is always
right but I don't yet know why they are right in this instance.

Action:

Revision 007a conditionally allows class 3 on page 7, section 4.2.
There are two reasons why class 3 service may be desirable.  

a)	FC-AL cost performance could be improved by not having any requirement
	for acknowledgments.
	
b)	Some class 2 systems may have to operate with incomplete Acknowledgment
	information anyway, meaning that the tools for operation without ACK
	must probably be available anyway.	

020	E	Define FC-4

In 4.3 FC-4 needs a definition or some other term should be
used.

Action:

The text will be modified to read:  FC-PH allows management protocols above the
FC-PH service interface to perform link data functions.

021	E	FC-3

In 5 FC-3 needs a definition or another term. The last I knew
FC-3 was a wish list. Perhaps it has taken shape by now.

Action:

This text has been deleted in revision 007a.  The text will be searched to
replace "FC-3" with appropriate descriptive text.  In section 4.1 of 007a,
the words "and FC-3" are deleted.

022	E	Editorial

I suggest replacing "explained" with "shown" in the sentence
just prior to Table 1.

Action:

Accepted.

023	E	Open exchanges

Is there not something more specific than "characteristics"
that defines how many Exchanges can be open?

Action:

The text will be changed to:  "The number of Exchanges that may
simultaneously be open is defined by the FC-PH implementation."

024	E	Tables
Several of the Tables (e.g. Table 2 "d" on separate line from
"Require") need to have the size or font adjusted to eliminate
the awkward word wrap.

Action:

Tables have been corrected in revision 007a.

025	E	Capitalization

Although I have never been comfortable with the SCSI conventions,
I think to be congruent with SAM and the other SCSI documents
Table 2 should replace Terminate Task and Clear ACA with "TERMINATE
TASK and CLEAR ACA".

Action:

The SAM conventions will be used.

026	E 	Article

No document is immune to my opinions on "an" and "a". The
next to last paragraph of 5 should be "identify a FCP I/O" rather
than "identify an FCP I/O". However this is not unpleasant like
"an SCSI".

Action:

The sentence has been removed in revision 007a.  A search will be made
for other cases.  Note that "an FCP_CMND IU" will be used, since the
word is read by its letter values.  The only foolproof method for 
resolving this in a way that will satisfy all parties is to avoid the
indefinite article for such cases.

027	E	IUs

In the first note after Table 3 I think it should be "IUs"
rather than "IUS".

Action:

Accepted.

028	E	Clarify terms

In 5.3.1 it is not clear how Device_Data Information Categories
tie into R_CNTL nor how they are defined in Table 3 and 4 since
the nomenclature changes. Why is there no "_" between Data and
Information and Categories?

Action:

The proper term for the type of frame that carries Information Category
identifiers and ULP information is a Device_Data frame.  These are
formal FC-PH terms and will be used consistently throughout the document.

029	E	Future Extensions

In 5.3.2 and 5.3.3 the "If future extensions of the Fibre
Channel" statement should either be deleted or moved to a note
of the form "X3T10 and X3T11 intend to develop a future extension
... For further information on the progress of these future extensions
contact some poor soul."

Action:

The following note will replace the offending sentence:

Note:  X3T11 intends to develop future extensions of the Fibre Channel that
may allow treatment of the D_ID as an alias for multi-N_Port hunt groups, dynamic
path reconnection groups, and data striping groups.

030	E	Saturday

In 5.3.9 what is a "SAM tag"? Is it Saturday?

Action:

The offending phrase will be replaced with:  "The value of the OX_ID 
is the tag defined by SAM."

031	E	Private Saturday

And in 5.3.10 what is a private version of the SAM tag?

Action:

The offending phrase will be replaced with:  "The RX_ID allows the Exchange
Responder to optionally create its own value for the tag defined by SAM."

032	E	Process Login

In section 6 why is the Process Login included in such an
esoteric standard as FC-SB?

Action:

The FC-SB defines the Process Login because it was the first FC document
that realized the desirability of a Process Login.

033	E	Other PRLI parameters

Note FC-4 issue in 6.1. Does the paragraph they are in imply
that FCP requires items in FC-SB and other unamed FC documents
besides PRLI or is it a throw away paragraph other than the portion
that is redundant to the second sentence of 6?

Action:

The offending sentence will be changed to:

"The PRLI common service parameters are defined in the FC-SB document.
They are included here for reference, but are not required by the FCP ULP."

Incidentally, the parameters will be examined to be sure that they are
not factors in the ULP.

034	E	Unit Attention

Is the PRLI unit attention condition actually for all tragets
or is it for all initiators?

Action:

The PRLI unit attention is created by all the targets involved and transmitted to 
all initiators effected by changes in those  targets.  The text will be modified
to indicate that.

035	E	PRLI IU?

Is a PRLI contained within an IU and therefore should it be
immune from the requirement to discard IUs prior to the performance
of t he PRLI?

Action:

The PRLI is not contained within an FCP IU.  The payload is within an
Extended Link Service frame and its IUs are defined by SB.  Only
FCP IUs are discarded.

036	E	PRLI state

In the last paragraph of 6.1 is "initiator capability" correct
or is it "initiator defined capability"? In other words is the
act of dumping reservations due to a change in the initiator or
in the target? Does the PRLI provide a backdoor way to circumvent
reservations?

Action:

The phrase "initiator capability" will be modified to say:  "If the action
removed the capability of acting as an initiator from an image in the image
pair, all tasks, reservations, Mode Select parameters, 
and status for the initiator are removed from
the target involved in the login operation."

The PRLI does indeed end reservations for an initiator, but it is an
action performed by the port having the initiator capability, so it is
not really a backdoor mechanism.

037	E	Invalid

In 6.1.1 I think "assumed to be invalid" should be replaced
with "invalid" in two places (end of Word 1, Bits 3 and 2).

Action:

Accepted.

038	E	One

In Bit 3 change "shall be set 1" to "shall be set to one"
and "will be rejected" to "shall be rejected".

Action:

Accepted.

038	E	Shall

In Bit 1 replace "will not be used" with "shall not be used"; 
"will be used" with "shall be used" and "will operate" with
"shall operate".

Action:

Accepted.

039	E	Awkward construction

The requirement "both N_Ports shall always expect the Exchange
Responder to transmit an FCP_XFER_RDY" is a problimatic way to
state the requirement. Why not reconstruct it to "the Exchange
Responder shall transmit an FCP_XFER_RDY"? (Also I presume it
should be expanded to loop ports.)

Action:

Accepted.  Loop ports already define the Exchange Originator and
Exchange Responder such that the text applies to loops without
any change.

040	E	Everywhere

Comments 38 and 39 apply to both Read and Write.

Action:

Accepted.

041	E	Reset and PRLO

In 6.2 what is the impact of a PRLO upon Mode Pages? How broadly
should "reset" be interpreted?

Action:

The intent is that a PRLO changes the image pair from a functioning FCP
pair of devices to a pair of N_Ports that cannot perform any SCSI functions,
unless there is also an implicit log-in state implemented for the image pair.
The word reset means that a subsequent PRLI will bring the image pair up
in the same state that a SCSI hard reset (or power-on) would establish for 
them.  To make this clearer, the following changes will be made in 6.2.

"All tasks, reservations, status, and Mode Page parameters are set to the
state they would have after a SCSI hard reset or power on reset was performed.
Open ... by an ABTX.  Unless implicit login parameters exist that allow
FCP functions and establish default parameters, the PRLO shall set the 
referenced process image into a state that
does not allow any FCP initiator or target functions to be initiated or performed."

042	E	Shall

Change "can intitiate" to "shall initiate".

Action:

Corrected by above rewrite.

043	E	Delete redundancy

Delete the last pragraph of 6.2 which is redundant not to
mention problimatic.

Action:

Accepted.

044	E	Wrong table

In 6.2.1 change Table 5 to Table 6.

Action:

Accepted.

045	E	An

In the paragraph after Table 7 delete "an".

Action:

Revision 007a rewrite corrected this.

046	E	Clarification

Would it be clearer to indicate that the FCP_DATA IU immediatley
follows the FCP_DL rather than FCP_CMND so that no one puts it
after the FCP_CDB?

Action:

Revision 007a rewrite clarified this.

047	E	Name a new port

I assume that in 7.1.1 the FCP_ENT_ADDR can also be used with
loop ports not just the N_Port and the definition should be expanded.

Action:

In section 4.1, the following explanatory sentence will be added to paragraph 3.

"In the FCP document, N_Ports and L_Ports capable of supporting
the FCP ULP will be collectively referred to as FCP_Ports."

All relevant N_Port references will be changed to be FCP_Port references.

048	E	Address structure

I presume the address structure is not vendor unique although
the address generation may be vendor unique.

Action:

The address generation is vendor unique.  The structure of the Entity Address,
if it has a structure, is also vendor unique.  The offending sentence will be
modified to indicate:

"The structure of the FCP_ENT_ADDR field is not specified by the FCP.  The
structure is specified by the SCSI device model and may be vendor unique for
devices that do not have a defined address structure."

049	E	Terminate I/O

I have checked and have not found anyone who has implented
the Terminate I/O of SCSI-2. Is it necessary to include it in
FCP 7.1.2?

Action:

The convention followed with respect to SAM functions is that physical
layers are required to have a mechanism for performing any SAM function,
but the physical layers are not required to make the function mandatory.
The FCP revision 007a specifies that Terminate I/O is optional.  I sincerely
hope no one implements it, and I would be willing to carry a motion to
make it prohibited for all physical layers.

050	E	CDB Pad

For CDBs shorter than 16 bytes, where is the definition of
what pads out the FCP_CDB?

Action:

Section 7.1.3 will have the following information added to it.

"The command byte of the CDB shall be located at the first byte transmitted of the
FCP_CDB field.  The CDB's first byte defines the length and basic format 
of the remainder of the CDB as described in SAM.  Bytes beyond the last byte of
the CDB are not defined by FCP, not examined by the Target, and may have any
value."

051	E	Invalidity precedence

Should there be a tie between the last sentence of 7.1.4 and
the last sentence of 7.1.2? That is to say does "bits shall be
ignored" take precedence over "is invalid"?

Action:

The document will be checked for comparable reflexive invalidity.

The offending sentence in section 7.1.2 will be modified to read:

"If both Read Data and Write Data are set to zero, there shall be no
FCP_DATA IUs and the FCP_DL shall be zero."  This indicates that
knowledge of the fact that there will be no data transfer should
be reflected at all relevant parts.

Section 7.1.2 will be modified by changing the last sentence referring to
both bits as one to:

"The initiator shall not set both the Read Data and the Write data bits to one."

Section 7.1.4, last sentence, will be deleted to indicate that it does not
really matter whether a read or a write are expected if the transfer length is
zero.  Note that an FCP_DL of zero when a read or write operation with
non-zero transfer occurs will result in a residual value being noted in the
FCP_RSP.  This should be obvious from the text.

052	E	SCSI or SCSI-2.

In 7.4.3 I think SCSI-2 should be replaced with SCSI.

Action:

Revision 007a deleted the offending sentence.

053	E	Maximum Length

In 7.4.4 how was 252 bytes selected as the maximum response
length?

Action:

The value 252 is the maximum value expressable with one byte that is an
integral multiple of 4.

054	E	Blanks

Why are there four blank rows in Table 14?

Action:

No reason.  They will be deleted.

055	E	SCSI or SCSI-2

In 7.4.6 I think SCSI-2 should be replaced with SCSI.

Action:

SCSI-2 is the document referenced (as specified in section 2) to define the
format of the FCP_SNS_INFO.  No change will be made.
056) Although the RAID Advisory Board can render a definitive ruling,
I believe those with the good of mankind in mind have decided
that the explosion of the RAID acronym should be "Redundant Array
of Independent Disks" in B.1.

057	E	Address Model

It is not clear to me what the essential point is with "different"
in the paragraph following Figure 8.

Action:

Revision 007a completely rewrites this section.








More information about the T10 mailing list