Some comments on FC-TAPE v 1.06b

Bob Snively Bob.Snively at Ebay.Sun.COM
Thu Jul 9 11:28:51 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Bob Snively <Bob.Snively at Ebay.Sun.COM>
*

I have not completed my reading of the error recovery and
proposed FCP changes yet, but to date I have the following comments on
FC-TAPE v 1.06b.

My goal is create a profile with little space for options or ambiguities,
so my most frequent comment is to remove "allowable" functions to the
"prohibited" category, and more rarely to the "required" category.

Unfortunately, I also want the devices to be tolerant of present
FCP SCSI Class-3 loop environments, so I am hoping that some functions
will be treated as invocable, but only invoked by those initiators
with the special capabilities necessary to exploit them.  Much of that
is still in the part I have not completed reviewing.

Hope this is some help.

Bob

To:		

From:		Bob Snively

Date:		May 28, 1998

Subject:	Comments on FC-TAPE document Rev 1.06b

#1

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: Table of contents
PDFPage: 
DocPage:  ix
Line: all
CommentType: E

Comment:

Annex titles should be included in the TOC.

CommentEnd:

SuggestedRemedy:

Include annex titles in the TOC.  This may require modification of
the templates for the Annex title paragraph and the TOC.

RemedyEnd:

#2

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 1.0
PDFPage: 
DocPage:  1
Line: 3
CommentType: T

Comment:

The scope includes "... options required for operation of streaming
devices and medium changers in a public and private arbitrated loop
environment."

There appeared to be agreement that all these devices would be 
public loop devices.  Using the FLA profile, definitions in 3.1.25,
a public NL_Port can observe the rules of either a public NL_Port or
a private NL_Port. 

CommentEnd:

SuggestedRemedy:

I propose that the offending text referenced above be changed to read:

"... options required for operation of streaming devices and medium
changers in a public arbitrtated loop environment.  Devices that
operate in a public arbitrated loop environment are by definition
capable of operating in a private loop environment."

RemedyEnd:

#4

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 3.2
PDFPage: 
DocPage:  5
Line: 
CommentType: E

Comment:

The editorial conventions specify a set of conventions and indicate
that those not meeting those conventions have the normal English
meaning.  However, nowhere is it specified what the meaning is of
those special conventions.

CommentEnd:

SuggestedRemedy:

Change the first paragraph to read:

"A number of conditions, mechanisms, sequences, parameters, events,
states, or similar terms are printed with the following conventions.
Each of these terms is explicitly defined in the glossary, in the
appropriate text, or in the indicated reference and has a special
meaning within this document.

RemedyEnd:

#5

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 3.4
PDFPage: 
DocPage:  7
Line: 
CommentType: E

Comment:

The second paragraph on page 7 contains a statement that
prohibited features may be required for compliance with the
relevant standards.  This statement somewhat overstates the
actual requirement.

CommentEnd:

SuggestedRemedy:

I suggest that the following paraphrase of the FCSI profile
introductory text be used instead, since it more precisely provides
a guideline to the relationship between mandatory features and
their place in the profile.

This profile is a proper subset of the various relevant standards. 
It prohibits use of many features and options in these standards; 
and interoperability is not guaranteed if these features are used. 
This profile does not prohibit implementation of features, only 
their use. Implementations may support features whose
use is prohibited, such prohibited features may be required 
by other Profiles or in applications not covered by a Profile. 
Such implementations are non-compliant with this profile 
if inclusion of prohibited features makes them not operate with 
other systems using exactly that Profile.

RemedyEnd:

#6

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 3.5
PDFPage: 
DocPage:  7
Line: 
CommentType: E

Comment:

Throughout this section, the words "FC-TAPE compliant 
implementation" is used in a rather odd way.  The point is that
"implementations" do not communicate with each other.  As an
example, an FC-TAPE tape device cannot communicate with another
FC-TAPE tape device.

CommentEnd:

SuggestedRemedy:

I would propose that the many relevant places be modified to
speak of "initiators" communicating with "targets", or alternatively,
speak of "nodes" communicating with "complementary nodes".  As one example,
in the second paragraph, the text "An implementation may use the 
feature to communicate with non-compliant implementations." be 
modified to read:  "An initiator may use the feature to communicate
with non-compliant targets."  

RemedyEnd:

#7

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project nnnnDT, FC-TAPE, T11/98-124v7
ClauseSubclause: 3.5
PDFPage: 
DocPage:  7
Line: 
CommentType: T

Comment:

The first paragraph under the subheading "Invokable" says that;
"The recipient shall support invokable features or provide a 
response that it is not implemented as defined by the appropriate
standard."  This is not correct.  If the originator is allowed to
invoke a feature, the recipient's only correct response is to
perform the requested function, not refuse the requested function.

CommentEnd:

SuggestedRemedy:

I propose that the definition of "Invokable" be replaced with
the following definition from the FC-FLA document:

If a feature or parameter value is Invocable, it means that it 
may be used between compliant implementations. Compliant 
implementations are required to implement the feature, and make
available the use of the feature. Invocable is different than 
Allowable or Required in that an originator may invoke the feature 
if needed, but the originator is not required to invoke it, and may 
never need to. Typically, an Invocable feature is Required for 
implementation by the recipient of the feature.

RemedyEnd:

#8

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 4.1
PDFPage: 
DocPage:  9
Line: 
CommentType: T

