FC-TAPE Minutes, 4 Aug 1999, Rochester MN

Edward A. Gardner eag at ophidian.com
Thu Aug 12 14:15:00 PDT 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* "Edward A. Gardner" <eag at ophidian.com>
*
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I recall several votes being taken.  Why are none of them recorded in
the minutes?  Whether you call them a straw poll or a motion is
irrelevant, they need to be recorded.  Otherwise we are wasting our
time, as if decisions aren't recorded we will revisit them again and
again and again...

One specific example, under the FCP-2 review:

>#004  FCP restricts FCP_CONF to queuing. Charles felt this was
unnecessarily
>restricting. Bob felt that the initiator should know when it could
expect
>that the target could request a confirm. No change

I recall the vote overwhelmingly disagreeing with this and Bob
agreeing to change FCP-2 to allow FCP_CONF at any time.

Edward A. Gardner               eag at ophidian.com
Ophidian Designs                719 593-8866 voice
1262 Hofstead Terrace           719 593-8989 fax
Colorado Springs, CO  80907
- -----Original Message-----
From: WYATT,STEWART (HP-Boise,ex1) <stewart_wyatt at am.exch.hp.com>
To: 'SCSI Reflector' <t10 at t10.org>; 'Fibre Channel Reflector'
<fc at nsg0.network.com>
Date: Friday, August 06, 1999 3:22 PM
Subject: FC-TAPE Minutes, 4 Aug 1999, Rochester MN


