FC-Tape minutes, Portsmouth, U.K., August 12, 1998

STEWART_R_WYATT at HP-Boise-om2.om.hp.com STEWART_R_WYATT at HP-Boise-om2.om.hp.com
Tue Aug 18 09:34:40 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* STEWART_R_WYATT at HP-Boise-om2.om.hp.com
*
     FC-TAPE Meeting Minutes    T1198-413.pdf
     Portsmouth, U.K. 12 August 1998
     
     1. Introductions: Facilitator, Dale LaFollette, STK, called the 
     meeting to order. This meeting was scheduled to run from 3 to 9 PM. 
     Dale had just discovered that the room would not be available after 5. 
     He proposed adjourning for supper at 5 and reconvening at 6:30 in a 
     different room. This was agreed to. The agenda was completed, but 
     because of the meeting breaks and the need to bring in outside 
     participants for specific items, the items were not completed in the 
     order listed in the agenda. To improve readability, these minutes are 
     organized into the agenda order.
     
     As is customary, Dale had the participants introduce themselves.
     
     2. Approval of this agenda: T11/98-374v0. Approved.
     
     3. Approval of 7/14 Minutes: T11/98-363v0. Approved
     
     4. Old Action Items: 
     Stewart Wyatt updated the minutes and posted them to the web site. He 
     also posted a TapeAlert announcement to the web site and the 
     reflector. Stephen Gold, HP, was in attendance at this meeting to make 
     a TapeAlert presentation. Dave Peterson is the new SSC editor. He has 
     received notes from Gary Stephens and Rob Basham. Dale LaFollette 
     extended the time for this meeting. Dale also posted a list of 
     commands to the reflector for review.
     
     An additional action item was to obtain the location of the template 
     for making formal review comments: Stewart Wyatt contacted Rich 
     Taborek for this information after the tape meeting. 
     The location is: 
     http://www.g2networks.com/technology/comments/descript.htm
     (Locate the www.g2networks.com web site, select "Technology", then 
     "Fibre Channel", then "Comments on FC-AL-2 Rev 6.3", finally "Comment 
     field descriptions".)
     
     5. Required SCSI Commands: T11/98-375v0
     
     Dale LaFollette led a review of the SPC and SSC commands for inclusion 
     in FC-TAPE. Typically the required/prohibited status was determined by 
     vote. Some commands incurred some discussion which is included below.
     
     Copy command - Brian Smith, Crossroads, said the copy command was 
     being implemented in some 3rd party devices. He expects that it may be 
     required in some tape drives in the future. Nevertheless the 
     participants roundly voted to prohibit it in this profile
     
     There was also some discussion about eliminating six byte commands. 
     This was defeated since it would break many operating systems.
     
     Dale also reviewed the SMC commands. Bob Snively noted that there are 
     other devices besides tapes that implement SMC commands and felt that 
     the decisions should be reviewed by a broader group. The group 
     concluded that this document would only apply to media changers for 
     FC-TAPES. Brian Smith, Crossroads, offered to sample other medium 
     changers requirements to to review and provide comments on this 
     group's decisions.
     
     6. ABTS proposal: Dave Baldwin, Emulex
     
     Dave made two proposals. The first was to assign values to a new 
     parameter field in ABTS. The three assigned values are:
     #1. Abort Exchange set bit 0 to 1
     #2. Abort Sequence set bit 1 to 1
     #3. Check Status set bit 2 to 1 
     The Check Status bit appeared to be redundant with REC. Dave was asked 
     to see if it added new capability to make it worth keeping.
     Dave's second proposal was to allow the sequence recipient to be able 
     to abort the sequence as well as the sequence initiators. No one 
     objected.
     
     7. FC-TAPE draft review. Editor Dave Peterson had completed REV 1.07 
     earlier this week.
     
     Dave had four questions he wanted to discuss.
     
     #1.SCSI Target Discovery ala FLA Clause 10.3 - Dave wanted some 
     guidance on how the target discovery process should be modified from 
     the PLDA to include public tapes. Jeff Stai, Brocade, was found and 
     invited to participate. Jeff said that he did not know what the 
     process should be but offered to consult with Dave in defining the 
     process.
     
     #2. FCP_CONF Issues - The original proposal was to use FCP_CONF in all 
     queued commands. Rob Basham (who was not present) is known to want to 
     use it only at certain checkpoints. Bob Snively was unhappy that a 
     process had not been defined to his satisfaction since the definition 
     left the target to request FCP_CONF at its discretion without 
     including an application model. Some discussion followed about the 
     necessity for the FCP_CONF. Dal Allan saw FCP_CONF as a check point 
     for error recovery. The point was made that the target only proceeds 
     when it has a successful transfer and so the FCP_CONF is unneeded. 
     
     Dave Peterson saw the need for FCP_CONF being with read operations 
     where the target is unaware of whether the host received the data. The 
     host may lose data internally because of an internal error and need to 
     have the data retransferred. He expects the target to keep the read 
     data in its buffer until the FCP_CONF is received. 
     
     Matthew Wakeley, HP, saw FCP_CONF as useful for queued read commands 
     to stop the drive when initiator detects a data error.
     
     The discussion revealed some misunderstandings and enabled the group 
     to get a more consistent view of FCP_CONF. Bob Snively and Dave 
     Peterson will produce a model. A key point is that the FCP_CONF is not 
     to be sent on a read until all of the data is confirmed. Dal Allan 
     asked Dave Peterson to review the model with Rob Bashim. Dave will 
     post the completed model to the reflector.
     
     #3. Public/Private Addressing - Dave Baldwin and Charles Binford noted 
     that the addressing options in the FLA precluded communication between 
     private initiators and public targets. Jim Coomes, Seagate, presented 
     his proposal, to correct this situation. Some discussion followed. It 
     was concluded that public devices should respond to either DD_AA&AL-PA 
     or 00_00&AL-PA. The target always returns frames with its public 
     address in the source ID. Some concern was expressed about whether 
     current implementations can support this requirement. The participants 
     were asked to review their implementations to see if this requirement 
     would break existing solutions. Several of the implementers were 
     uncertain how there applications work.
     
     Brian Smith thought that private devices would ignore the area and 
     domain fields and argued hard to that effect. The remainder of the 
     participants felt that private addresses included the 00_00 in the 
     area and domain fields. 
     
     Jim Coomes's conclusion: All public devices reply to 0000 or DDAA in 
     the area and domain address fields at login. Dave Baldwin's extension: 
     Public device be allowed to interrogate every device with a private 
     address to allow for a consistent address approach during target 
     discovery.
     
     #4. Comments: Stewart Wyatt questioned support for all of the queuing 
     flavors. Some discussion followed but the group did not appear to want 
     to limit them.
     
     Dave took the opportunity to review some more of Bob Snively's 
     comments posted before the previous meeting.
     
     Bob wanted to prohibit half duplex operation - the group preferred 
     that the profile be silent on full and half duplex operation. Bob also 
     wanted to prohibit DHD - A long discussion followed between Bob, Dal 
     and Matthew about the relevance of specifying physical issues. Dave 
     supported Bob. Matthew doesn't want to write a new proposal when new 
     physical features are added to Fibre Channel. (MCM as an example.) Bob 
     felt that these things are necessary for interoperability. Dal pointed 
     out that support for these features can be learned in the login and 
     the profile can be silent on these issues without affecting 
     interoperability.
     
     Discard policy. Voted for a redefined discard multiple policy. Single 
     is prohibited because it would allow the FCP_RSP to be sent up to the 
     upper level when there was missing read data.
     
     ACA handling - required for queuing, prohibited otherwise.
     
     Choice of class 3. Class 3 behavior is mandatory. Class 2 is optional, 
     all others are prohibited.
     
     Continuously increasing sequence count - not supported in first 
     generation Seagate drives, allowed.
     
     9. TapeAlert proposal: T11/98-373v0, Stephen Gold
     TapeAlert presentation: T11/98-412v0 - The overheads Stephen used in 
     this presentation
     
     Stephen presented a brief over of TapeAlert. TapeAlert is a standard 
     method of presenting log data to backup software. It provides clear 
     message that can be presented to the user along with corrective action 
     recommendations. It can also be used in network applications. Examples 
     of reported errors include: cleaning requirements, worn out media, 
     wrong media. The TapeAlert messages are intended to be idiotic proof.
     
     Stephen was asking for SSC support for using the reserved log page 
     0x2E. Dal Allan, ENDL, and Gary Stephens, FSI, responded noting that 
     Stephen should have gotten approval before hand. They thought he would 
     have to make a request to the T10 plenary for inclusion of the log 
     page in the SPC. Dale LaFollette checked the standard and found that 
     this log page was device specific and that the SSC could grant 
     permission to use it. The group agreed to make the assignment in the 
     next draft of the SSC. Dal told Stephen to post a comment to the SMC 
     to get it included in that document also. 
     
     The last item of discussion was whether to seek a letter ballot at the 
     T11.3 plenary the next morning. While the group has made considerable 
     progress, the majority feeling was that we are not ready. The best 
     schedule is to complete the profile by the September meeting and ask 
     the T11 (or T11.3) chair for a letter ballot before the October 
     meeting. 
     
     There was some confusion about whether a letter ballot from T11.3 was 
     sufficient to go for public review or if T11 would also have to have a 
     letter ballot. Dal Allan was of the feeling that if T11 required a 
     letter ballot to skip the T11.3 letter ballot. 
     
     10. T10 New Business: None
     
     11. T11 New Business: None
     
     12. Review new action items: Stewart Wyatt
     
     #1. Dave Baldwin, revise ABTS proposal, compare the ABTS Status Check 
     to the REC to see if any additional functionality is provided, obtain 
     a document number, post updated proposal to the reflector.
     #2. Brian Smith, Crossroads, review media changer commands.
     #3. Stewart Wyatt to post a copy of the TapeAlert presentation
     #4. Dave Peterson to include TapeAlert in the next SSC draft which is 
     estimated to be completed by the November T10 meeting.
     #4. Stephen Golding to post a comment to SMC for inclusion of 
     TapeAlert.
     #5. Dave Peterson and Bob Snively will produce a model of FCP_CONF. 
     Dave will review it with Rob Bashim. Dave will post the model to the 
     reflector. 
     #6. Relevant participants: Investigate capability of existing Fibre 
     Channel solutions to respond to both DDAA&ALPA and 0000&ALPA after 
     login. 
     #7. Rich Toborek/Dal Allan is FC-TAPE what letter ballots are required 
     before the FC-TAPE proposal can go for public review.
     
     13. Adjournment: 10 PM

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