Comment:

The first paragraph describes the behavior of both public and
private ports.  The profile compliant device is a public device
that will attempt to login to address 0 with FLOGI.  If it fails,
it will continue on as a private NL_Port.  The paragraph 
considers incorrectly that a compliant FC-TAPE port may be
private.

CommentEnd:

SuggestedRemedy:

Delete the second sentence of the paragraph, "An NL_Port...
is called a Private NL_Port."

RemedyEnd:

#9

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 4.1
PDFPage: 
DocPage:  9
Line: 
CommentType: T

Comment:

Tables 1 and 2, Need to simplify public/private behavior.

Table 1:
6th row:  Allowing a Public NL_Port to open any
local NL_Port is an additional unnecessary complexity.
7th row:  Private NL_Port may Open any Local NL_Port is an
unnecessary complexity.
new 8th row:  A public port should revert to private behavior
if the Fabric Login fails.

Table 2:
5th and 6th row:
A port forced into private operation by lack of a fabric
should only be allowed to operate with private ports.

CommentEnd:

SuggestedRemedy:

Table 1:
Mark the "Public NL_Port may open any Local NL_Port" as prohibited.
Change the "Private NL_Port may Open any Local NL_Port" to a new
feature entitled "Private NL_Port may open any private local NL_Port"
and mark it required.
Create a new feature entitled "Public NL_Port will behave as private
NL_Port if FLOGIN fails" and mark it as required.

Table 2:
Remove the "Public NL_Port may open NL_Port" feature.
Change the "Private NL_Port may open Private or Public NL_Port" to
a new feature entitled "Private NL_Port may open private NL_Port" and
mark it required.

RemedyEnd:

#10

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.1
PDFPage: 
DocPage:  11
Line: 
CommentType: E

Comment:

The first paragraph of 5.1 suggests using the IEEE or IEEE extended
formats.  SCSI devices should use the IEEE Registered values.

CommentEnd:

SuggestedRemedy:

Replace: "IEEE or IEEE extended formats defined by FC-PH." with
"IEEE Registered or IEEE Registered Extended formats defined by
FC-PH-3."

RemedyEnd:

#11

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.1
PDFPage: 
DocPage:  11
Line: 
CommentType: T

Comment:

The second paragraph of 5.1 indicates a Native Address Identifier
must be acquired before performing PLOGI.  The definition and
process for doing so is outlined in somewhat conflicting language
in FLA.  Words like "native address identifier" and "native
port identifier" appear to be used interchangeably in FLA.

CommentEnd:

SuggestedRemedy:

The portions of FLA and PLDA identifying this behavior should
be explicitly referenced.  It would be helpful to paraphrase them
in an informative annex if the references are complete.  I believe
they may not be, which would require additional text saying how
this is accomplished.  References include:

	FC-FLA 5.6

RemedyEnd:

#12

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.1
PDFPage: 
DocPage:  11
Line: 
CommentType: E

Comment:

typo

CommentEnd:

SuggestedRemedy:

Fifth paragraph,  "two examples os a DISC" should be "two examples of
a FDISC"

RemedyEnd:

#13

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.2
PDFPage: 
DocPage:  13
Line: 
CommentType: T

Comment:

In Table 4, features on line 2, 4, and 7 indicate that Class 3
behavior is optional.  Class 3 behavior should be mandatory.  If
all initiators and the target support Class 2, Class 2 behavior 
should be used.  

CommentEnd:

SuggestedRemedy:

In Table 4, change the features "Class 2" on lines 2, 4, and 7 to be
invokable by the NL_Port originator and required by the
NL_Port responder.  

Change Note 1 of Table 4 to read:

	Implementations conforming to this profile shall support
	Class 3.  If all initiators attached to a target support
	Class 2, the target may choose to operate with Class 2.

RemedyEnd:

#14

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.3
PDFPage: 
DocPage:  14
Line: 
CommentType: T

Comment:

I suggest a number of modifications to Table 5 intended to 
complete the profile and make the implementation both more
tolerant and more rigorous.

CommentEnd:

SuggestedRemedy:

In Table 5, make the following changes:

    feature 10, "Dynamic Half Duplex - DHD" should be 0, 0.

    feature 11, "SEQ_CNT" should be 1. 1.

RemedyEnd:

#15

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.4
PDFPage: 
DocPage:  15
Line: 
CommentType: T

Comment:

I suggest a number of modifications to Table 6 intended to
complete the profile and make the implementation both more tolerant
and more rigorous.

CommentEnd:

SuggestedRemedy:

In Table 6, make the following changes:

    feature 9, "E_D_TOV Resolution" should be 0
	
    feature 10, "Dynamic Half Duplex - DHD" should be 0.

    feature 11, "SEQ_CNT" should be 1.
    
    feature 14, "Total Concurrent Sequences (min)" should be 1 from PLDA
    
    feature 15, "Relative Offset..."  should be the same as PLOGI in Table 5.
    
RemedyEnd:

#16

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.5
PDFPage: 
DocPage:  16
Line: 
CommentType: T

Comment:

I suggest a number of modifications to Table 7 intended to
complete the profile and make the implementation both more tolerant
and more rigorous.

Note in particular that ACK generation assistance should be prohibited.

CommentEnd:

SuggestedRemedy:

In Table 7, make the following changes;

    Service Options:
    
    	features 1-6 should be 0,0.
    
    Initiator Control:
    
    	feature 1, "ACK_0 capable" should be 1,1.
    	    	
    	feature 3, "ACK generation assistance" should be P,P.
    	    	
    	feature 5, "data compressin history" should be 0,0.
    	    	
    	feature 7, "clock synch' capable" should be 0,0
    	
    Recipient Control:
    
    	feature 1, "ACK_0 capable" should be 1,1.
    	    	
    	feature 4, "Abort, discard multiple sequences"  should be P, P.
    	
    	features 10, 12, (see features 5, 7 above) should be P, P.
    
RemedyEnd:

#17

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.6
PDFPage: 
DocPage:  17
Line: 
CommentType: T

Comment:

Class 2 FLOGI parameters should be completed to make the document
less ambiguous and more rigorous.

CommentEnd:

SuggestedRemedy:

All the parameters in Table 8 that are not yet specified should be
specified as 0,0 or P,P, except the following:

	Initiator Control, ACK_0 capable should be 1,1.
	Recipient Control, ACK_0 capable should be 1,1.

RemedyEnd:

#18

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.7
PDFPage: 
DocPage:  18
Line: 
CommentType: T

Comment:

Class 3 PLOGI service parameters should be completed to make the document less
ambiguous and more rigorous.

CommentEnd:

SuggestedRemedy:

All the parameters in Table 9 that are not yet specified should be
specified as 0,0, or P,P, except the following:

	Service Options, Sequential delivery should be 1,1.
	
	Clock synchronization capable should be 0, 0 in two places.

RemedyEnd:

#19

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.8
PDFPage: 
DocPage:  19
Line: 
CommentType: T

Comment:

Class 3 FLOGI Service Parameters should be completed to make the
document less ambiguous and more rigorous.

CommentEnd:

SuggestedRemedy:

All the parameters in Table 10 that are not yet specified should be
specified as 0,0 or P,P.

Clock Synchronization capable should be 0, 0 in two places.	

RemedyEnd:

#20

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.9
PDFPage: 
DocPage:  20
Line: 
CommentType: T

Comment:

The use of link control frames does not appear to be correctly
described by the note in table 11.

CommentEnd:

SuggestedRemedy:

I propose that the note describe those link control frames that may
be transmitted or received while operating with each class of service.

In particular, P_RJT, F_RJT, P_BSY, and F_BSY can be transmitted or
received in both class 2 and class 3.  However, ACKs should never be
transmitted by or to a class 3 device.

RemedyEnd:

#21

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause:  5.9
PDFPage: 
DocPage:  20
Line: 
CommentType: T

Comment:

The use of non-zero continue sequence values parameter should not
be allowed.

CommentEnd:

SuggestedRemedy:

In table 11, the Ignore non-zero continue sequence values should be R, R.
They should always be ignored and should never be generated.

RemedyEnd:

#22

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.10
PDFPage: 
DocPage:  21
Line: 
CommentType: T

Comment:

In table 12, two of the Basic Link Services are labeled as being originated,
where they are really only used as responding functions.

CommentEnd:

SuggestedRemedy:

In table 12, for the Basic Accept and Basic Reject frames, the "originated
by SCSI initiator" and "originated by SCSI target" columns should be blank.

RemedyEnd:

#23

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.11
PDFPage: 
DocPage:  21
Line: 
CommentType: T

Comment:

The extended link service entries described in table 13 
need to be modified to provide for simple and correct utilization of
the services.

CommentEnd:

SuggestedRemedy:

In table 13 on pages 21 and 22, the following features should be modified:

   Accept (ACC)		This should only be in the Response columns, since
   			it is a response, not a request.
   			
   Fabric Login (FLOGI)	This is responded to only by fabrics.  Non-fabric
   			nodes will respond with a reject.  Therefore,
   			the response columns for SCSI targets and initiators
   			should be indicated as P.
   			
   FAN			This is responded to only by fabrics.  Non-fabric
   			nodes will respond with a reject.  Therefore,
   			the response columns for SCSI targets and initiators
   			should be indicated as P.
   			
   LINIT, LPC, LSTS	Note 6 says that FAN is the preferred method for
   			authenticating addresses during loop initialization.
   			Therefore, these functions should not be invocable,
   			they should be prohibited.
   			
   LS_RJT		This is used only as a response.  As such, the
   			"originated by" columns should be blank.
   			
   PRLI			Normally, the process logins are initiated by
   			a host adapter searching for its attached drives and
   			attempting to distinguish them from non-SCSI or
   			SCSI initiator devices.  However, it is possible that
   			a SCSI target might choose to verify its list of
   			possible initiators to properly allocate initiator
   			related resources.  As such this might be one of
   			the rare cases where a function might be allowed
   			rather than prohibited.
   			
   PRLO			The I,R combination originated by a target is
   			only acceptable if PRLI can also be performed
   			by a SCSI target.  Otherwise, it too should be
   			P,P.  See PRLI above.
   			
   RSI, RSS		These functions should be prohibited or required.
   			If they are used for recovery in one of the
   			scenarios created by this document, they should
   			be required, otherwise prohibited.
   			
   TPRLO		Unless there is an explicitly documented recovery
   			process that requires this ELS, it should be prohibited.

RemedyEnd:

#24

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.13.1
PDFPage: 
DocPage:  24
Line: 
CommentType: T