>Joint T11/T10 TAPE AdHoc Meeting, August 4, 1999 - Rocehster, MN
>T11/99-471v0
>Stewart Wyatt, FC_TAPE Secretary, 208-396-3594, stewart_wyatt at hp.com
>
>1. Introductions: Group 
>
>The facilitator, Dale LaFollette, called the meeting to order at 5 PM
and,
>as is customary, had the participants introduce themselves.
>
>2. Approval of this Agenda: T11/99-429v0 - Group
>
>The agenda was approved with a number of additions and a few changes
that
>are included in these minutes
>
>3. Approval of 7/13/99 Minutes: T11/99-411v1 - Stewart Wyatt
>
>Approved.
>
>4. Review Old Action Items: Stewart Wyatt
>
>#1. HP (Steve Jerman): to continue MAM discussion and post
presentation. -
>Ongoing
>#2. Eric Oetting - to collect issues from the SCC letter ballot
comments for
>the SPC-2. - Deferred until next month.
>#3. Dave Peterson: - to update the SSC. - Completed
>#4. Stephen Gold (Stewart Wyatt) HP: Resolve IBM letter ballot
comments on
>TapeAlert. - Ongoing 
>#5. Stewart Wyatt: Report on FC Tape Connector resolution. Completed
>#6. Bob Snively and Bob Kembel: Create a list of the specific BLS and
ELS
>which are allowed before Login, including explicit Login, in an annex
for
>later placement in the FC-FS. - Ongoing
>#7. Bob Snively: Review the SRR statement, it may not be flexible
enough for
>the target. SRR must be properly interpreted in context and command
known by
>the target. "Nasty case is did the transfer ready or the response (to
an
>error) get hit." Deferred
>#8. Bob Snively: Return clause 2.8 to previous text. - Deferred
>#9. Bob Snively: Change Table 2 - Discovery of FCP capabilities entry
>"Initiator performs REC", Discovery mechanism needs to be changed
from
>"None/Process Login" to "See References". - Deferred
>#10. Dave Peterson and group: Extend current document to cover LIP
discovery
>process. Participants asked to communicate concerns to Dave. -
Ongoing
>#11. Carl Zeitler: Review need for process associators. - Due in
October.
>
>5. SSC: T10 Working Drafts SSC-R18, LB Comment Resolution
T10/99-011r3
>- Dave Peterson
>
>Will finish by next month. George has asked all SPC references be
changed to
>SPC-2 and all SCSI references should drop the -3 after SCSI. (Use
SCSI
>instead of SCSI-3)
>
>6. FCP-2: T10 Working Drafts FCPR02, Changes to FCP-2, T10/99-211r1 -
>Bob Snively
>
>Bob reviewed Charles Binford's "two and three star" comments from a
file
>called LSI.PDF. (Charles had graded his comments in order of
importance by
>assigning them one, two or three stars.)
>
>#004  FCP restricts FCP_CONF to queuing. Charles felt this was
unnecessarily
>restricting. Bob felt that the initiator should know when it could
expect
>that the target could request a confirm. No change
>
>#006 LUN reset should be added to the table 3. Bob agreed 
>
>#007 FCP actions should only affect FCP exchanges. Bob agreed.
>
>#008 Charles would like to reserve a device with dual ports where
both ports
>were included in the reservation. He thought this could be
facilitated by
>using the WWN for reservation. This led to a long discussion with the
>problem that the address space doesn't cross domains. Charles'
request is an
>architectural issue in violation of SAM. Bob agreed that the concept
had
>merit and wanted to continue the discussion later.
>
>#010 Confirmed Completion allowed. Charles thought the title was
misleading
>especially in view of comment #004.  Bob said he may review the
title.
>
>#012 page 30, 7.1, 1st paragraph, "the target shall not reject
requests for
>retransmission of FCP_XFER_RDY or FCP-RSP". Matthew Wakeley felt that
this
>was too strong of wording. Bob felt that if the device supports the
error
>recovery, it should always comply. It may be necessary to separately
specify
>FCP_RSP and FCP_XFER_RDY. The issue was not resolved.
>
>#014 Bus Inactivity limit and #015 Disconnect time limit. Charles
thought
>these two parameters were specified inconsistently. George thought
the
>specification was taken from earlier SCSI documents. Bob will review
to them
>to make sure they are consistent with previous SCSI documents.
>
>#018 Why is RR_TOV so huge?  Clause 10.3 change "must" to "shall"
last
>paragraph of 10.3. Add default value for RR_TOV for non REC_TOV error
>recovery.
>
>#022 page 57 11.1.2 second to last paragraph - what should a target
do if it
>receives an ABTS? Bob agreed to do research.
>
>#027 REC data count is over exchange not sequence. Check wording.
>
>#029 page 58, 11.2.5 FCP_RSP Recovery. Charles questioned the
statement that
>a target shall retain exchange information until the queue depth is
>exceeded.  Charles was concerned that the tape requirements are being
>imposed on disks. Jim Coomes agreed with Charles concern. A long
discussion
>with many tangents followed. Clause 11 needs a statement to make sure
that
>optional error recovery behavior is clearly noted. The end result of
the
>discussion is that if a target is queuing and not using FCP_CONF, the
>exchange information retained by the target can only be vendor
specific or
>undefined. A proposal to only keep bad status was rejected since it
would
>not allow differentiating a successfully completed command whose
status had
>been discarded from a command that was lost.
>
>Following is a summary of the cases of where the target can clearly
know
>when to discard completed exchange data in regard to using FCP_CONF:
>
>Class 2 works with and without FCP_CONF - FCP-CONF is optional.
>Class 3 error retry and queuing, FCP_CONF is required, keep all
FCP_RSP not
>confirmed.
>Class 3 no error retry, queue or not, without FCP_CONF (Bob: retry
optional
>and random results)
>
>The discussion went down a significant tangent about moving the
FC-TAPE
>developed error recovery approach into the FCP-2.  The problem is
that it
>appeared that tape error recovery requirements were being imposed on
disk
>drives. Also what subset of the tape error requirements could a disk
adopt
>without breaking it. There was a concern that the FCP was making
guidelines
>a part of a standard. The discussion focused on the effect on disk
drives
>that may want to use FCP_CONF but don't want the restrictions that
Bob has
>required the error recovery. Bob was restricting the use of FCP_CONF
to the
>applications described in a model that was developed last year. This
limited
>FCP_CONF to bad status responses and queuing. Ed Gardner and Dal
Allan
>argued that the target should be able to ask for the CONF at its
discretion
>and that an initiator should always comply.  A straw poll vote was
taken
>with 14 in favor of the change and 2 in favor of retaining the
current
>wording. Bob asked Dal for a new model to justify the change.
>
>#033 Target needs to provide a unique RX_ID when FCP_CONF is used.
RX_ID =
>FFFFh invalid, class independent.
>
>6.1 Jim Coomes: 99-226r0
>
>Jim's proposal was to clarify the Fibre Channel Control Mode page 19,
>Disable Soft Address (DSA). The clarification limits address
selection to
>the hard address phase only (LIHA). Otherwise the device goes into
>nonparticipating mode. The intent of this bit was to not only to
preclude
>the device from choosing an address during the soft address phase
(LISA) but
>to preclude it from selecting its address during the previously
assigned
>address phase (LIPA).
>
>Matt Wakeley was concerned that this would break some existing
>implementations. Jim notes that this is the way that Seagate
implemented
>this function. Bob Snively thought that this was the way most disks
were
>implemented. Jeff Williams asked for a delay to check the impact on
his
>design. This started a long discussion which resulted in a straw poll
with
>the result that 8 voted to oppose a delay and 7 voted to allow delay.
 A
