Some comments on FC-TAPE v 1.06b

Talluto, Dennis dennis.talluto at eds.com
Thu Jul 9 17:05:16 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Talluto, Dennis" <dennis.talluto at eds.com>
*
Bob,

Just a couple comments on your comments - 


#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:

Talluto comment: I do not have the specific detailed knowledge on this, but
I would not want to see the possibility of peer-peer storage elements
prohibited in anyway.  True, in today's environment, with SCSI protocols and
initiator/target relationships, direct disk-disk, disk-tape, and tape-tape
are not implemented (I know that there are some proprietary deliverables
using microprocs/microkernels, but that is a whole other breed).  What we
are interested in pursuing with some of our suppliers is IPI-3 capabilities
and functions, that will allow brokered or third party I/O under the
management of an appropriate integrity manager.  I would just hate to see
peer-peer devices precluded.  Please correct me if I am wrong and this does
not pertain.


#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:

Talluto comment: I fail to see the difference between the results of the
comment and the results of the suggested remedy.  It seems that both
statements allow for the support of either class2 or class3.  The only
impact that I could see is if someone would choose to implement class2
drivers only - that would be prohibited. 



#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:

Talluto comment:  I concur.  This (explicitness and interoperability) will
be the industry's fastest path to market penetration and success.  You
already face some significant barriers to entry without creating new ones.



#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:

Talluto comment:  I concur.


#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.

>>>>>  CLIP  <<<<<<


Talluto comment:  I concur.


# 37 & #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:

Talluto Comment: If this is the same as 'command chaining', why should that
be prohibited in an intelligent storage controller?




----------
From:  Bob Snively[SMTP:Bob.Snively at Ebay.Sun.COM]
Sent:  Thursday, July 09, 1998 2:29 PM
To:  fc at network.com; t10 at Symbios.COM
Subject:  Some comments on FC-TAPE v 1.06b

* 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

>>>>>>>>>>>  MAJOR CLIP   <<<<<<<<<<<<<<<<<

*
* 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