Comment:

In the first bulleted item, there is an incomplete statement about ending
an Exchange.  If no FCP_CONF is requested, this is true.  If FCP_CONF is
requested, the Exchange cannot end until the FCP_CONF is transmitted and
any required ACKs are received.

CommentEnd:

SuggestedRemedy:

This item should be divided into two items.  One should express the
termination where FCP_CONF is not transmitted, the other where FCP_CONF
is transmitted.  Note that class of service is also part of this.

RemedyEnd:

#25

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.13.2
PDFPage: 
DocPage:  24
Line: 
CommentType: T

Comment:

In the first bulleted item, there is an incomplete statement about ending
an Exchange.  If no FCP_CONF is requested, this is true.  If FCP_CONF is
requested, the Exchange cannot end until the FCP_CONF is transmitted and
any required ACKs are received.

CommentEnd:

SuggestedRemedy:

This item should be divided into two items.  One should express the
termination where FCP_CONF is not transmitted, the other where FCP_CONF
is transmitted.  Note that class of service is also part of this.

RemedyEnd:

#26

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.13.3.2
PDFPage: 
DocPage:  25
Line: 
CommentType: T

Comment:

The item b) under the description of behavior for sequences that
transfer sequence initiative says that the same SEQ_ID can be used.
This seems to me like a very bad idea that should be avoided.  There
should be no benefit to such reuse and it does allow improper behavior
detected only be sequence count information in some cases.

CommentEnd:

SuggestedRemedy:

The SEQ_ID should not be re-used unless R_A_TOV has passed or a
successful recognition of transfer of initiative or termination of
an exchange has been recognized.

RemedyEnd:

#27

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.13.3.2
PDFPage: 
DocPage:  26
Line: 
CommentType: T

Comment:

We are allowing all-together too much grandfatherliness here.  Note 2
in the middle of the page should be removed.  A device should either
not stream sequences or should maintain continuously increasing sequence
counts.

CommentEnd:

SuggestedRemedy:

Remove Note 2 in the middle of the page.  This implicitly requires
item 2 iv to be always fulfilled.  This can be fullfilled either by
not streaming sequences or by managing the sequence count properly.

RemedyEnd:

#28

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.13.4
PDFPage: 
DocPage:  27
Line: 
CommentType: T

Comment:

Items b and e are implicitly detected immediately.  The text should be
clarified to indicate that such cases may be detected at the recipient's
leisure, as long as no actions are taken by the host or target that use
the incorrectly sequenced data.  In particular, such checking may be
performed outside hardware and may take several frame times to discover.

CommentEnd:

SuggestedRemedy:

Make it explicitly clear that detection of some of these items, especially
item b and e, may not be detected immediately, but shall be detected before
the data is used.

RemedyEnd:

#29

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 5.13.4
PDFPage: 
DocPage:  27
Line: 
CommentType: T

Comment:

Item f in this list indicates that a sequence error occurs if a frame
in a sequence is not received within E_D_TOV of the previous frame.  While
this may tend to be true within a given loop tenancy, it is certainly not 
a requirement in the presence of a busy loop that allows partial sequences
to be transmitted in a single tenancy.  

By the way, this is also a bug in PLDA.

CommentEnd:

SuggestedRemedy:

Item f should either be removed or it should be explicitly stated that
this is true only in point-to-point connections or within a single
loop tenancy.

RemedyEnd:

#30

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 6
PDFPage: 
DocPage:  28
Line: 
CommentType: T

Comment:

This is the place to state a principle.  All features should be either
prohibited or required or else a carefully worded justification and note
must be provided.  Otherwise, the profile's principal goal of guaranteeing
interoperability cannot be met.

CommentEnd:

SuggestedRemedy:

All cases where an originator may invoke a function require that the
recipient implement the function.

All cases where a function is allowed should be reviewed carefully, since
any case that is allowed will guarantee interoperability problems at
either the hardware, protocol, or driver/application level.  Almost
all such cases should be changed to prohibited, although a few might
become required.  Any case where "allowed" is used must have a clear and
complete justification of the special case.

RemedyEnd:

#31

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 6.1
PDFPage: 
DocPage:  28
Line: 
CommentType: T

Comment:

Full duplex should be the only way transfers take place.

CommentEnd:

SuggestedRemedy:

The entries in table 15 should be modified to reflect this.

   Open Full Duplex, Open Originator can send,  should be R, R.
   
   Open Half Duplex, Open Originator can send,  should be P, P.
   
   Open Half Duplex, Open Originator accepts,   should be P, P.

RemedyEnd:

#32

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 6.1
PDFPage: 
DocPage:  28
Line: 
CommentType: T

Comment:

Certain rarely used functions should be removed from the allowed
set of behaviors.

CommentEnd:

SuggestedRemedy:

In Table 15, certain functions should be removed from allowed or 
invocable, as described below:

   Unfairness		Should be P, P.
   
   Transfer State use   Should be P, P.
   
   LPE/LPB Origination  Should be P, P.
   
   LPE/LPB Recognition  Should be P, P.
   
   MRKtx origination	Should be P, P unless there is a clearly defined
   			functional requirement identified and specified
   			by this document.

RemedyEnd:

#33

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 6.1
PDFPage: 
DocPage:  28
Line: 
CommentType: T

Comment:

Note 2 of table 15 is inconsistent with the content of the table.

