X3T10/95-204R1 == Proposed responses to FCP Public Review Comments.

Charles Monia monia at am.shrmsg.shr.MTS.dec.com
Fri Apr 28 13:14:46 PDT 1995


Hi Bob:

The following are areas where I disagree with the proposed resolution of
comments made by Digital Equipment Corporation. My principal disagreements are
with the proposed responses to DEC comments 15 and 16. Regrettably, unless
these issues are addressed, I cannot vote to approve the referenced proposal.

Comments: DEC 5, DEC 6, DEC 8, DEC 11, DEC 12

Each of these comments refers to a glossary entry, which, in my opinion,
contains explanatory material which is inappropriate for inclusion in a
glossary.

In a typical response you state:

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

The only legitimate function of a glossary is to define terms having other than
the normal English meaning. Using a glossary to clarify concepts is
inappropriate. Such clarification, although useful, belongs in the body of the
standard, not in the glossary.


Comment:  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.


The above responses, while informative, are unacceptable. These standards must
be interpreted and implemented by human beings. In that regard, errors caused
by lack of clarity are as significant as errors due to faulty technical
content. For that reason, the assertion that these are editorial issues is
unpersuasive. The SAM LLP procedural interfaces, for instance,  were defined so
that a reader could trace an architectural requirement to it's implementation
using a given a protocol. The definition of protocol-specific responses serves
a similar purpose. Without such explicit traceability to serve as a guide, the
interpretation of architectural requirements is left to the implementor. I
believe there's a strong likelihood, in this case, that such requirements will
be misconstrued and that incorrect implementations will result.

In my opinion, the need for a manner of presentation which ties the
architectural and protocol specifications together closely is central to the
goal of creating a consistent and coherent family of standards.





More information about the T10 mailing list