>second straw poll was taken asking if the change should be included
in the
>next revision of the FCP (rev 3). The results were 7 for, 7 opposed.
Another
>heated discussion followed about whether this was a technical or
editorial
>change.  There was also a proposal to change the name to something
like,
>"Select only Hard Address."
>
>6.2 Charles Binford: LSI.PDF
>
>While the facilitator added this as a separate agenda item, it was
actually
>covered in item #6, FCP review.
>
>6.3 MCM George Penokie: T11/99-206r0
>
>George proposed adding three fields to Fibre Channel Control page 19
for
>controlling MCM applications. 
>Bob Snively objected to using mode pages because the applications are
not
>FCP functions and apply to other protocols as well. He thought they
should
>be controlled by the use of either an ELS or a login procedure. Jeff
>Williams noted that the other bits in this page are also not
necessarily
>SCSI specific either and failed to see Bob's distinction. Bob Kembel
raised
>a concern that these behaviors will affect protocols other than SCSI.
Dal
>Allan spoke in favor of George's proposal by noting that there was no
>precedence for using ELS or login procedures for these controlling
this type
>of parameters. SCSI has traditionally used mode pages to tune
operations. If
>other protocols want these controls let them work out a procedure. Ed
>Gardner encouraged those who want to use an ELS for this purpose to
make a
>proposal that could be reviewed. George said he would be revising the
>proposal with input from an earlier meeting where the proposal was
also
>presented. Bob raised a second issue about the proposal in that it
extended
>the length of the page. George noted that the page length is part of
the
>payload.  Bob wanted to make additional page length optional, as he
is
>concerned about compliance to FCP-2.
>
>7. Media Auxiliary Memory T10/99-223r1 - Sid Crighton
>
>Last month Steve Jerman made a presentation. As a result of
discussion
>during and after the meeting the proposal was modified. Sid Crighton
gave a
>quick overview of the old proposal and described the changes that
have been
>made. The changes included dropping the use of Read Element Status
and the
>use of Log page 0Ah. The terminology is changed from "parameters" to
>"attributes". The addition includes two new commands for the SPC-2,
Write
>Attribute and Read Attribute. The Inquiry VPD page is to be retained
to
>allow read access for reserved devices.
>
>The justification of moving the documentation to the SPC is that this
>capability has application to any type of removal media device.
>
>8. Tape Connector Update SFF8072 - Stewart Wyatt
>
>Stewart reviewed the changes made to the proposal. The 12 Volt pins
had been
>reduced from 8 to 5 to improve compatibility with the SCSI connector
with
>the understanding that the pins were rated more than 1 Amp each. Dal
Allan
>reported that the pins were capable of handling 1.5 Amps currently.
This
>could be improved by changing the material of the connector.
>
>8.1 Curt Ridgeway 99-410v1
>
>Curt had a counter proposal to the one made by Stewart. Curt's
proposal was
>for a "fat pipe" proposal of 8 channels on the same connector to
enable
>improved performance by striping the data transfer across 4 dual port
>channels. While Curt was successful in demonstrating that it was
possible,
>he agreed to rework his proposal with a 100 pin connector to provide
some
>spare pins and to avoid slowing down the tape connector proposal
which is a
>critical path activity for the tape manufacturers.
>
>9. T11 New Business: Group
>
>None
>
>10. T10 New Business: Group
>
>None
>
>11. Next Meeting Requirements: Group
>
>Four hours minimum
>
>12. Review New Action Items: Stewart Wyatt
>
>Old forwarded action items
>
>#1. Eric Oetting - to collect issues from the SCC letter ballot
comments for
>the SPC-2. - Deferred until next month.
>#2. Stephen Gold (Stewart Wyatt) HP: Resolve IBM letter ballot
comments on
>TapeAlert. - Ongoing 
>#3. Bob Snively and Bob Kembel: Create a list of the specific BLS and
ELS
>which are allowed before Login including explicit Login in an annex
for
>later placement in the FC-FS. - Ongoing
>#4. Bob Snively: Review the SRR statement, it may not be flexible
enough for
>the target. SRR must be properly interpreted in context and command
known by
>the target. "Nasty case is did the transfer ready or the or response
(to an
>error) get hit." Deferred
>#5. Bob Snively: Return clause 2.8 to previous text. - Deferred
>#6. Bob Snively: Change Table 2 - Discovery of FCP capabilities entry
>"Initiator performs REC", Discovery mechanism needs to be changed
from
>"None/Process Login" to "See References". - Deferred
>#7. Dave Peterson and group: Extend current document to cover LIP
discovery
>process. Participants asked to communicate concerns to Dave. -
Ongoing
>#8. Carl Zeitler: Review need for process associators. - Due in
October.
>
>New Action Items
>
>#1. HP (Steve Jerman/Sid Crighton): Continue MAM discussion. Post
>presentation made today. Contact Ralph Weber about including MAM in
the
>SPC-2. Make presentation to SCSI working group next month. Resolve
issues
>with Sony AIT per Joe Breher's concerns. Determine need, if any, for
content
>to be placed in the SSC.
>#2. Bob Snively: (Binford FCP comment #006) LUN reset should be added
to the
>table 3. 
>#3. Bob Snively: (Binford FCP comment #007) FCP actions should only
affect
>FCP exchanges. 
>#4. Bob Snively: (Binford FCP comment #014 and #015) Check to see
that Bus
>Inactivity limit and  Disconnect time limit are specified
consistently with
>other SCSI standards.
>#5. Bob Snively: (Binford FCP comment #022) Define what a target
shall do
>when it receives a ABTS. 
>#6. Bob Snively: (Binford FCP comment #027) Check wording to see that
REC
>data is counted is over an exchange not a sequence.
>#7. Bob Snively: (Binford FCP comment #029) Optional error recovery
>procedures need to be clearly marked. The requirements for using
error
>recovery procedures in class 3 need to be clearly specified for disk
drives.
>A target may request an FCP_CONF at its disgression.
>#8. Bob Snively: (Binford FCP comment #033) Target must use valid
RX_ID (<>
>FFFFh) when using FCP_CONF.
>#9. Bob Snively: (Binford FCP comment #018) Add a default value for
RR_TOV
>for non REC_TOV error recovery.
>#10. Bob Snively: Binford FCP comments #008, using WWN for
reservations, and
>#010, title for Confirmed Completion Allowed, appeared to be
unresolved
>without specific action items. In addition the proposal by Jim Coomes
to
>clarify the DSA field appeared unresolved as well as a proposal to
rename it
>more appropriately.
>
>13. Adjournment: Group - At 9:20
>
>Attendance:
>
>Dale Lafollette Storage Tek Horst Truestedt True Focus
>Cutis Ridgeway LSI Charles Binford LSI Logic
>Dave Ford Clariion Arlan Stone UNISYS
>Sid Crighton HP Joe Breher Exabyte
>Gile Frazier IBM Damian Bannon SSL
>Bill Lynn Adaptec Shinya Iguchi Hitachi
>Mark Dewilde Pathlight Matt Gaffney StorageTek
>Mike Fitzpatrick Fujitsu CPA Edward A. Gardner Ophidian
>Designs
>Pak Seto Quantum Matt Wakeley HP
>Jim Coomes Seagate Bill Martin Gadzoox Networks
>Stewart Wyatt HP Danny Ybarra TI
>Paul Suhler Seagate Bob Kembel Connectivity Solutions
>Carl Zeitler Compaq Paul Entzel Quantum
>Dave Baldwin Emulex John Lohmeyer LSI Logic
>Dal Allan ENDL George Penokie IBM
>Jeff Williams WD Dennis Moore KnowledgeTek 
>
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2

iQA/AwUBN7M5VJsv4MZNZL9GEQKhNgCfSKPakSw9ULfIMl9jXdVm3evzERQAn3Ir
hKn3Ptn84jDqo/YqNbISf1jc
=J46A
-----END PGP SIGNATURE-----


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






More information about the T10 mailing list