CommentEnd:

SuggestedRemedy:

LILP and LIRP behavior are required.  Note 2 changes them to optional.
Note 2 should be deleted.

RemedyEnd:

#34

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 7.5
PDFPage: 
DocPage:  32
Line: 
CommentType: T

Comment:

This clause defines two separate R_A_TOV timers, running at different
times and for different purposes.  Implicitly, these timers can have
different values and different but potentially overlapping run times.

CommentEnd:

SuggestedRemedy:

The timing structure must be reviewed.  It is possible that this is
actually two separate timers, one looking for ELS responses and the
other looking for recovery qualifier timeouts.

RemedyEnd:

#35

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 7.7
PDFPage: 
DocPage:  33
Line: 
CommentType: T

Comment:

It is not clear what the start and end times of FCP_TOV are.

CommentEnd:

SuggestedRemedy:

Define FCP_TOV completely or remove the function.

RemedyEnd:

#36

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 7.6
PDFPage: 
DocPage:  32
Line: 
CommentType: T

Comment:

RR_TOV is timing a function which the initiator may not be able to control.
If a target is arrogant enough to actually use such a timer, it must be
responsible enough to explicitly notify the effected initiators that
it has done so by performing a LOGO.  

CommentEnd:

SuggestedRemedy:

The expiration of the RR_TOV timer should require the target to either
verify that the initiator is still active and willing to continue when
possible or should explicitly logout with the initiator.  Failure of a
logout happens within R_A_TOV, since LOGO is an ELS.

RemedyEnd:

#37

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 8.2
PDFPage: 
DocPage:  35
Line: 
CommentType: T

Comment:

Command linking should be prohibited.

CommentEnd:

SuggestedRemedy:

As a result of prohibiting command linking, the enabling sentences of
8.2 (Paragraph 1, second sentence and Paragraph 2, second sentence) should
be removed.

The enabling sentences of 8.2.1 should be removed.  These include:

	The removal of IU T3 where ever found.

RemedyEnd:

#38

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause:  8.2.1.1
PDFPage: 
DocPage:  36
Line: 
CommentType:  T

Comment:

The FCP Command Reference Number is incorrectly described.  The CRN
should increment for commands on an initiator/lun basis.  The CRN
should be 0 for task management functions.  The CRN should be reset
by all actions that reset a LUN or for all LUNs when a target reset 
function is invoked.

CommentEnd:

SuggestedRemedy:

This clause needs to be rewritten after further study.

RemedyEnd:

#39

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 8.2.4.1
PDFPage: 
DocPage:  38
Line: 
CommentType: T

Comment:

This clause should be rewritten to express the following ideas:

   a)	FCP completely and correctly expresses the required behavior
	for FCP_RSP residual checking.
	
   b)   Interesting challenges pop up in the preparation of the FCP_RESID
   	value when data overlay occurs.

CommentEnd:

SuggestedRemedy:

The clause should be entirely replaced with the following text.

"The presentation of the FCP_RESID, FCP_RESID_UNDER, and FCP_RESID_OVER
fields and indicators shall be as required by 7.4.1 and 7.4.2 of FCP.
Data bytes associated with data overlay operations may be transferred multiple
times, but for the purposes of FCP_RESID calculations, shall be counted
only once."

RemedyEnd:

#40

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 8.2.4.3
PDFPage: 
DocPage:  38
Line: 
CommentType: T

Comment:

This information is redundant with FCP and should be deleted.

CommentEnd:

SuggestedRemedy:

Rewrite 8.2.4.3 as follows:

"The FCP_RSP_INFO field shall be as defined by FCP.  This information should
normally be analyzed before FCP_SNS_INFO is examined, since a failure
indicated by FCP_RSP_INFO may prevent valid execution and completion of
a SCSI command."

RemedyEnd:

#41

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 8.2.5
PDFPage: 
DocPage:  39
Line: 
CommentType: T

Comment:

The definitions of FCP_CONF are already out of date.  

In particular:

	There is no functional model for FCP_CONF.
	
	FCP_CONF is not made class of service independent.

CommentEnd:

SuggestedRemedy:

Continue the study of FCP_CONF and correct this portion of the document
accordingly.

Provide a model that shows under what conditions and why FCP_CONF must
be used.

I have not yet verified the annex, but it should only contain the
information that will later be found in FCP-2.

RemedyEnd:

#42

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 8.3
PDFPage: 
DocPage:  40
Line: 
CommentType: T

Comment:

ACA is a relatively undisciplined function in the SCSI environment.
I would prefer to see it prohibited.  However, if the tape model
really needs it, it should not be allowed, but rather required.

CommentEnd:

SuggestedRemedy:

Prefered remedy:

   Change table 20 as follows:

	Clear ACA = 1				P, P
	
   Change table 21 as follows:

	Auto Contingent Allegiance Type		P, P
	
   Change table 22 as follows:
   
   	Auto Contingent Allegiance (ACA)	P, P
	
   Delete note 1 from table 20, note 1 from table 21, and note 2 from table 22.

Alternate remedy:
  
   Make similar changes to make ACA required.

RemedyEnd:

#43

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v5
ClauseSubclause: 10
PDFPage: 
DocPage:  1.04a P 51
Line: 
CommentType: T

Comment:

This problem was identified against revision 1.04a, but I am leaving
it in here as a reminder to myself and the working group.  It may
have been already corrected, but my reading of 1.06b is still incomplete.

Single Profile Problem:

This is a continuing problem that still pervades this edition of the
document.  I may miss many instances that need to be corrected because of
this, but I will call out this problem name (Single Profile Problem)
so that this need not be repeated over and over for those cases that
I do identify.

This should be a single profile that has the following properties:

	Class independent error recovery mechanism
	
	Class independent public loop operation as the only mechanism
	  (Note that public loop nodes, automatically as part of their normal
	  behavior, are required to operate in private loop environments.)
	  
	Class 3 behavior
	
Then, in the annexes, there should be a discussion of possible additional
error identification mechanisms using class-2 behavior.  These mechanisms
should invoke the same class independent error recovery mechanism described
in the body of the text.  The only benefit of class-2 is a little better
congestion management and possibly slightly more rigorous and timely
error detection.

If we do not do this, we must split the document into at least four
separate and independent profiles, documenting them through the
combination of different feature sets.  That would require the following
profiles to be defined:

	Class 3 only private loop behavior
	
	Class 2 only private loop behavior
	
	Class 3 only public loop behavior
	
	Class 2 only public loop behavior
	
These profiles would all be non-interoperable.

CommentEnd:

SuggestedRemedy:

The first sentence of the clause should be changed to read:

"This clause describes required and optional behavior of SCSI streaming
and Media Changer devices in a public loop configuration using FCP and
a class independent delivery and error recovery service.

RemedyEnd:

#44

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v5
ClauseSubclause: 10.1.1
PDFPage: 
DocPage:  1.04a, 51
Line: 
CommentType: T

Comment:

This problem was identified against revision 1.04a, but I am leaving
it in here as a reminder to myself and the working group.  It may
have been already corrected, but my reading of 1.06b is still incomplete.


Note that ULP timers are grossly effected by tagged queueing.

CommentEnd:

SuggestedRemedy:

Include the following sentence at the end of the first paragraph of this
clause.

"ULP timers must take into account response time increments caused by
command queueing and multi-initiator congestion."

RemedyEnd:

#45

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v5
ClauseSubclause: 10.1.2
PDFPage: 
DocPage:  1.04a, 20
Line: 
CommentType: T

Comment:

This problem was identified against revision 1.04a, but I am leaving
it in here as a reminder to myself and the working group.  It may
have been already corrected, but my reading of 1.06b is still incomplete.

I do not believe that Exchange information should be kept beyond the
transmission of FCP_RSP unless FCP_CONF has been requested.  Isn't that
what FCP_CONF is for?

CommentEnd:

SuggestedRemedy:

Change this clause to read:

"The target shall manage Exchanges using the OX_ID/RX_ID pair and shall
maintain Exchange information until the FCP_RSP has been successfully
transmitted, or, if FCP_CONF has been requested, until FCP_CONF has been
received."

RemedyEnd:

#46

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 10.1
PDFPage: 
DocPage:  52
Line: 
CommentType: T

Comment:

ACA is a relatively undisciplined function in the SCSI environment.
I would prefer to see it prohibited.  However, if the tape model
really needs it, it should not be allowed, but rather required.

CommentEnd:

SuggestedRemedy:

Change section 10.1 to say:

"ACA is prohibited for this profile."

If you really must have ACA, then say:

"Initiators and Targets compliant with this profile shall support ACA.

NACA shall be set to 1 for those CDBs that have defined an upper layer
recovery protocol that requires ACA for completion.  NACA shall be set to
0 for those CDBs that are recovered without ACA."

You must then go on and describe both the recovery action and the conditions
under which NACA will be required, both things that I believe are
vendor specific and very intractable.  Without a complete interoperability
model, ACA is not a meaningful addition to the profile.

RemedyEnd:

#47

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 10.3
PDFPage: 
DocPage:  53
Line: 
CommentType: T

Comment:

The SCSI target discovery and verification is described in this
section for PLDA only.  This should use the FLA recovery.

CommentEnd:

SuggestedRemedy:

Replace the relevant portions of this clause with the FC-FLA documentation.
This requires a device to use FAN instead of ADISC/PDISC if it has
determined that it is operating as a public loop device and ADISC/PDISC if
it has determined that it is operating in degraded mode as a private loop
device.  See FC-FLA table B.1, note 8.

This change pervades this subclause.

RemedyEnd:

#48

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 11.3
PDFPage: 
DocPage:  58
Line: 
CommentType: T

Comment:

Command linking should be prohibited.

CommentEnd:

SuggestedRemedy:

Rewrite 12.3 to read:

"The use of command linking is prohibited by devices conforming to this
profile."

RemedyEnd:

#49

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 11.4
PDFPage: 
DocPage:  58
Line: 
CommentType: T

Comment:

The ERASE command should either be able to depend upon the
implementation of SHORT or it should be prohibited.  

CommentEnd:

SuggestedRemedy:

In Table 24, make ERASE SHORT  P, P.

RemedyEnd:

#50

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 11.4
PDFPage: 
DocPage:  58
Line: 
CommentType: T

Comment:

The FORMAT MEDIUM command should be mandatory and its 
IMMEDIATE bit capability should be mandatory.  For those formats of
tape medium that do not actually require formatting, the command
should leave the tape in the same state that the FORMAT MEDIUM
command would leave a tape that did require formatting.  In such a case,
the FORMAT MEDIUM command would be otherwise a NOP.

CommentEnd:

SuggestedRemedy:

In Table 24, make FORMAT MEDIUM      I, R.
Add a row to indicate IMMED is	     I, R.

Add a note that indicates:

"If the medium type does not require formatting, the tape shall be
be positioned at BOM or BOP 0 and no other action shall be taken.
The FORMAT MEDIUM command shall not be rejected as not supported."

RemedyEnd:

#51

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 11.4
PDFPage: 
DocPage:  58
Line: 
CommentType: T

Comment:

Several of the INQUIRY command features are specified as allowed or
required.  Other profile treatment is preferred.

CommentEnd:

SuggestedRemedy:

In Table 24, the following changes should be made in the profile definitions
of some INQUIRY vital product data page codes:

hex 81 (Implemented Operations)  		should be P, P.
hex 82 (ASCII implemented operations)		should be P, P.

RemedyEnd:

#52

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 11.4
PDFPage: 
DocPage:  58
Line: 
CommentType: T

Comment:

Several of the LOAD/UNLOAD command features should be specified as
prohibited or required, not allowed.

CommentEnd:

SuggestedRemedy:

In Table 24, under the LOAD/UNLOAD command, the following changes
should be made in the profile definitions:

EOT = 1						should be P, P
Load = 1					should be I, R or P, P
Reten = 1					should be I, R or P, P

RemedyEnd:

#53

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 11.4
PDFPage: 
DocPage:  59
Line: 
CommentType: T

Comment:

A number of changes should be made in the details of various commands
to make them either P, P or I, R to allow for non device specific
driver implementations.

CommentEnd:

SuggestedRemedy:

In Table 24, on pages 59, 60, and 61, the following changes should be made 
to clarify whether or not the functions can be used without forcing error 
recovery in an interoperable environment.

   LOCATE:
   
   	BT = 1				should be P, P
   	CP = 1				should be I, R
   	
   LOG SELECT:   			should be P, P, and all bits removed.
   
   					if someone really needs this, the
   					usage intent should be explained in 
   					a note and it should be I, R
   	
   	If LOG SELECT is made I, R, then the following additional changes
   	are required:
   	
   	PC = 00	(threshold)		should be P, P
   	PC = 10 (default threshold)	should be P, P
   	PC = 11 (default cumulative)	should be P, P
   	
   LOG SENSE:
   
   	SP = 1				should be P, P
   	PPC = 1				should be P, P
   	PC = 00				should be P, P
   	PC = 10				should be P, P
   	PC = 11				should be P, P
   	
   	Page select 0C			valid values need to be specified.
   	
   MODE SENSE/MODE SELECT (6)		should be P, P
   
   MODE SENSE/MODE SELECT (10)		should be I, R
   
   	DBD = 1				should be P, P
   	PC = 00				should be I, R
   	PC = 10				should be I, R
   	PC = 11				should be P, P
   	Pages 01 - 10			individual values required should be
   					specified, or pages should be 
   					prohibited.  Frankly, no one trusts
   					an end user to set most of these fields 
   					anyway.
   	Pages 11 - 14			should be P, P unless partitions
   					are truly required, in which case
   					these pages should be I, R.
   					
   	Page 0F (compression)		should be added as P, P.				
   					
   PERSISTENT RESERVE IN		should be I, R
   
   PERSISTENT RESERVE OUT		should be I, R
   
   PREVENT/ALLOW MEDIUM REMOVAL		should be I, R.  It is described by
   					SPC, not SSC.  The subset of function
   					required and prohibited should be
   					specified.
   					
   READ
   	Fixed = 0			should be I, R.  A note on the 
   					proper use of variable length reads
   					is probably required.
   					
   	SILI = 1			should be I, R.  A note on the 
   					proper use of the SILI bit is
   					probably required.
   					
   READ BUFFER				should be P, P.  Recover buffered
   					data does any practical job that
   					READ BUFFER may have originally been
   					intended for.
   
   READ POSITION
   	BT = 0 is vendor specific	should either be P, P or a note 
   					should be added to specify a required
   					vendor specific format as I, R.
   					
   	BT = 1				should be I, R.
   	
   READ REVERSE				should be P, P.
   
   RECEIVE DIAGNOSTIC RESULTS		should be P, P.  A note should
   					indicate that the command is I, R
   					if SES functionality is included in the
   					device.
   					
   RECOVER BUFFERED DATA		
   
   	Fixed = 0			should be I, R.  A note on the proper
   					use of variable length data is 
   					probably required.
   					
   	SILI = 1			should be I, R.	A note on the prope
   					use of the SILI bit is probably
   					required.
   					
   	FIFO, LIFO			I did not find these bits defined in
   					SSC.  If they are not defined there,
   					they must be included in a "this needs
   					to change" annex.  FIFO should be P, P.
   					
   RELEASE (6)				should be P, P
   
   RELEASE (10)				
   
   	Third Party = 1			should be P, P
   	
   RESERVE (6)				should be P, P
   
   RESERVE (10)
   
   	Third Party = 1			should be P, P
   	
   SEND DIAGNOSTIC
   
   	ST = 0				should be P, P.  A note should indicate
   					that the command is I, R if SES
   					functionality is included in the device.
   					
   SET CAPACITY				should be added to the list as P, P.
   
   SPACE
   
   	Code 010 (Sequential FMK)	should be I, R.
   	Code 011 (EOD)			should be I, R.  Emulation is 
acceptable.
   	Code 100 (Setmarks)		should be P, P.
   	Code 101 (Seqntl Setmarks)	should be P, P.
   	
   VERIFY				should be P, P.
   
   WRITE
   
   	Fixed = 0			should be I, R.
   	
   WRITE BUFFER				should be I, R for downloads, 
  					should be P, P for all others.

RemedyEnd:

#54

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 11.4
PDFPage: 
DocPage:  60
Line: 
CommentType: T

Comment:

The presence of an attached loader should be discussed in section 12.4
The commands involved with attached loaders should not be included in
Table 24.

CommentEnd:

SuggestedRemedy:

Remove the following attached loader commands from Table 24.  They are
already included in Table 26.  Table 26 should be expanded to contain the
individual command features specified in Table 24.

   MOVE MEDIUM ATTACHED
   READ ELEMENT STATUS ATTACHED
   	The command features should also be moved to Table 26 with the
   	following changes:
   	
   		Vol Tag = 1		should be P, P.

RemedyEnd:

#55

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 11.4
PDFPage: 
DocPage:  62
Line: 
CommentType: E

Comment:

Note at bottom of table 24 on page 62 has an incorrect table reference.

CommentEnd:

SuggestedRemedy:

Table reference should probably be to table 26.

RemedyEnd:

#56

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 12.3
PDFPage: 
DocPage:  62
Line: 
CommentType: T

Comment:

Command linking should be prohibited.

CommentEnd:

SuggestedRemedy:

Change 12.3 to read:

"The use of command linking by media changer devices conforming to this
profile is prohibited."

RemedyEnd:

#57

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 12.4
PDFPage: 
DocPage:  62
Line: 
CommentType: T

Comment:

There are too many options allowed in table 25 to assure interoperability.
In addition, the information is incomplete, since individual fields may
also be optional and should be either required or prohibited.

CommentEnd:

SuggestedRemedy:

The following changes should be made in table 25.

  All commands				should have subfields specified as
  					to whether they are P or R.

  CHANGE DEFINITION			should be P, P.
  
  EXCHANGE MEDIUM			should be I, R
  
  INITIALIZE ELEMENT STATUS		should be I, R (a note might be used to
  					indicate that this can be implemented
  					as a NOP.)
  					
  INQUIRY
    	
  	hex 81 (Implemented Operations)  		should be P, P.
  	
  	hex 82 (ASCII implemented operations)		should be P, P.
  					
  LOG SELECT				should be P, P.
  
  MODE SENSE/MODE SELECT (6)		should be P, P
   
  MODE SENSE/MODE SELECT (10)		should be I, R
   
   	DBD = 1				should be P, P
   	PC = 00				should be I, R
   	PC = 10				should be I, R
   	PC = 11				should be P, P
   	Page 1D (addr assignment)	This should be P,P for MODE SELECT,
   					I, R for MODE SENSE.
   	Page 1E (transport geometry)	This should be P, P for MODE SELECT,
   					I, R for MODE SENSE.
   					
   	Page 1F (capabilities)		This should be P, P for MODE SELECT,
   					I, R for MODE SENSE.
  
  PERSISTENT RESERVE IN			should be I, R.
  
  PERSISTENT RESERVE OUT		should be I, R.
  
  POSITION TO ELEMENT			should be P, P.
  
  PREVENT ALLOW MEDIUM REMOVAL		should be I, R.
  
  READ BUFFER 				should be P, P.
  
  RECEIVE DIAGNOSTIC RESULTS		should be P, P, unless SES functionality
  					is included, in which case it should
  					be I, R.
  					
  RESERVE/RELEASE ELEMENT(6)		should be P, P.
  
  RESERVE/RELEASE ELEMENT(10)
  
     	Third Party = 1			should be P, P

	Element = 1			should be P, P
  
  REQUEST VOLUME ELEMENT ADDRESS	should be I, R or P, P.
    
  REZERO UNIT				should be P, P.
  
  SEND DIAGNOSTIC			
  
  	ST = 0				should be P, P, unless SES functionality
  					is included, in which case it should
  					be I, R.
  					
  SEND VOLUME TAG			should be P, P.
  
  WRITE BUFFER				should be I, R for downloads, 
  					should be P, P for all others.

RemedyEnd:

#58

NameLastFirst: Snively, Robert
Email: Bob.Snively at sun.com
Phone: (510) 574-9051
Fax: 
CoOrg: Sun Microsystems
Project: Project 1315DT, FC-TAPE, T11/98-124v7
ClauseSubclause: 12.4
PDFPage: 
DocPage:  63
Line: 
CommentType: T

Comment:

There are too many options allowed in table 26 to assure interoperability.
In addition, the information is incomplete, since individual fields may
also be optional and should be either required or prohibited.

CommentEnd:

SuggestedRemedy:

The following changes should be made to table 26.

  All commands				should have subfields specified as
  					to whether they are P or R.
  
  Only one of the command set should be used.  I would propose that
  only A7 and B4 be used, since all other cases are handled by 
  table 25.  As a result, table 25 would be changed as follows:
  
  MOVE MEDIUM ATTACHED (A5h)		should be P, P.
  
  READ ELEMENT STATUS ATTACHED (B8h)	should be P, P.

RemedyEnd:

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list