From support at terabyteunlimited.com  Thu Jun  1 00:58:24 2006
From: support at terabyteunlimited.com (David F.)
Date: Thu, 1 Jun 2006 00:58:24 -0700
Subject: Set Streaming
Message-ID: <mailman.492.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606010_f.htm">HTML-formatted message</A>

Hello,
It would nice to allow the "End LBA" field for Set Streaming Type=0 to use
0xFFFFFFFF as a documented value to ensure compatibility between all drives.
--
David F.
TeraByte Unlimited
http://www.terabyteunlimited.com
This email and any attachments are intended solely for the individual or
entity to which it is addressed.  If you have received this email in error,
please reply immediately to the sender that you have received the email in
error and permanently delete it.  If you are not the intended recipient, any
disclosure, copying, distribution, or use of the contents of this
information is prohibited.    


From Wayne.Bellamy at hp.com  Thu Jun  1 13:39:45 2006
From: Wayne.Bellamy at hp.com (Bellamy, Wayne)
Date: Thu, 1 Jun 2006 15:39:45 -0500
Subject: SAT June 7,8 in Phoenix (RSVP Please)
Message-ID: <mailman.493.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606011_f.htm">HTML-formatted message</A>

In response to the RSVP: 
I plan to attend, also.
wayne
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Sheffield, Robert L
Sent: Tuesday, May 23, 2006 11:20 AM
To: t10 at t10.org
Subject: SAT June 7,8 in Phoenix (RSVP Please)
Hi all,
I have reserved a conference room in the Park Plaza Hotel June 7 and 8
for a face-to-face SCSI/ATA Translation working group meeting to work
through the last of the SAT letter-ballot comments (see announcement:
http://www.t10.org/ftp/t10/sat-ann.pdf).
By word of mouth, however, it's starting to look like the meeting may
not be very well attended. I have had several regular participants tell
me they do not intend to attend, and others have said they don't want to
incur the travel expense unless some of the key attendees are there to
help resolve the 90 or so LB comments that remain.
So, please RSVP and let me know if you plan on attending. I will use the
RSVP replies to determine whether it is worth holding the meeting or
not. I understand there are a handful of you who already have your plane
tickets booked, but if it's not going to be a productive meeting, I have
trouble justifying Intel's expense to host the meeting.
I really would like to use this June meeting to come as close as
possible to resolving the last of the LB comments so we can ask for a
vote to forward to INCITS in July and move forward with SAT-2.
Please RSVP to the reflector, or to my e-mail (on the T10 website).
Best regards,
Bob Sheffield (your humble SAT edtior)


From michael.banther at hp.com  Fri Jun  2 01:48:35 2006
From: michael.banther at hp.com (Banther, Michael)
Date: Fri, 2 Jun 2006 09:48:35 +0100
Subject: SMC-3 teleconference
Message-ID: <mailman.494.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606020_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0606020_banther_michael.vcf">banther_michael.vcf</A>
Attachment #2: <A HREF="r0606020_smc_2006-06-05_agenda.pdf">smc_2006-06-05_agenda.pdf</A>

The SMC-3 working group will hold an ad-hoc teleconference on Monday, 5
June 2006 beginning at 8:00 AM PDT and concluding at 10:00 AM PDT.  You
can find the agenda, along with contact details, in the attached PDF.
Regards,
Michael Banther
Hewlett-Packard Ltd.
+44 117 312 9503


From lohmeyer at t10.org  Sat Jun  3 23:00:47 2006
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 4 Jun 2006 00:00:47 -0600
Subject: Recent T10 documents uploaded since 2006/05/28
Message-ID: <mailman.495.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SAT - Fix Task Management Functions
(by: Robert Sheffield)
T10/06-179r1   Uploaded: 2006/06/02   53566 bytes
ftp://ftp.t10.org/t10/document.06/06-179r1.pdf
SAS-2: Reporting ZONE PARTICIPATING CAPABLE in the IDENTIFY address
frame
(by: Kevin Marks)
T10/06-210r1   Uploaded: 2006/06/01   53602 bytes
ftp://ftp.t10.org/t10/document.06/06-210r1.pdf
SAT - Example configurations
(by: Robert Sheffield)
T10/06-262r0   Uploaded: 2006/05/30   36915 bytes
ftp://ftp.t10.org/t10/document.06/06-262r0.pdf
SAT - Example configurations
(by: Robert Sheffield)
T10/06-262r1   Uploaded: 2006/06/01   40525 bytes
ftp://ftp.t10.org/t10/document.06/06-262r1.pdf
SAS-2 Spread-spectrum clocking by upspreading
(by: Rob Elliott)
T10/06-263r0   Uploaded: 2006/05/31   40991 bytes
ftp://ftp.t10.org/t10/document.06/06-263r0.pdf
SPC-4 REQUEST SENSE parameter data clarifications
(by: Rob Elliott)
T10/06-264r0   Uploaded: 2006/06/02   33582 bytes
ftp://ftp.t10.org/t10/document.06/06-264r0.pdf
Minutes: May 31 Conference Call
(by: Kevin Butt)
T10/06-265r0   Uploaded: 2006/05/31   44636 bytes
ftp://ftp.t10.org/t10/document.06/06-265r0.pdf
Minutes of SAS Physical Working Group teleconference, June 1, 2006
(by: Alvin Cox)
T10/06-266r0   Uploaded: 2006/06/01   23225 bytes
ftp://ftp.t10.org/t10/document.06/06-266r0.pdf
SAS-2 Spread Spectrum Clocking Options
(by: Kevin Witt, Greg Tabor, Adrian Robinson)
T10/06-267r0   Uploaded: 2006/06/01   256036 bytes
ftp://ftp.t10.org/t10/document.06/06-267r0.pdf
Agenda for SMC-3 Conference Call - June 5, 2006
(by: Greg Wheeless)
T10/06-268r0   Uploaded: 2006/06/02   4279 bytes
ftp://ftp.t10.org/t10/document.06/06-268r0.pdf
Working Drafts
--------------
(Report generated on 2006/06/04 at 00:00:46)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Mon Jun  5 09:55:41 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Mon, 05 Jun 2006 10:55:41 -0600
Subject: July hotel reservations
Message-ID: <mailman.496.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
Some people have had difficulty making their room reservations for the July
T10 meetings in Colorado Springs using the on-line reservation form. If you
are having trouble, please call the Hilton reservations phone number
(1-800-HILTONS) and give them the group code LSI709.
The room block is filled on Sunday night July 9th (but there are some
non-block rooms), so if you are arriving Sunday you will need to call the
reservations phone number.
The cutoff date is this Friday, June 9th. Procrastinators, now is the time!
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Mignon.M.Fernandez at bitmicro.com  Tue Jun  6 02:57:48 2006
From: Mignon.M.Fernandez at bitmicro.com (Mignon Fernandez)
Date: Tue, 6 Jun 2006 17:57:48 +0800
Subject: SAS wide init/targ command transfers
Message-ID: <mailman.497.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606060_f.htm">HTML-formatted message</A>

Hello,

Based on how I understand the spec (sas1r10), it is possible for a wide
Initiator and a wide Target to have simultaneous connections with each
other on different PHYs.

For this scenario (a wide initiator having multiple simultaneous
connections with a wide target), I could not find the info in the spec
the rules or the restrictions of command transfer/processing (e.g. if
only simple commands can be transmitted etc..). Can there be a case
where a wide initiator sends an ordered command on one phy and another
ordered command on another phy to the same wide Target?

Thanks in advance,
Mignon Fernandez
<please ignore disclaimer>
------------------------------------------------------------
CONFIDENTIALITY NOTICE

This email and any attached documents may be confidential
and property of BiTMICRO Networks, Inc. If you are not the

intended recipient, you may not disclose, copy, distribute,
or act in reliance on the information in this email.
Also note, this email and attached documents are scanned for

the presence of virus.	Changes made to this email after it



From monika.talwar at nsysinc.com  Tue Jun  6 06:05:08 2006
From: monika.talwar at nsysinc.com (Mona)
Date: Tue, 06 Jun 2006 18:35:08 +0530
Subject: Queries : Transport layer
Message-ID: <mailman.498.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Mona <monika.talwar at nsysinc.com>
*
I have some doubts . I am referring SAS Revision 3a, released on 22 
April 2006
Following are the queries :
1.In the ST_IFR state machine it has been stated on page 383(section
9.2.6.2.2.2)that 
"If the ST_ITS state machine for the tag specified in the Send Task
Management Request is currently in use,then this state machine shall set
the retransmit bit argument to one. If the ST_ITS state machine for the
tag specified in the Send Task Management Request is not currently in
use, then this state machine shall set the Retransmit Bit argument to
zero."
 I am not able to figure out which scenario is being talked out here. As per
my understanding, ST_ITS state-machine is busy when 
ST_IFR assigns it any task. After ST_ITS state machine sends Transmission
status(nak or ack/nak time-out etc) to ST_IFR state machine,
the ST_ITS state machine corresponding to that tag becomes free. Moreover, Is
there any static binding b/w ST_ITS state machine and TAG,
or that ST_IFR can allocate any state-machine when TASK/COMMAND request
arrives? I am concerned if I have missed something. 
2.Is CDB field's contents are visible to transport layer?
If no then how does Transport layer comes to know whether the COMMAND is a
read command or write command.
If Yes, then why does data size need to be specified exclusively in the
Execute Command request from Application layer when 
TRANSFER LENGTH/PARAMETER LIST LENGTH/ALLOCATION LENGTH are there in CDB to
specify the size of the data.
-- 
--------------------------------------------
Best regards
Sandeep Taneja
nSys Design systems
Accelerating designs
http://www.nsysinc.com
91-11-27354820 (Ext.241)
1-510-402-4544(VOIP)
--------------------------------------------
-- 
----------------------------------
Best regards
Mona
nSys
http://www.nsysinc.com
Accelerating designs
+1-510-402-4544
----------------------------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From wasim.sabir at gmail.com  Tue Jun  6 09:02:29 2006
From: wasim.sabir at gmail.com (Wasim Sabir)
Date: Tue, 6 Jun 2006 21:02:29 +0500
Subject: Set DVD Speed?
Message-ID: <mailman.499.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Wasim Sabir" <wasim.sabir at gmail.com>
*
Dear All,
We have a command in specifications as "SET CD SPEED" to select a
preferred physical speed foe CD media. Is there any such command
available for DVD media?
-- 
With kind regards,
Wasim Sabir
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Gary.Franco at Emulex.Com  Tue Jun  6 09:23:56 2006
From: Gary.Franco at Emulex.Com (Gary.Franco at Emulex.Com)
Date: Tue, 6 Jun 2006 09:23:56 -0700
Subject: Relative offset calculation with data protection enabled
Message-ID: <mailman.500.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606063_f.htm">HTML-formatted message</A>

All,
I have been trying to find some statement in the various documents
defining data protection, SPC/SBC and have yet to find anything
discussing relative offset generation with a data protection enabled
device or initiator.
Is the relative offset field still generated on 512 byte blocks and the
DIF field just an opaque object that we have to deal with?
When a check and translate function is requested (DIF embedded in the
data-in or data-out buffer) does the above still hold true?
If you know where I can find this information I would appreciate a
reply.
__________________________________
Gary Franco Consultant Engineer 
Emulex Network Systems 
972-671-7433 Dallas Office
972-671-7435 Dallas Office Fax 
720-652-6387 Longmont Colorado Office 
720-494-1817 Longmont Colorado Office Fax
972-839-5694 Cell Phone
Today's Quote 
It is not the cards you are dealt but what you do with them that counts.
-Anonymous
This message contains confidential information of Emulex Corporation
intended only for listed recipients and should not be forwarded to
anyone else.  
If you have received this message in error, please delete it
immediately.  Thank you. 


From Elliott at hp.com  Tue Jun  6 11:16:39 2006
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Tue, 6 Jun 2006 13:16:39 -0500
Subject: Relative offset calculation with data protection enabled
Message-ID: <mailman.501.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606064_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0606064_smime.p7s">smime.p7s</A>

Protection information is a SCSI Block command set concept.  The Fibre
Channel and FCP layers just transfer bytes for the SCSI layer.	They don't
know if the command they are carrying is block-based or not, what the block
size is, or even what a "block" is.  Some SCSI command sets like OSD (object
storage) and SSC (tapes) have totally different concepts of the granularity
of media accesses than SBC (disks).  So, the Parameter field in the FCP
frame header, which serves as a Relative Offset field for FCP_DATA IUs, is
based on the number of bytes actually transferred (e.g., 520 bytes per
block) not the amount of user data (e.g., 512 bytes per block).
-- 
Rob Elliott, elliott at hp.com 
Hewlett-Packard Industry Standard Server Storage Advanced Technology 
https://ecardfile.com/id/RobElliott 
  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Gary.Franco at emulex.com
Sent: Tuesday, June 06, 2006 11:24 AM
To: t10 at t10.org
Subject: Relative offset calculation with data protection enabled
All,
I have been trying to find some statement in the various documents defining
data protection, SPC/SBC and have yet to find anything discussing relative
offset generation with a data protection enabled device or initiator.
Is the relative offset field still generated on 512 byte blocks and the DIF
field just an opaque object that we have to deal with?
When a check and translate function is requested (DIF embedded in the
data-in or data-out buffer) does the above still hold true?
If you know where I can find this information I would appreciate a reply.
__________________________________
Gary Franco Consultant Engineer 
Emulex Network Systems 
972-671-7433 Dallas Office
972-671-7435 Dallas Office Fax 
720-652-6387 Longmont Colorado Office 
720-494-1817 Longmont Colorado Office Fax
972-839-5694 Cell Phone
Today's Quote 
It is not the cards you are dealt but what you do with them that counts.
-Anonymous
This message contains confidential information of Emulex Corporation
intended only for listed recipients and should not be forwarded to anyone
else.  
If you have received this message in error, please delete it immediately.
Thank you. 


From Elliott at hp.com  Tue Jun  6 12:00:22 2006
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Tue, 6 Jun 2006 14:00:22 -0500
Subject: SAS wide init/targ command transfers
Message-ID: <mailman.502.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606065_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0606065_smime.p7s">smime.p7s</A>

There are some restrictions in 8.2.2.3.6 PL_OC2:Over_Control state frame
transmission for task management functions. A SAS port does not send a task
management function that might affect a command that is in flight.
There is no specific advice about waiting to send commands that may affect
or depend on other commands that are also in-flight.  This includes:
- command with the ORDERED or HEAD OF QUEUE task attribute
- PERSISTENT RESERVE OUT command with the PREEMPT AND ABORT service action
(aborts tasks already in the task set, if they've arrived yet)
If you send one of these in a connection before the ACK was received for the
previous command (in its connection), there is no guarantee which one the
device server will receive first.
Since a narrow port or a wide ports in only one connection at a time to
another port already preserves ordering (due to the interlocked frame
transmission rules), it's probably best for SAS-2 to include rules for these
cases for wide ports with multiple connections to other wide ports as well.
-- 
Rob Elliott, elliott at hp.com 
Hewlett-Packard Industry Standard Server Storage Advanced Technology 
https://ecardfile.com/id/RobElliott 
  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mignon
Fernandez  
Sent: Tuesday, June 06, 2006 4:58 AM
To: t10 at t10.org
Subject: SAS wide init/targ command transfers
Hello, 
Based on how I understand the spec (sas1r10), it is possible for a wide
Initiator and a wide Target to have simultaneous connections with each other
on different PHYs. 
For this scenario (a wide initiator having multiple simultaneous connections
with a wide target), I could not find the info in the spec the rules or the
restrictions of command transfer/processing (e.g. if only simple commands
can be transmitted etc..). Can there be a case where a wide initiator sends
an ordered command on one phy and another ordered command on another phy to
the same wide Target? 
Thanks in advance,
Mignon Fernandez


From matt.ball at quantum.com  Tue Jun  6 16:49:56 2006
From: matt.ball at quantum.com (Matt Ball)
Date: Tue, 6 Jun 2006 17:49:56 -0600
Subject: SSC-3: 06-225r2 now available (AES Key-wrap for establishing an encryption key)
Message-ID: <mailman.503.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606066_f.htm">HTML-formatted message</A>

Hi All,
I just uploaded 06-225r2 to the T10 site.  Please forward this document to
any cryptography people in your organization.  If possible, I'd like to vote
on including this proposal into SSC-3 at the next SSC-3 teleconference on
June 21st.  If nothing else, we should be able to include the changes from
clause 8.
Thanks!
-Matt


From keiji_katata at post.pioneer.co.jp  Tue Jun  6 19:35:37 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Wed, 7 Jun 2006 11:35:37 +0900
Subject: Fuji meeting announcement & July hotel reservations
Message-ID: <mailman.504.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
Fuji meeting will be held at July 10 and 11 at T10 meeting place.
Mr. John Lohmeyer kindly prepares a meeting room for Fuji group.
Here is the July T10 hotel information.
Please make your reservation as soon as possible.
Best regards,
Keiji Katata
PIONEER CORP.
---------------------- $BE>Aw<T(B: Keiji Katata/Pioneer $BE>AwF|(B:
2006/06/07 11:31
---------------------------
John Lohmeyer <lohmeyer at t10.org>@t10.org on 2006/06/06 01:55:41
$BAw?.<T(B:	  owner-t10 at t10.org
$B08 at h(B:  T10 Reflector <t10 at t10.org>
cc:
bcc:
$B7oL>(B:  July hotel reservations
* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
Some people have had difficulty making their room reservations for the July
T10
meetings in Colorado Springs using the on-line reservation form. If you are
having trouble, please call the Hilton reservations phone number
(1-800-HILTONS)
and give them the group code LSI709.
The room block is filled on Sunday night July 9th (but there are some
non-block
rooms), so if you are arriving Sunday you will need to call the reservations
phone number.
The cutoff date is this Friday, June 9th. Procrastinators, now is the time!
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Wed Jun  7 07:44:45 2006
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 7 Jun 2006 07:44:45 -0700
Subject: SSC-3: 06-225r2 now available (AES Key-wrap for establishing an
 encryption key)
Message-ID: <mailman.505.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606070_f.htm">HTML-formatted message</A>

Matt & all,
I want to voice my concern about trying to approve for inclusion into 
SSC-3 this proposal without first having an approved method of 
establishing an SA in SPC-4.  It seems bad to approve something that 
relies on a nonexistent method.  I know that David Black is working on his 
proposal 06-103 SSC-3: Encrypt keys for transfer to device as well as 
possibly taking some of the original parts of 06-225r1 and targeting them 
for SPC-4.  However, this has barely started and nothing in SPC-4 provides 
a method to establish an SA yet.  The result of this, I believe, is that 
SSC-3 will be held out of letter ballot until a method to establish an SA 
is included into SPC-4 and SPC-4 passes letter ballot. 
Dave,
Please add a discussion of this email to the agenda for the next SSC-3 
meeting (i.e. June 21 Telecon).
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Matt Ball" <matt.ball at quantum.com> 
Sent by: owner-t10 at t10.org
06/06/2006 04:49 PM
To
"T10 Reflector" <t10 at t10.org>
cc
Subject
SSC-3: 06-225r2 now available (AES Key-wrap for establishing an encryption 
key)
Hi All,
I just uploaded 06-225r2 to the T10 site.  Please forward this document to 
any cryptography people in your organization.  If possible, I'd like to 
vote on including this proposal into SSC-3 at the next SSC-3 
teleconference on June 21st.  If nothing else, we should be able to 
include the changes from clause 8.
Thanks!
-Matt


From roweber at IEEE.org  Wed Jun  7 09:09:26 2006
From: roweber at IEEE.org (Ralph Weber)
Date: Wed, 07 Jun 2006 11:09:26 -0500
Subject: SSC-3: 06-225r2 now available (AES Key-wrap for establishing
 an encryption key)
Message-ID: <mailman.506.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Kevin,
I fail to follow this concern.
The revision of SSC-2 which was sent to Public Review contains a
reference to SPC-3. SPC-3 did not enter Letter Ballot until 16
months after SSC-2 was sent to Public Review (July 2003 to
November 2004).
Either SSC-3 is being held to an unusually high standard, or the
Letter Ballot status of SPC-4 is not an SSC-3 gating item.
To me, it looks like the SPC-4 SA Establishment protocol needs
to be incorporated in SPC-4 before SSC-3 goes to Letter Ballot in
May 2007. If this is the case, then worrying about the matter at
this juncture seems very premature.
All the best,
.Ralph
Kevin D Butt wrote:
>
> Matt & all,
>
> I want to voice my concern about trying to approve for inclusion into 
> SSC-3 this proposal without first having an approved method of 
> establishing an SA in SPC-4.	It seems bad to approve something that 
> relies on a nonexistent method.  I know that David Black is working on 
> his proposal 06-103 SSC-3: Encrypt keys for transfer to device as well 
> as possibly taking some of the original parts of 06-225r1 and 
> targeting them for SPC-4.  However, this has barely started and 
> nothing in SPC-4 provides a method to establish an SA yet.  The result 
> of this, I believe, is that SSC-3 will be held out of letter ballot 
> until a method to establish an SA is included into SPC-4 and SPC-4 
> passes letter ballot.
>
> Dave,
>
> Please add a discussion of this email to the agenda for the next SSC-3 
> meeting (i.e. June 21 Telecon).
>
> Thanks,
>
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-2869 / 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/
>
>
> *"Matt Ball" <matt.ball at quantum.com>*
> Sent by: owner-t10 at t10.org
>
> 06/06/2006 04:49 PM
>
>	
> To
>	"T10 Reflector" <t10 at t10.org>
> cc
>	
> Subject
>	SSC-3: 06-225r2 now available (AES Key-wrap for establishing an 
> encryption key)
>
>
>
>	
>
>
>
>
>
> Hi All,
>  
> I just uploaded 06-225r2 to the T10 site.  Please forward this 
> document to any cryptography people in your organization.  If 
> possible, I'd like to vote on including this proposal into SSC-3 at 
> the next SSC-3 teleconference on June 21st.  If nothing else, we 
> should be able to include the changes from clause 8.
>  
> Thanks!
> -Matt
>  
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From monika.talwar at nsysinc.com  Wed Jun  7 22:12:17 2006
From: monika.talwar at nsysinc.com (Mona)
Date: Thu, 08 Jun 2006 10:42:17 +0530
Subject: SAS Transport layer- ST_IFR/ST_ITS State machines
Message-ID: <mailman.507.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606080_f.htm">HTML-formatted message</A>

Hello !! 
Could anybody please clear my doubts in SAS transport layer!!
<>I have some doubts . I am referring SAS Revision 3a, released on 22 April
2006
<>Following are the queries :
1.In the ST_IFR state machine it has been stated on page 383(section
9.2.6.2.2.2)that 
"If the ST_ITS state machine for the tag specified in the Send Task
Management Request is currently in use,then this state machine shall set
the retransmit bit argument to one. If the ST_ITS state machine for the
tag specified in the Send Task Management Request is not currently in
use, then this state machine shall set the Retransmit Bit argument to
zero."
I am not able to figure out which scenario is being talked out here. As per
my understanding, ST_ITS state-machine is busy when 
ST_IFR assigns it any task. After ST_ITS state machine sends Transmission
status(nak or ack/nak time-out etc) to ST_IFR state machine,
the ST_ITS state machine corresponding to that tag becomes free. Moreover, Is
there any static binding b/w ST_ITS state machine and TAG,
or that ST_IFR can allocate any state-machine when TASK/COMMAND request
arrives? I am concerned if I have missed something. 
2.Is CDB field's contents are visible to transport layer?
If no then how does Transport layer comes to know whether the COMMAND is a
read command or write command.
If Yes, then why does data size need to be specified exclusively in the
Execute Command request from Application layer when 
TRANSFER LENGTH/PARAMETER LIST LENGTH/ALLOCATION LENGTH are there in CDB to
specify the size of the data.
-- 
----------------------------------
Best regards
Mona
nSys
http://www.nsysinc.com
Accelerating designs
+1-510-402-4544
----------------------------------
-- 
----------------------------------
Best regards
Mona
nSys
http://www.nsysinc.com
Accelerating designs
+1-510-402-4544
----------------------------------


From keiji_katata at post.pioneer.co.jp  Wed Jun  7 23:49:38 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 8 Jun 2006 15:49:38 +0900
Subject: Set DVD Speed?
Message-ID: <mailman.508.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hi Wasim,
Set CD Speed may not work for DVD, HD-DVD and BD. Applying to other than CD
is
vender specific.
This is the reason why it is not Set DVD Speed.
Best regards,
Keiji Katata
PIONEER CORP.
"Wasim Sabir" <wasim.sabir at gmail.com>@t10.org on 2006/06/07 01:02:29
$BAw?.<T(B:	  owner-t10 at t10.org
$B08 at h(B:  t10 at t10.org
cc:
bcc:
$B7oL>(B:  Set DVD Speed?
* From the T10 Reflector (t10 at t10.org), posted by:
* "Wasim Sabir" <wasim.sabir at gmail.com>
*
Dear All,
We have a command in specifications as "SET CD SPEED" to select a
preferred physical speed foe CD media. Is there any such command
available for DVD media?
--
With kind regards,
Wasim Sabir
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From takeshi_kohda at post.pioneer.co.jp  Thu Jun  8 00:56:14 2006
From: takeshi_kohda at post.pioneer.co.jp (takeshi_kohda at post.pioneer.co.jp)
Date: Thu, 8 Jun 2006 16:56:14 +0900
Subject: June Mt. Fuji meeting minutes
Message-ID: <mailman.509.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* takeshi_kohda at post.pioneer.co.jp
*
June Mt. Fuji meeting minutes have posted on the fuji ftp site.
ftp://ftp.avc-pioneer.com/Mtfuji_7/Minutes/MinJun06.pdf
Distributed documents in the meeting have placed in:
ftp://ftp.avc-pioneer.com/Mtfuji_7/Proposal/Jun06/
Best regards,
---
Takeshi Kohda
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Kris.Schoofs at pmtc.be  Wed Jun  7 23:09:04 2006
From: Kris.Schoofs at pmtc.be (Kris.Schoofs at pmtc.be)
Date: Thu, 8 Jun 2006 08:09:04 +0200
Subject: Set DVD Speed?
Message-ID: <mailman.510.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Kris.Schoofs at pmtc.be
*
Hi,
You should use the SET STREAMING command.
Regards,
Kris
"Wasim Sabir" <wasim.sabir at gmail.com>
Sent by: owner-t10 at t10.org
06/06/2006 18:02
	To:	t10 at t10.org
	cc: 
	Subject:	Set DVD Speed?
* From the T10 Reflector (t10 at t10.org), posted by:
* "Wasim Sabir" <wasim.sabir at gmail.com>
*
Dear All,
We have a command in specifications as "SET CD SPEED" to select a
preferred physical speed foe CD media. Is there any such command
available for DVD media?
-- 
With kind regards,
Wasim Sabir
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Mark_Evans at maxtor.com  Thu Jun  8 10:07:52 2006
From: Mark_Evans at maxtor.com (Evans, Mark)
Date: Thu, 8 Jun 2006 10:07:52 -0700
Subject: SAS Transport layer- ST_IFR/ST_ITS State machines
Message-ID: <mailman.511.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606084_f.htm">HTML-formatted message</A>

Hi Monika,
For question 1:  I think there probably should be some more words in the
description in 9.2.6.2.2.2 clarifying that, in this case, the last
action by the ST_ITS state machine was sending a Transmission Complete
(Task Failed x) to the ST_IFR state machine for the frame transmitted
for the previous Send Task Management Request.	The fact that an error
occured during transmission of the previous frame is context maintained
by the	ST_ITS state machine.  The additional words could be something
like, "If the ST_ITS state machine for the tag specified in the Send
Task Management Request is currently in use (i.e., a this state sent a
Transmission Status (Task Failed x) to the ST_IFR state machine for the
previous Transmit Frame request), ..."
For question 2:  There is a little SCSI magic going on here.  The
initiator transport layer MAY look at the CDB, but that isn't required.
The Send SCSI Command request contains either a Data-In Buffer Size or a
Data-Out Buffer Size.  This is all that's required to specify whether
the command requires data transfer and, if so, in which direction.
Therefore, the data size is specified.
Regards,
Mark Evans 
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mona
Sent: Wednesday, June 07, 2006 10:12 PM
To: t10 at t10.org
Subject: SAS Transport layer- ST_IFR/ST_ITS State machines
Hello !! 
Could anybody please clear my doubts in SAS transport layer!!
<>I have some doubts . I am referring SAS Revision 3a, released on 22
April 2006</>
<></>Following are the queries :
1.In the ST_IFR state machine it has been stated on page 383(section
9.2.6.2.2.2)that 
"If the ST_ITS state machine for the tag specified in the Send Task
Management Request is currently in use,then this state machine shall set
the retransmit bit argument to one. If the ST_ITS state machine for the
tag specified in the Send Task Management Request is not currently in
use, then this state machine shall set the Retransmit Bit argument to
zero."
I am not able to figure out which scenario is being talked out here. As
per my understanding, ST_ITS state-machine is busy when 
ST_IFR assigns it any task. After ST_ITS state machine sends
Transmission status(nak or ack/nak time-out etc) to ST_IFR state
machine,
the ST_ITS state machine corresponding to that tag becomes free.
Moreover, Is there any static binding b/w ST_ITS state machine and TAG,
or that ST_IFR can allocate any state-machine when TASK/COMMAND request
arrives? I am concerned if I have missed something. 
2.Is CDB field's contents are visible to transport layer?
If no then how does Transport layer comes to know whether the COMMAND is
a read command or write command.
If Yes, then why does data size need to be specified exclusively in the
Execute Command request from Application layer when 
TRANSFER LENGTH/PARAMETER LIST LENGTH/ALLOCATION LENGTH are there in CDB
to specify the size of the data.
-- 
----------------------------------
Best regards
Mona
nSys
http://www.nsysinc.com
Accelerating designs
+1-510-402-4544
----------------------------------
-- 
----------------------------------
Best regards
Mona
nSys
http://www.nsysinc.com
Accelerating designs
+1-510-402-4544
----------------------------------


From Walt.Hubis at lsil.com  Thu Jun  8 09:43:46 2006
From: Walt.Hubis at lsil.com (Hubis, Walt)
Date: Thu, 8 Jun 2006 10:43:46 -0600
Subject: SPC-4: Persistent Reserve Out Confusion
Message-ID: <mailman.512.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Hubis, Walt" <Walt.Hubis at lsil.com>
*
In SPC4-04, Section 5.6.6 "Registering", Table 34 "Register behaviors
for a REGISTER AND IGNORE EXISTING KEY service action", anytime the
SERVICE ACTION RESERVATION KEY is non-zero and SPEC_I_PT is set to one,
a CHECK CONDITION status is to be generated. But in section 6.12.3
"Basic PERSISTENT RESERVE OUT parameter list" states:
"If the SPEC_I_PT bit is set to one for the REGISTER service action or
the REGISTER AND IGNORE EXISTING KEY service action, then the additional
parameter data shall include a list of transport IDs (see table 116) and
the device server shall also apply the registration to the I_T nexus for
each initiator port specified by a TransportID. If a registration fails
for any initiator port(e.g., if the logical unit does not have enough
resources available to hold the registration information), none of the
other registrations shall be made."
This seems to be a contradiction - what am I missing here?
Cheers,
Walt
---
Walt Hubis walt.hubis at lsil.com  
Software Architect
Engenio Storage Group
LSI Logic Corporation
5400 Airport Blvd Ste 100
Boulder, Colorado 80301  USA
Phone: (303) 381-4332
www.lsilogic.com/engenio
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Elliott at hp.com  Thu Jun  8 11:19:46 2006
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Thu, 8 Jun 2006 13:19:46 -0500
Subject: SPC-4: Persistent Reserve Out Confusion
Message-ID: <mailman.513.1441607308.22510.t10@sandbox.t10.org>

Attachment #1: <A HREF="r0606086_smime.p7s">smime.p7s</A>

SPEC_I_PT used to work with REGISTER AND IGNORE EXISTING KEY, but that
combination was removed by the REGISTER AND MOVE service action proposal
03-337 (apparently incompletely).  SPC-3 letter ballot comments to reinstate
it were rejected, saying a detailed proposal would be needed to make such a
change in SPC-4.
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf 
> Of Hubis, Walt
> Sent: Thursday, June 08, 2006 11:44 AM
> To: t10 at t10.org
> Subject: SPC-4: Persistent Reserve Out Confusion
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Hubis, Walt" <Walt.Hubis at lsil.com>
> *
> In SPC4-04, Section 5.6.6 "Registering", Table 34 "Register behaviors
> for a REGISTER AND IGNORE EXISTING KEY service action", anytime the
> SERVICE ACTION RESERVATION KEY is non-zero and SPEC_I_PT is 
> set to one,
> a CHECK CONDITION status is to be generated. But in section 6.12.3
> "Basic PERSISTENT RESERVE OUT parameter list" states:
> 
> "If the SPEC_I_PT bit is set to one for the REGISTER service action or
> the REGISTER AND IGNORE EXISTING KEY service action, then the 
> additional
> parameter data shall include a list of transport IDs (see 
> table 116) and
> the device server shall also apply the registration to the 
> I_T nexus for
> each initiator port specified by a TransportID. If a 
> registration fails
> for any initiator port(e.g., if the logical unit does not have enough
> resources available to hold the registration information), none of the
> other registrations shall be made."
> 
> This seems to be a contradiction - what am I missing here?
> 
> Cheers,
> Walt
>  
> ---
>  
> Walt Hubis walt.hubis at lsil.com  
> Software Architect
> Engenio Storage Group
>  
> LSI Logic Corporation
> 5400 Airport Blvd Ste 100
> Boulder, Colorado 80301  USA
> Phone: (303) 381-4332
> www.lsilogic.com/engenio
>  
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 


From lohmeyer at t10.org  Sat Jun 10 23:00:55 2006
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 11 Jun 2006 00:00:55 -0600
Subject: Recent T10 documents uploaded since 2006/06/04
Message-ID: <mailman.514.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SPC-4 Wrapping and saturating counter definitions
(by: Rob Elliott)
T10/06-175r1   Uploaded: 2006/06/09   73423 bytes
ftp://ftp.t10.org/t10/document.06/06-175r1.pdf
SAS-2 Self-configuring expander status
(by: Rob Elliott)
T10/06-187r1   Uploaded: 2006/06/10   58868 bytes
ftp://ftp.t10.org/t10/document.06/06-187r1.pdf
SAS-2 Add expander change count to all SMP functions
(by: Rob Elliott)
T10/06-197r2   Uploaded: 2006/06/05   135512 bytes
ftp://ftp.t10.org/t10/document.06/06-197r2.pdf
SAS-2 Restrict access to SMP write functions
(by: Rob Elliott)
T10/06-208r1   Uploaded: 2006/06/05   29534 bytes
ftp://ftp.t10.org/t10/document.06/06-208r1.pdf
SSC-3: Using NIST AES Key-Wrap for Key Establishment
(by: Matt Ball)
T10/06-225r2   Uploaded: 2006/06/06   120755 bytes
ftp://ftp.t10.org/t10/document.06/06-225r2.pdf
SPC-4 REQUEST SENSE parameter data clarifications
(by: Rob Elliott)
T10/06-264r1   Uploaded: 2006/06/06   33982 bytes
ftp://ftp.t10.org/t10/document.06/06-264r1.pdf
SAT - ATA resets and ATA nexus Loss
(by: Robert Sheffield)
T10/06-270r0   Uploaded: 2006/06/04   25223 bytes
ftp://ftp.t10.org/t10/document.06/06-270r0.pdf
spc4r04 editorial nits
(by: Rob Elliott)
T10/06-271r0   Uploaded: 2006/06/05   89954 bytes
ftp://ftp.t10.org/t10/document.06/06-271r0.pdf
SAS2:  Bus Inactivity Timeout Timer Is Broken
(by: Stephen Finch)
T10/06-273r0   Uploaded: 2006/06/05   9704 bytes
ftp://ftp.t10.org/t10/document.06/06-273r0.pdf
SPC-4 SBC-3 REQUEST SENSE and Stopped power condition
(by: Rob Elliott)
T10/06-274r0   Uploaded: 2006/06/09   36165 bytes
ftp://ftp.t10.org/t10/document.06/06-274r0.pdf
T10 Annual Report for 2005
(by: John Lohmeyer)
T10/06-276r0   Uploaded: 2006/06/08   11482 bytes
ftp://ftp.t10.org/t10/document.06/06-276r0.htm
T10 Annual Report for 2005
(by: John Lohmeyer)
T10/06-276r0   Uploaded: 2006/06/08   113836 bytes
ftp://ftp.t10.org/t10/document.06/06-276r0.pdf
SPC-4 Fix persistence of SET DEVICE IDENTIFIER
(by: Paul Entzel)
T10/06-278r0   Uploaded: 2006/06/08   14123 bytes
ftp://ftp.t10.org/t10/document.06/06-278r0.pdf
Working Drafts
--------------
SCSI Primary Commands - 4 (SPC-4)
(Editor: Ralph Weber)
 Rev: 05       Uploaded: 2006/06/10   5219919 bytes
ftp://ftp.t10.org/t10/drafts/spc4/spc4r05.pdf
(Report generated on 2006/06/11 at 00:00:54)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Sun Jun 11 12:04:38 2006
From: roweber at IEEE.org (Ralph Weber)
Date: Sun, 11 Jun 2006 14:04:38 -0500
Subject: SPC-4 r05 is available
Message-ID: <mailman.515.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
SPC-4 r05 has been uploaded as:
  http://www.t10.org/ftp/t10/drafts/spc4/spc4r05.pdf
It includes all approved proposals, including the concluding
log subpage documents.
Enjoy,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Gary.Franco at emulex.com  Mon Jun 12 07:34:26 2006
From: Gary.Franco at emulex.com (Gary.Franco at emulex.com)
Date: Mon, 12 Jun 2006 07:34:26 -0700
Subject: Protection Modes in SCSI devices
Message-ID: <mailman.516.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606120_f.htm">HTML-formatted message</A>

All,
I have a question with regard to the discussion in SPC4r04 
In clause 7.6.4 Extended INQUIRY Data VPD page, there are 3 bits
discussed
*	GRD_CHK,
*	APP_CHK and
*	REF_CHK
They are defined as far as their meaning, but never discussed how they
are set. Is this part of the format process, or simply the capability of
the device firmware or design?
Any Help?
__________________________________
Gary Franco Consultant Engineer 
Emulex Network Systems 
972-671-7433 Dallas Office
972-671-7435 Dallas Office Fax 
720-652-6387 Longmont Colorado Office 
720-494-1817 Longmont Colorado Office Fax
972-839-5694 Cell Phone
Today's Quote 
It is not the cards you are dealt but what you do with them that counts.
-Anonymous
This message contains confidential information of Emulex Corporation
intended only for listed recipients and should not be forwarded to
anyone else.  
If you have received this message in error, please delete it
immediately.  Thank you. 


From Gerry.Houlder at seagate.com  Mon Jun 12 11:14:44 2006
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Mon, 12 Jun 2006 13:14:44 -0500
Subject: Protection Modes in SCSI devices
Message-ID: <mailman.517.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Like all INQUIRY bits, these bits are set by the SCSI device to indicate
its capability for the function. These will always be set in a device that
is capable of supporting the function. To tell whether the capability has
been invoked or not you must use READ CAPACITY(16) and interpret the bits
returned there.
	     Gary.Franco at emule						   
	     x.com							   
	     Sent by:							To 
	     owner-t10 at t10.org	       <t10 at t10.org>			   
	     No Phone Info						cc 
	     Available							   
								   Subject 
				       Protection Modes in SCSI devices    
	     06/12/2006 09:34						   
	     AM 							   
All,
I have a question with regard to the discussion in SPC4r04
In clause 7.6.4 Extended INQUIRY Data VPD page, there are 3 bits discussed
      GRD_CHK,
      APP_CHK and
      REF_CHK
They are defined as far as their meaning, but never discussed how they are
set. Is this part of the format process, or simply the capability of the
device firmware or design?
Any Help?
__________________________________
Gary Franco Consultant Engineer
Emulex Network Systems
972-671-7433 Dallas Office
972-671-7435 Dallas Office Fax
720-652-6387 Longmont Colorado Office
720-494-1817 Longmont Colorado Office Fax
972-839-5694 Cell Phone
Today's Quote
It is not the cards you are dealt but what you do with them that counts.
-Anonymous
This message contains confidential information of Emulex Corporation
intended only for listed recipients and should not be forwarded to anyone
else.
If you have received this message in error, please delete it immediately.
Thank you.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Tue Jun 13 00:58:57 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 13 Jun 2006 16:58:57 +0900
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.518.1441607309.22510.t10@sandbox.t10.org>

Attachment #1: <A HREF="r0606130_question_fast_re-format.pdf">question_fast_re-format.pdf</A>

Hello all,
This is an action item of June meeting.
Please send your selection and commnet by June 21 (if possible).
Best regards,
Keiji Katata
PIONEER CORP.
(See attached file: Question fast re-format.pdf)


From keiji_katata at post.pioneer.co.jp  Tue Jun 13 02:12:09 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 13 Jun 2006 18:12:09 +0900
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.519.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
One amendment.
Pioneer drive supports "13h: Quick Grow the last Border" for unclose disc
operation.
Best regards,
Keiji Katata
PIONEER CORP.
keiji_katata at post.pioneer.co.jp@avc-pioneer.com on 2006/06/13 16:58:57
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B:  mtfuji5 at avc-pioneer.com
cc:    t10 at t10.org
bcc:
$B7oL>(B:  Question for RW-DL fast re-format
Hello all,
This is an action item of June meeting.
Please send your selection and commnet by June 21 (if possible).
Best regards,
Keiji Katata
PIONEER CORP.
(See attached file: Question fast re-format.pdf)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From michael.banther at hp.com  Tue Jun 13 08:06:47 2006
From: michael.banther at hp.com (Banther, Michael)
Date: Tue, 13 Jun 2006 16:06:47 +0100
Subject: ADC-2 SET MEDIUM ATTRIBUTE
Message-ID: <mailman.520.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606132_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0606132_banther_michael.vcf">banther_michael.vcf</A>

Hi Paul,
A question about the medium attributes: ADC2r05a clause 5.3.1 states,
'Attributes established when no medium is present shall be applied to
the next medium loaded.'  We're not sure how to interpret this sentence
when a load operation fails.  What did you intend?  Should the device
server apply the medium attributes to the next successful load or should
it clear the attributes when a load operation fails?  Thanks.
Regards,
Michael Banther
Hewlett-Packard Ltd.
+44 117 312 9503


From Alvin.Cox at seagate.com  Tue Jun 13 14:03:30 2006
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Tue, 13 Jun 2006 16:03:30 -0500
Subject: Reminder> SAS PHY working group conference call Thursday, 8 am PDT
Message-ID: <mailman.521.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606133_f.htm">HTML-formatted message</A>

Agenda:
Agenda: 
1.	Training sequence/speed negotiation 
http://www.t10.org/ftp/t10/document.05/05-397r3.pdf
The following ideas are for consideration. Please investigate and discuss 
on the 6/15 call. Reflector traffic is welcome and encouraged. Some 
concerns related to how the information is handled and whether it reaches 
beyond the PHY layer.
Idea floated in the WG meeting of just sending G1 traffic in the G3 
window.  This should get through without needing training.
It would diverge from the normal window definition by:
* Start with training pattern? (Suggest leaving as idle time since speed 
will be determined later)
* Continue with ALIGN (0)/ALIGN (1) algorithm like today
* End by sending information about supported rates and features, not just 
sending ALIGN (1)s.  Include:
  - Additional rates supported (G3, G4, G5, etc.)
  - Whether the phy can receive SSC
  - Advice to the other transmitter to help it decide about tx amplitude, 
preemphasis, etc.
    * "Receiver device" characteristics (which it should know)
    * System interconnect characteristics (which it may know)
This would be the last trial window; there'd be no need for subsequent 
(G4, G5, etc.) windows following the current algorithm. The next window 
would be the final one, which would enable SSC if supported, start with a 
training sequence, perform whatever is needed for dword sync, etc. like 
has been discussed.  If lock is unsuccessful, the phys restart OOB.  If 
lock is repeatedly unsuccessful, turn off the fastest rate and try again. 
(Same issues as today)
2.	Spread Spectrum Clocking 
a. SSC options / trade-offs [Witt]
http://www.t10.org/ftp/t10/document.06/06-267r0.pdf
Compares up-, center- and down-spreading for SSC. Conclusion was that the 
short-term buffering impact of SSC is minimal, but long-term impact was 
not covered. Makes a possible case for center-spreading.
b. SAS-2 Spread-spectrum clocking by upspreading (06-263) [Elliott]
http://www.t10.org/ftp/t10/document.06/06-263r0.pdf
Present cases and issues with different SSC schemes. Supports 
up-spreading, but it looks like the center-spreading calculation may have 
not been done correctly regarding the buffer dword total. Kevin Witt will 
contact Rob about this. 
PARTICIPANT INFORMATION: 
Toll Free Dial in Number: (866) 279-4742 
International Access/Caller Paid Dial In Number: (309) 229-0118 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate 
Topic: SAS-2 PHY WG 
Date: Thursday, June 15, 2006 
Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago) 
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809


From roweber at ieee.org  Thu Jun 15 14:01:55 2006
From: roweber at ieee.org (Ralph Weber)
Date: Thu, 15 Jun 2006 16:01:55 -0500
Subject: SPC-4 r05a
Message-ID: <mailman.522.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
The complains were too numerous for this early in a draft's lifetime.
Besides, I even got wrote 'Revision 04' where 'Revision 05' is supposed
to go.
http://www.t10.org/ftp/t10/drafts/spc4/spc4r05a.pdf
has been uploaded to fix the gaffs.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From steve.finch at st.com  Thu Jun 15 14:05:37 2006
From: steve.finch at st.com (Stephen FINCH)
Date: Thu, 15 Jun 2006 15:05:37 -0600
Subject: BROADCAST ASYNCHRONOUS EVENT
Message-ID: <mailman.523.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Stephen FINCH <steve.finch at st.com>
*
I noticed that in sas2r04 that we define BROADCAST (ASYNCHRONOUS EVENT) and
have a way to send it, but we don't allow anyone to receive it.  I think we
need to add to the SL_CC state machine, in states CC0, CC1 and CC2, the
requirement for the CC state machine to send a ASYNCHRONOUS EVENT RECEIVED
confirmation to the management layer.  This is how the reception of a
BROADCAST (CHANGE) is handled.
Or maybe we should make the change more generic and allow _any_ received
BROADCAST to cause a confirmation to be sent to the management layer with a
type argument?
Regards,
Steve Finch
STMicroelectronics
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From steve.finch at st.com  Fri Jun 16 05:57:43 2006
From: steve.finch at st.com (Stephen FINCH)
Date: Fri, 16 Jun 2006 06:57:43 -0600
Subject: BROADCAST ASYNCHRONOUS EVENT (re-post)
Message-ID: <mailman.524.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Stephen FINCH <steve.finch at st.com>
*
(I sent this out to the reflector a couple of days ago, but never saw it come
back so here it is again.)
I noticed that in sas2r04 that we define BROADCAST (ASYNCHRONOUS EVENT) and
have a way to send it, but we don't allow anyone to receive it.  I think we
need to add to the SL_CC state machine, in states CC0, CC1 and CC2, the
requirement for the CC state machine to send a ASYNCHRONOUS EVENT RECEIVED
confirmation to the management layer.  This is how the reception of a
BROADCAST (CHANGE) is handled.
Or maybe we should make the change more generic and allow _any_ received
BROADCAST to cause a confirmation to be sent to the management layer with a
type argument?
Regards,
Steve Finch
STMicroelectronics
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Alvin.Cox at seagate.com  Fri Jun 16 06:36:45 2006
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Fri, 16 Jun 2006 08:36:45 -0500
Subject: Minutes of SAS PHY WG teleconference June 15, 2006
Message-ID: <mailman.525.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606161_f.htm">HTML-formatted message</A>

Minutes are posted at:
http://www.t10.org/ftp/t10/document.06/06-284r0.pdf
They contain a list of items to be discussed on our next conference call 
that will be next week on FRIDAY June 23 concerning proposal 06-263 as 
well as 05-397.
Please review and be prepared to discuss.
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809


From hcurley at indra.com  Fri Jun 16 12:28:47 2006
From: hcurley at indra.com (Hugh Curley)
Date: Fri, 16 Jun 2006 13:28:47 -0600
Subject: SSC Data encryption
Message-ID: <mailman.526.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Hugh Curley <hcurley at indra.com>
*
Is the purpose of the Write Encrypted command proposal to: 1) writes to 
a drive in encryption mode with a legacy write command will fail, and 2) 
writes to a drive not in encryption mode with the Write Encrypted(16) 
command will fail?
I cannot find this defined in either 06-207 nor 06-172.
Hugh Curley
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From gideon at decru.com  Fri Jun 16 13:09:04 2006
From: gideon at decru.com (Gideon Avida)
Date: Fri, 16 Jun 2006 13:09:04 -0700
Subject: SSC Data encryption
Message-ID: <mailman.527.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Gideon Avida" <gideon at decru.com>
*
Here's what I wrote in 06-207:
KEY INSTANCE COUNTER is the same KEY INSTANCE COUNTER from the Data
Encryption Status page (see 8.5.2.7). If the KEY INSTANCE COUNTER does not
match, the device server shall terminate the command with CHECK CONDITION
status,
with the sense key set to DATA PROTECT, and the additional sense code set to
DATA
ENCRYPTION KEY INSTANCE COUNTER HAS CHANGED. If encryption is not
enabled, the device server shall terminate the command with CHECK CONDITION
status, with the sense key set to DATA PROTECT, and the additional sense
code set to
DATA ENCRYPTION NOT ENABLED.
Please let me know if you have suggestions for improvement.
Since this command is optional, legacy drives and drives that don't encrypt
will probably not support it.
I am also toying with the idea of adding a bit to Set Data Encryption page
(now in SSC-3) to indicate that using Write Encrypted is required. Another
option is that using "legacy" write will write in the clear (making it
easier for the application to switch from encrypted to unencrypted). This
could be useful for writing application metadata that should be in the
clear.
Thanks,
Gideon
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Hugh Curley
Sent: Friday, June 16, 2006 12:29 PM
To: t10 at t10.org
Subject: SSC Data encryption
* From the T10 Reflector (t10 at t10.org), posted by:
* Hugh Curley <hcurley at indra.com>
*
Is the purpose of the Write Encrypted command proposal to: 1) writes to 
a drive in encryption mode with a legacy write command will fail, and 2) 
writes to a drive not in encryption mode with the Write Encrypted(16) 
command will fail?
I cannot find this defined in either 06-207 nor 06-172.
Hugh Curley
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Sat Jun 17 23:01:38 2006
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 18 Jun 2006 00:01:38 -0600
Subject: Recent T10 documents uploaded since 2006/06/11
Message-ID: <mailman.528.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SAT - Fix Task Management Functions
(by: Robert Sheffield)
T10/06-179r2   Uploaded: 2006/06/12   55752 bytes
ftp://ftp.t10.org/t10/document.06/06-179r2.pdf
SAS-2: Reporting ZONE PARTICIPATING CAPABLE in the IDENTIFY address
frame
(by: Kevin Marks)
T10/06-210r2   Uploaded: 2006/06/12   58032 bytes
ftp://ftp.t10.org/t10/document.06/06-210r2.pdf
SAT - Example configurations
(by: Robert Sheffield)
T10/06-262r2   Uploaded: 2006/06/12   40444 bytes
ftp://ftp.t10.org/t10/document.06/06-262r2.pdf
SAS-2 Spread-spectrum clocking
(by: Rob Elliott)
T10/06-263r1   Uploaded: 2006/06/14   118630 bytes
ftp://ftp.t10.org/t10/document.06/06-263r1.pdf
SAT - ATA resets and ATA nexus Loss
(by: Robert Sheffield)
T10/06-270r1   Uploaded: 2006/06/12   24857 bytes
ftp://ftp.t10.org/t10/document.06/06-270r1.pdf
SAS-2 Allow more than one ZPSDS in a SAS domain
(by: Rob Elliott)
T10/06-279r0   Uploaded: 2006/06/13   82350 bytes
ftp://ftp.t10.org/t10/document.06/06-279r0.pdf
ADT-2 Correct Major and Minor Revision Numbers
(by: Paul Suhler)
T10/06-280r0   Uploaded: 2006/06/13   85509 bytes
ftp://ftp.t10.org/t10/document.06/06-280r0.pdf
SPC-4 WRITE BUFFER clarifications
(by: Rob Elliott)
T10/06-282r0   Uploaded: 2006/06/15   49150 bytes
ftp://ftp.t10.org/t10/document.06/06-282r0.pdf
ADT-2 Limit Login due to Symbol Framing Errors
(by: Michael Banther)
T10/06-283r0   Uploaded: 2006/06/15   56365 bytes
ftp://ftp.t10.org/t10/document.06/06-283r0.pdf
Minutes of SAS Physical Working Group teleconference, June 15, 2006
(by: Alvin Cox)
T10/06-284r0   Uploaded: 2006/06/15   29748 bytes
ftp://ftp.t10.org/t10/document.06/06-284r0.pdf
Working Drafts
--------------
SCSI Primary Commands - 4 (SPC-4)
(Editor: Ralph Weber)
 Rev: 05a      Uploaded: 2006/06/15   5223224 bytes
ftp://ftp.t10.org/t10/drafts/spc4/spc4r05a.pdf
(Report generated on 2006/06/18 at 00:01:37)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From sandeep.taneja at mail.nsysinc.com  Mon Jun 19 03:12:00 2006
From: sandeep.taneja at mail.nsysinc.com (sandeep taneja)
Date: 19 Jun 2006 15:42:00 +0530
Subject: queries in ST-IFR state machine for transport layer
Message-ID: <mailman.529.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* sandeep taneja <sandeep.taneja at mail.nsysinc.com>
*
Hi all,
I have certain doubts in Transport layer.
I am referring to SAS Revision 3a, released on 22 April 2006.
In section 9.2.6.2.2.2 (Processing transport protocol service requests)
it has been stated that :
If the ST_ITS state machine for the tag specified in the Send Task
Management Request is currently in use,
then this state machine (ST-IFR) shall set the retransmit bit argument
to one. If the ST_ITS state machine for the tag specified in the Send
Task Management Request is not currently in use, then this state machine
shall set the Retransmit Bit argument to zero.
Queries:
1. I am not getting clearly the condition in which talked about scenario
will occur. 
Is it when ACK/NAK (may be ACK/NAK time out or Connection lost without
ACK/NAK) is not received for a transmitted Task Mgt function?
please point to me if i am going wrong.
2.also related to same , 
is'nt a ST_ITS machine becomes free after sending transmission complete
messages to ST-IFR machine.
if yes then how the above said condition will become true?     
if no then when ST-IFR machine will free a ST-ITS machine?
-- 
--------------------------------------------
Regards
Sandeep Taneja
nSys
Accelerating designs
http://www.nsysinc.com
91-11-27354820 (Ext.241)
1-510-402-4544(VOIP)
--------------------------------------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Gary.Franco at emulex.com  Mon Jun 19 04:47:13 2006
From: Gary.Franco at emulex.com (Gary.Franco at emulex.com)
Date: Mon, 19 Jun 2006 04:47:13 -0700
Subject: Questions regarding protection  mode definitions
Message-ID: <mailman.530.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606191_f.htm">HTML-formatted message</A>

All,
There seems to be a difference between the SUPPORTED PROTECTION TYPES
defined in Table 331 of spc4r04, and the P_TYPE definitions of the READ
CAPACITY (16) Parameter data defined in Table 43.
The way I read the definitions of these two items sounds like they are
defining the same thing.
Help - I am confused
__________________________________
Gary Franco Consultant Engineer 
Emulex Network Systems 
972-671-7433 Dallas Office
972-671-7435 Dallas Office Fax 
720-652-6387 Longmont Colorado Office 
720-494-1817 Longmont Colorado Office Fax
972-839-5694 Cell Phone
Today's Quote 
It is not the cards you are dealt but what you do with them that counts.
-Anonymous
This message contains confidential information of Emulex Corporation
intended only for listed recipients and should not be forwarded to
anyone else.  
If you have received this message in error, please delete it
immediately.  Thank you. 


From gop at us.ibm.com  Mon Jun 19 06:45:40 2006
From: gop at us.ibm.com (George Penokie)
Date: Mon, 19 Jun 2006 08:45:40 -0500
Subject: Questions regarding protection  mode definitions
Message-ID: <mailman.531.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606192_f.htm">HTML-formatted message</A>

Gary,
The Identify command information (i.e., the PROTECT bit in the standard 
inquire data and the SPT field in the extended inquire VPD page ) define 
which type of protection the logical unit  supports. This information is 
used by an application client to determine which types of protection it 
can format the logical unit to.
The Read Capacity command information indicates (i.e., the P_TYPE field 
and the PROT_EN bit) the type of protection to which the logical unit has 
been formatted. This information is used by an application client to 
determine the type of protection the logical unit is currently formatted 
to.
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208
Gary.Franco at emulex.com 
Sent by: owner-t10 at t10.org
06/19/2006 06:47 AM
To
<t10 at t10.org>
cc
Subject
Questions regarding protection	mode definitions
All,
There seems to be a difference between the SUPPORTED PROTECTION TYPES 
defined in Table 331 of spc4r04, and the P_TYPE definitions of the READ 
CAPACITY (16) Parameter data defined in Table 43.
The way I read the definitions of these two items sounds like they are 
defining the same thing.
Help ? I am confused
__________________________________
Gary Franco Consultant Engineer 
Emulex Network Systems 
972-671-7433 Dallas Office
972-671-7435 Dallas Office Fax 
720-652-6387 Longmont Colorado Office 
720-494-1817 Longmont Colorado Office Fax
972-839-5694 Cell Phone
Today's Quote 
It is not the cards you are dealt but what you do with them that counts.
-Anonymous
This message contains confidential information of Emulex Corporation 
intended only for listed recipients and should not be forwarded to anyone 
else. 
If you have received this message in error, please delete it immediately. 
Thank you. 


From Gerry.Houlder at seagate.com  Mon Jun 19 07:12:02 2006
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Mon, 19 Jun 2006 09:12:02 -0500
Subject: Questions regarding protection  mode definitions
Message-ID: <mailman.532.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
You are right, they are completely different by design.
The Supported Protection Types field in extended INQUIRY VPD page indicates
whether the drive is capable of supporting particular types of protection
information. This doesn't indicate whether any such feature is actually
enabled in the device.
The P_TYPE field in READ CAPACITY(16) indicates which protection type is
actually enabled in the drive and therefore specifies the behavior that
will occur when particular read and write commands are sent to the drive.
	     Gary.Franco at emule						   
	     x.com							   
	     Sent by:							To 
	     owner-t10 at t10.org	       <t10 at t10.org>			   
	     No Phone Info						cc 
	     Available							   
								   Subject 
				       Questions regarding protection	   
	     06/19/2006 06:47	       mode definitions 		   
	     AM 							   
All,
There seems to be a difference between the SUPPORTED PROTECTION TYPES
defined in Table 331 of spc4r04, and the P_TYPE definitions of the READ
CAPACITY (16) Parameter data defined in Table 43.
The way I read the definitions of these two items sounds like they are
defining the same thing.
Help ??? I am confused
__________________________________
Gary Franco Consultant Engineer
Emulex Network Systems
972-671-7433 Dallas Office
972-671-7435 Dallas Office Fax
720-652-6387 Longmont Colorado Office
720-494-1817 Longmont Colorado Office Fax
972-839-5694 Cell Phone
Today's Quote
It is not the cards you are dealt but what you do with them that counts.
-Anonymous
This message contains confidential information of Emulex Corporation
intended only for listed recipients and should not be forwarded to anyone
else.
If you have received this message in error, please delete it immediately.
Thank you.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From zdaggett at hcm.hitachi.com  Tue Jun 20 11:45:19 2006
From: zdaggett at hcm.hitachi.com (Daggett, Zane)
Date: Tue, 20 Jun 2006 14:45:19 -0400
Subject: Booking code
Message-ID: <mailman.533.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606200_f.htm">HTML-formatted message</A>

Dear all,
Previously it was announced that the booking code for the Nashua
meetings hosted by Hitachi Cable Manchester in September was HIT.  The
Crown Plaza just informed me they changed the booking code to HCM for
this years meetings.  
So if you try to book on line at www.crowneplazanashua.com please use
HCM as the Group Booking Code. 
Sorry for the confusion.   
Zane Daggett
Vice President Electronics Group
Hitachi Cable Manchester, Inc.
800-772-0116 x 236
************************************************************************
**************************
CONFIDENTIALITY NOTICE: If you have received this e-mail in error,
please 
immediately notify the sender by e-mail at the address shown. This
e-mail 
transmission and any attachment (s) may contain confidential
information. 
The information is intended only for the use of the individual(s) or
entity to 
whom it is intended even if addressed incorrectly. Please delete it from
your 
files if you are not the intended recipient. Thank you for your
compliance. 
Copyright 2005 Hitachi Cable Manchester, Inc.
************************************************************************
**************************


From daviburg at windows.microsoft.com  Tue Jun 20 15:22:12 2006
From: daviburg at windows.microsoft.com (David Burg)
Date: Tue, 20 Jun 2006 15:22:12 -0700
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.534.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "David Burg" <daviburg at windows.microsoft.com>
*
Hello,
Thank you for this host consultation.
We checked this issue at Microsoft optical platform storage and core
file system services.
Most important is we do not want to change existing format code
behavior. Per consistency with DVD-RW SL, existing format code behavior
shall be unchanged. Otherwise it would cause unexpected behavior in our
software. If new format behavior is desired, it needs to be with a new
format code or option.
Also, we do not want vendor specific implementations. If there is a
feature, please make it mandatory. If it is not possible, at least
specify the feature *and the feature availability recognition*.
Please let us know if further clarification is needed.
Best regards,
David Burg,
Research Software Development Engineering Lead,
Microsoft.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com
[mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of
keiji_katata at post.pioneer.co.jp
Sent: Tuesday, June 13, 2006 12:59 AM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: Question for RW-DL fast re-format
Hello all,
This is an action item of June meeting.
Please send your selection and commnet by June 21 (if possible).
Best regards,
Keiji Katata
PIONEER CORP.
(See attached file: Question fast re-format.pdf)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kenji-tokumitsu at hlds.co.jp  Tue Jun 20 16:05:15 2006
From: kenji-tokumitsu at hlds.co.jp (=?iso-2022-jp?B?VG9rdW1pdHN1IEtlbmppKBskQkZBOHc3cjtKGyhCKQ==?=)
Date: Wed, 21 Jun 2006 08:05:15 +0900
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.535.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* =?iso-2022-jp?B?VG9rdW1pdHN1IEtlbmppKBskQkZBOHc3cjtKGyhCKQ==?=
<kenji-tokumitsu at hlds.co.jp>
*
Katata-san:
I prefer another option.
Option 4
New Format Type of the FORMAT UNIT command is used for the fast re-format
operation.
Best Regards,
Kenji Tokumitsu 
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Tuesday, June 13, 2006 4:59 PM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: Question for RW-DL fast re-format
Hello all,
This is an action item of June meeting.
Please send your selection and commnet by June 21 (if possible).
Best regards,
Keiji Katata
PIONEER CORP.
(See attached file: Question fast re-format.pdf)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From ai.takaharu at jp.panasonic.com  Tue Jun 20 18:03:43 2006
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Wed, 21 Jun 2006 10:03:43 +0900
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.536.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
Hello David,
One of the most important issues Pioneer proposed and Chair wanted to
gather the opinion of each company is that the Standard can prohibit the
Logical Unit from doing something during a command although it has not
been prohibited in the prior version of the standard.
According to Pioneer's proposal, although it is not the documented
proposal, it is prohibited from overwriting a part or whole of the user
data area by FORMAT UNIT command with Format type=00h, i.e. Full format,
for DVD-RW DL disc.
The reason they explained was that some of the software vendors wanted
to preserve the recorded user data through the format process. They said
that a software which can write and append data to the incomplete DVD-RW
disc. But another company requested that they need the method to convert
the incomplete state to complete state without no recorded data
modification.
So, Pioneer proposed that the Full format *SHALL* not overwrite data to
the recorded user data area.
But the current Mt.Fuji and MMC does not prohibit from doing that. So,
it is possible that the Logical Unit overwrite some of the user data
area for the security reason or other purpose. This behavior does not
impact to the execution time of the Full format process. We think
Pioneer's proposal deny this freedom of the implementation.
We understand Pioneer's concern for the execution time of the Full
format for DVD-RW DL disc, because the DVD-RW DL have a new feature
which makes the re-formatting function for the recorded disc very fast.
We think that function is very important and we believe no drive vendor want
to spoil this function. So no one implement the Full format very slow,
even if Mt.Fuji/MMC does not prohibit.
Our proposal is to add an recommendation that the drive should not
overwrite all the user data area where is requested to be formatted by
Full format of FORMAT UNIT command for DVD-RW DL disc during the
formatting process.
If a software vendor want make the incomplete state DVD-RW DL disc to
complete sate without no modification of the recorded user data through
the formatting process, we already have this function as Grow format.
Grow format is not the mandatory function for DVD-RW SL, but we can make
it a mandatory function for DVD-RW DL. This function can also be defined
as a fast re-format operation.
Best Regards,
Harry Ai
VEBU
Panasonic AVC Networks Company
Matsushita/Panasonic
Osaka, Japan
---------------- Start of the original message ----------------
>From: David Burg <daviburg at windows.microsoft.com>
>To: mtfuji5 at avc-pioneer.com
>Cc: t10 at t10.org
>Date: Tue, 20 Jun 2006 15:22:12 -0700
>Subject: RE: Question for RW-DL fast re-format
>
>Hello,
>
>Thank you for this host consultation.
>
>We checked this issue at Microsoft optical platform storage and core
>file system services.
>
>Most important is we do not want to change existing format code
>behavior. Per consistency with DVD-RW SL, existing format code behavior
>shall be unchanged. Otherwise it would cause unexpected behavior in our
>software. If new format behavior is desired, it needs to be with a new
>format code or option.
>
>Also, we do not want vendor specific implementations. If there is a
>feature, please make it mandatory. If it is not possible, at least
>specify the feature *and the feature availability recognition*.
>
>Please let us know if further clarification is needed.
>
>Best regards,
>
>David Burg,
>Research Software Development Engineering Lead,
>Microsoft.
>
>-----Original Message-----
>From: owner-mtfuji5 at avc-pioneer.com
>[mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of
>keiji_katata at post.pioneer.co.jp
>Sent: Tuesday, June 13, 2006 12:59 AM
>To: mtfuji5 at avc-pioneer.com
>Cc: t10 at t10.org
>Subject: Question for RW-DL fast re-format
>
>Hello all,
>
>This is an action item of June meeting.
>Please send your selection and commnet by June 21 (if possible).
>
>Best regards,
>
>Keiji Katata
>PIONEER CORP.
>
>(See attached file: Question fast re-format.pdf)
----------------- End of the original message -----------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From mou_huang at goCyberlink.com  Wed Jun 21 02:26:54 2006
From: mou_huang at goCyberlink.com (Mou Huang)
Date: Wed, 21 Jun 2006 17:26:54 +0800
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.537.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606210_f.htm">HTML-formatted message</A>

Dear Katata-san,
As regards the question "2. Question about re-format operation of Mt. Fuji
specification",
we CyberLink would like to choose the option 2:
2. Format type Grow Session (11h) and Quick Grow (13h) shall not modify 
    the recorded user data area. Other format type behavior is vender
specific.
To us, the Quick Grow (13h) is enough.
If the Fast Re-format is mandatory, we hope that drive vendors can support
format type 13h. 
If it's optional, we suggest to add one flag "Fast Re-format" at bit 5 of
byte 4 in the 
"Feature 002Ch: Rigid Restricted Overwrite Feature Descriptor" so that we can
know whether 
the Fast Re-format is supported or not. 
When it's "1b", then format type 13h should be supported for DVD-RW DL Fast
Re-Format;
When it's "0b", then Fast Re-format is not supported.
What do you think?
Thanks a lot.
Best Regards,
Mou Huang
CyberLink Corp.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com]On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Tuesday, June 13, 2006 3:59 PM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: Question for RW-DL fast re-format
Hello all,
This is an action item of June meeting.
Please send your selection and commnet by June 21 (if possible).
Best regards,
Keiji Katata
PIONEER CORP.
(See attached file: Question fast re-format.pdf)
 << File: Question fast re-format.pdf >> 
This correspondence is from Cyberlink Corp. and is intended only for use by
the recipient named herein, and may contain privileged, proprietary and/or
confidential information, and is intended only to be seen and used by named
addressee(s). You are notified that any discussion, dissemination,
distribution or copying of this correspondence and any attachments, is
strictly prohibited, unless otherwise authorized or consented to in writing
by the sender. If you have received this correspondence in error, please
notify the sender immediately, and please permanently delete the original and
any copies of it and any attachment and destroy any related printouts without
reading or copying them.


From Mignon.M.Fernandez at bitmicro.com  Wed Jun 21 06:00:32 2006
From: Mignon.M.Fernandez at bitmicro.com (Mignon Fernandez)
Date: Wed, 21 Jun 2006 21:00:32 +0800
Subject: SAS: transport layer: ACK lost
Message-ID: <mailman.538.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606211_f.htm">HTML-formatted message</A>

Hello,
If retries are enabled, and an ACK gets lost, then the transmitter
retries, is it required for the receiver to overwrite the data that is
retried even if it has ACK-ed all data in the previous connection? 
Thanks in advance,
Mignon Fernandez


From David.Peterson at mcdata.com  Wed Jun 21 10:36:09 2006
From: David.Peterson at mcdata.com (David Peterson)
Date: Wed, 21 Jun 2006 12:36:09 -0500
Subject: [T11.3] FC-LS: TPRLO format and usage
Message-ID: <mailman.539.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606212_f.htm">HTML-formatted message</A>

One more question: Is anyone using the Third Party Originator
Process_Associator and Responder Process_Associator fields in the TPRLO
Request payload?
If I receive no replies indicating they are used, I will also propose
that these fields be obsoleted too.
Thanks...Dave 
(no disclaimer)
________________________________
	From: t11_3-bounces at listserve.com
[mailto:t11_3-bounces at listserve.com] On Behalf Of David Peterson
	Sent: Wednesday, June 21, 2006 8:34 AM
	To: t11_3 at mail.t11.org
	Subject: [T11.3] FC-LS: TPRLO format and usage
	Howdy,
	Here is the plan that was agreed upon at the June FC-LS working
group meeting:
	- the Third Party Originator N_Port_ID field in the request
payload will be obsoleted
	- the Global bit shall be set to one in the request payload
	- the Responder may reject the TPRLO request if the Global bit
is not set to one
	- the LS_ACC payload is the same as the request payload
	Please reply if you have any objections along with your
reasoning.
	Thanks...Dave
	(no disclaimer)


From David.Peterson at mcdata.com  Wed Jun 21 09:57:03 2006
From: David.Peterson at mcdata.com (David Peterson)
Date: Wed, 21 Jun 2006 11:57:03 -0500
Subject: FW: [T11.3] FC-LS: TPRLO format and usage
Message-ID: <mailman.540.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606213_f.htm">HTML-formatted message</A>

FYI...Dave
(no disclaimer)
________________________________
From: t11_3-bounces at listserve.com [mailto:t11_3-bounces at listserve.com]
On Behalf Of David Peterson
Sent: Wednesday, June 21, 2006 8:34 AM
To: t11_3 at mail.t11.org
Subject: [T11.3] FC-LS: TPRLO format and usage
Howdy,
Here is the plan that was agreed upon at the June FC-LS working group
meeting:
- the Third Party Originator N_Port_ID field in the request payload will
be obsoleted
- the Global bit shall be set to one in the request payload
- the Responder may reject the TPRLO request if the Global bit is not
set to one
- the LS_ACC payload is the same as the request payload
Please reply if you have any objections along with your reasoning.
Thanks...Dave
(no disclaimer)


From David.Peterson at mcdata.com  Wed Jun 21 10:36:09 2006
From: David.Peterson at mcdata.com (David Peterson)
Date: Wed, 21 Jun 2006 12:36:09 -0500
Subject: [T11.3] FC-LS: TPRLO format and usage
Message-ID: <mailman.541.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606214_f.htm">HTML-formatted message</A>

One more question: Is anyone using the Third Party Originator
Process_Associator and Responder Process_Associator fields in the TPRLO
Request payload?
If I receive no replies indicating they are used, I will also propose
that these fields be obsoleted too.
Thanks...Dave 
(no disclaimer)
________________________________
	From: t11_3-bounces at listserve.com
[mailto:t11_3-bounces at listserve.com] On Behalf Of David Peterson
	Sent: Wednesday, June 21, 2006 8:34 AM
	To: t11_3 at mail.t11.org
	Subject: [T11.3] FC-LS: TPRLO format and usage
	Howdy,
	Here is the plan that was agreed upon at the June FC-LS working
group meeting:
	- the Third Party Originator N_Port_ID field in the request
payload will be obsoleted
	- the Global bit shall be set to one in the request payload
	- the Responder may reject the TPRLO request if the Global bit
is not set to one
	- the LS_ACC payload is the same as the request payload
	Please reply if you have any objections along with your
reasoning.
	Thanks...Dave
	(no disclaimer)


From kdbutt at us.ibm.com  Wed Jun 21 11:28:21 2006
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 21 Jun 2006 11:28:21 -0700
Subject: Minutes of SSC-3 NIST Key Wrapping Phone Conference Posted
Message-ID: <mailman.542.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606215_f.htm">HTML-formatted message</A>

2006/06/21 11:31:54 
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/ftp/t10/document.06/06-292r0.pdf
Normally, the posting/archiving process takes about 30 minutes.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From lohmeyer at t10.org  Wed Jun 21 12:20:46 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 21 Jun 2006 13:20:46 -0600
Subject: SAS Zoning Management WG minutes
Message-ID: <mailman.543.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft minutes of the SAS Zoning Management WG meeting are available at:
   http://www.t10.org/ftp/t10/document.06/06-290r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Alvin.Cox at seagate.com  Wed Jun 21 14:25:30 2006
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Wed, 21 Jun 2006 16:25:30 -0500
Subject: SAS PHY teleconference this FRIDAY, 6/23, 10 am CDT
Message-ID: <mailman.544.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606217_f.htm">HTML-formatted message</A>

Agenda: 

1.	Training sequence/speed negotiation and SSC

http://www.t10.org/ftp/t10/document.06/06-263r1.pdf

Discussed Rob???s updated proposal that includes a shift in position on SSC 

method plus adds spec details for other areas that will need to be 

updated. A follow-up teleconference will be held on June 23 to continue 

discussing the proposal. Special items discussed during today???s call:

End devices only need to transmit with downspreading.

All receiver devices need the ability to accept center spreading, down 

spreading, or no SSC.

The G3 window is proposed as the last window for speed determination. If 

nothing happens during that window, the previously negotiated window  (G1 

or G2) is the speed. The G3 window would be run at 1.5 Gbps and include 

data transfer at the end to communicate speed and SSC capability and 

possibly other information. This would allow the next window to be the 

final speed negotiation window with receiver equalization tuning (G3 and 

faster). We discussed when SSC should be turned on. Although easier to 

turn on prior to tuning the receiver device, it may be preferred to turn 

on afterwards. Items needing investigation/comment:

??	 Should SSC be on or off during receiver equalization setting?

??	 Is it viable to make a drive have independent SSC control on the 

transmitters of its two ports? Independence is required to set the 

receiver equalization without SSC since one port may be operating prior to 

the other one performing speed negotiation.

??	 In the beginning of the final speed negotiation window, does there 

need to be an idle time or can both devices immediately start transmitting 

the training pattern? It is assumed that if G2 is required, the sequence 

would follow the SAS 1.1 standard.

??	 It is assumed that all expanders and initiators are capable of 

receiving downspread SSC. Are there any know exceptions?

??	 Will an initiator or expander accept downspreading from a SAS 

device running at G1 or G2 speed?

??	 If a phy transmitter has SSC disabled or is using downspread SSC 

only, it could get away with inserting fewer ALIGNs - 1/128 (the SATA 

ratio) would cover sending to either SAS or SATA phys with downspread SSC. 

Is that complication worth a 0.8% performance improvement? (e.g. at 6 

Gbps, this is 4.77 MBps).

??	 Rob will contact Harvey Newman to work on the speed negotiation 

window. Please note any special requirements that may be needed.

If at all possible, it would be of great benefit to have the SSC and speed 

negotiation sequence resolved at the July T10 meeting by completing 

updates to 06-263 and 05-397. These items are the most critical as they 

impact ASIC design. Other specification issues are likely to be controlled 

by adjustable parameters while these issues likely affect basic hardware 

design.

2.	Next conference call June 23, 2006 

PARTICIPANT INFORMATION: 

Toll Free Dial in Number: (866) 279-4742 

International Access/Caller Paid Dial In Number: (309) 229-0118 

PARTICIPANT CODE: 3243413 

Webex information: 

https://seagate.webex.com/seagate 

Topic: SAS-2 PHY WG 

Date: Friday, June 23, 2006 

Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago) 

Meeting number: 826 515 680 

Meeting password: 6gbpsSAS

Alvin Cox

Seagate Technology, LLC

Tel 405-350-7424

Cell 405-206-4809

E-Mail	alvin.cox at seagate.com



From keiji_katata at post.pioneer.co.jp  Wed Jun 21 19:30:01 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 22 Jun 2006 11:30:01 +0900
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.545.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Thank you Ai san,
May I confirm your opinion? You prefer Option 2?
[Comment as Pioneer]
Pioneer proposal is not new idea. BD-RE drive does not write user data area
at
the default format operation of RE disc. I think it is same reason that 1
hour
operation time is not acceptable.
Best regards,
Keiji Katata
PIONEER CORP.
Takaharu Ai <ai.takaharu at jp.panasonic.com>@avc-pioneer.com on 2006/06/21
10:03:43
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B:  mtfuji5 at avc-pioneer.com, t10 at t10.org
cc:
bcc:
$B7oL>(B:  Re: Question for RW-DL fast re-format
Hello David,
One of the most important issues Pioneer proposed and Chair wanted to
gather the opinion of each company is that the Standard can prohibit the
Logical Unit from doing something during a command although it has not
been prohibited in the prior version of the standard.
According to Pioneer's proposal, although it is not the documented
proposal, it is prohibited from overwriting a part or whole of the user
data area by FORMAT UNIT command with Format type=00h, i.e. Full format,
for DVD-RW DL disc.
The reason they explained was that some of the software vendors wanted
to preserve the recorded user data through the format process. They said
that a software which can write and append data to the incomplete DVD-RW
disc. But another company requested that they need the method to convert
the incomplete state to complete state without no recorded data
modification.
So, Pioneer proposed that the Full format *SHALL* not overwrite data to
the recorded user data area.
But the current Mt.Fuji and MMC does not prohibit from doing that. So,
it is possible that the Logical Unit overwrite some of the user data
area for the security reason or other purpose. This behavior does not
impact to the execution time of the Full format process. We think
Pioneer's proposal deny this freedom of the implementation.
We understand Pioneer's concern for the execution time of the Full
format for DVD-RW DL disc, because the DVD-RW DL have a new feature
which makes the re-formatting function for the recorded disc very fast.
We think that function is very important and we believe no drive vendor want
to spoil this function. So no one implement the Full format very slow,
even if Mt.Fuji/MMC does not prohibit.
Our proposal is to add an recommendation that the drive should not
overwrite all the user data area where is requested to be formatted by
Full format of FORMAT UNIT command for DVD-RW DL disc during the
formatting process.
If a software vendor want make the incomplete state DVD-RW DL disc to
complete sate without no modification of the recorded user data through
the formatting process, we already have this function as Grow format.
Grow format is not the mandatory function for DVD-RW SL, but we can make
it a mandatory function for DVD-RW DL. This function can also be defined
as a fast re-format operation.
Best Regards,
Harry Ai
VEBU
Panasonic AVC Networks Company
Matsushita/Panasonic
Osaka, Japan
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Wed Jun 21 19:41:41 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 22 Jun 2006 11:41:41 +0900
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.546.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Thank you Mou,
May I confirm your requirement?
Do you request the null data writing on the entire RW-DL disc at the default
type (Formatting on Format Type = 00h)? Why do you need it always?
RW-DL format operation does not verify the user data area. Because it does
not
have hardware defect management.
Best regards,
Keiji Katata
PIONEER CORP.
"Mou Huang" <mou_huang at goCyberlink.com>@avc-pioneer.com on 2006/06/21
18:26:54
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B:  <mtfuji5 at avc-pioneer.com>
cc:    <t10 at t10.org>
bcc:
$B7oL>(B:  RE: Question for RW-DL fast re-format
Dear Katata-san,
As regards the question "2. Question about re-format operation of Mt. Fuji
specification",
we CyberLink would like to choose the option 2:
2. Format type Grow Session (11h) and Quick Grow (13h) shall not modify
??? the recorded user data area. Other format type behavior is vender
specific.
To us, the Quick Grow (13h) is enough.
If the Fast Re-format is mandatory, we hope that drive vendors can support
format type 13h.
If it's optional, we suggest to add one flag "Fast Re-format" at bit 5 of
byte 4
in the
"Feature 002Ch: Rigid Restricted Overwrite Feature Descriptor" so that we can
know whether
the Fast Re-format is supported or not.
When it's "1b", then format type 13h should be supported for DVD-RW DL Fast
Re-Format;
When it's "0b", then Fast Re-format is not supported.
What do you think?
Thanks a lot.
Best Regards,
Mou Huang
CyberLink Corp.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com]On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Tuesday, June 13, 2006 3:59 PM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: Question for RW-DL fast re-format
Hello all,
This is an action item of June meeting.
Please send your selection and commnet by June 21 (if possible).
Best regards,
Keiji Katata
PIONEER CORP.
(See attached file: Question fast re-format.pdf)
?<< File: Question fast re-format.pdf >>
This correspondence is from Cyberlink Corp. and is  intended only for use by
the
recipient named herein, and may contain privileged,  proprietary and/or
confidential information, and is intended only to be seen and  used by named
addressee(s). You are notified that any discussion, dissemination, 
distribution
or copying of this correspondence and any attachments, is strictly 
prohibited,
unless otherwise authorized or consented to in writing by the  sender. If you
have received this correspondence in error, please notify the  sender
immediately, and please permanently delete the original and any copies of  it
and any attachment and destroy any related printouts without reading or 
copying
them.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Wed Jun 21 19:42:00 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 22 Jun 2006 11:42:00 +0900
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.547.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Thank you everyone.
I would like to write my comment one by one.
[Answer to question]
Mt.Fuji group did not discuss the change of the DVD-RW SL (Single Layer)
Format
Unit Command. There is no change in other media types (DVD-RAM, +RW, etc.)
RW-DL is new media. So I think Pioneer proposal does not change of the drive
behavior.
[Comment as a chair]
I understand that you do not desire the device behavior which cannot be
checked.
[Comment as Pioneer]
We need to focus the behavior of the default type (Formatting on Format Type
=
00h). Full format of the DVD-RW DL will take more than 1 hour. User never
accept
this long time.
The other hands, 2 hours - 6 hours TV recording on the RW-DL disc may fill
the
disc up. Once it becomes ROM compatible state (Complete state), another full
format is not necessary.
For example, BD-RE drive dose not fill data area up with null data of the RE
disc by the default format operation. Drive changes Defect List only. If
there
was no linear replacement (no defect), host can read user data on the RE disc
before file system re-construction. Usually file system re-construction makes
the old user data unreadable.
[Question to software venders]
The RW-DL physical format allows pre-formatted media by the media
manufacture.
If software does not use the Format Unit command Format Type = 00h, we can
stop
this discussion now.
All software venders, how do you think? Does the software use Format Unit
command?
Best regards,
Keiji Katata
PIONEER CORP.
"David Burg" <daviburg at windows.microsoft.com>@avc-pioneer.com on 2006/06/21
07:22:12
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B:  <mtfuji5 at avc-pioneer.com>
cc:    <t10 at t10.org>
bcc:
$B7oL>(B:  RE: Question for RW-DL fast re-format
Hello,
Thank you for this host consultation.
We checked this issue at Microsoft optical platform storage and core
file system services.
Most important is we do not want to change existing format code
behavior. Per consistency with DVD-RW SL, existing format code behavior
shall be unchanged. Otherwise it would cause unexpected behavior in our
software. If new format behavior is desired, it needs to be with a new
format code or option.
Also, we do not want vendor specific implementations. If there is a
feature, please make it mandatory. If it is not possible, at least
specify the feature *and the feature availability recognition*.
Please let us know if further clarification is needed.
Best regards,
David Burg,
Research Software Development Engineering Lead,
Microsoft.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Wed Jun 21 19:42:16 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 22 Jun 2006 11:42:16 +0900
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.548.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Tokumitsu san, if possible, let me know how the default type (Formatting on
Format Type = 00h) shall work?
Best regards,
Keiji Katata
PIONEER CORP.
Tokumitsu Kenji($BFA8w7r;J(B) <kenji-tokumitsu at hlds.co.jp>@avc-pioneer.com
on
2006/06/21 08:05:15
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B:  <mtfuji5 at avc-pioneer.com>
cc:    <t10 at t10.org>
bcc:
$B7oL>(B:  RE: Question for RW-DL fast re-format
Katata-san:
I prefer another option.
Option 4
New Format Type of the FORMAT UNIT command is used for the fast re-format
operation.
Best Regards,
Kenji Tokumitsu
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From mou_huang at goCyberlink.com  Wed Jun 21 20:09:19 2006
From: mou_huang at goCyberlink.com (Mou Huang)
Date: Thu, 22 Jun 2006 11:09:19 +0800
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.549.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r060621c_f.htm">HTML-formatted message</A>

Hi Katata-san,
Thank you very much for your prompt response.
>> Do you request the null data writing on the entire RW-DL disc at the
default
>> type (Formatting on Format Type = 00h)? Why do you need it always?
No. We only want to make sure the Format Type 13h (Quick Grow) won't
overwrite 
the recorded user data area.
Regarding the Format Type 00h, we don't care whether drives will overwrite
the 
recorded user data area or not. It's up to drive vendors' implementations.
That's why we'd like to choose option 2.
Thanks a lot.
Best Regards,
Mou 
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com]On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Thursday, June 22, 2006 10:42 AM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: RE: Question for RW-DL fast re-format
Thank you Mou,
May I confirm your requirement?
Do you request the null data writing on the entire RW-DL disc at the default
type (Formatting on Format Type = 00h)? Why do you need it always?
RW-DL format operation does not verify the user data area. Because it does
not
have hardware defect management.
Best regards,
Keiji Katata
PIONEER CORP.
"Mou Huang" <mou_huang at goCyberlink.com>@avc-pioneer.com on 2006/06/21
18:26:54
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(J
$BAw?.<T(J:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(J:  <mtfuji5 at avc-pioneer.com>
cc:    <t10 at t10.org>
bcc:
$B7oL>(J:  RE: Question for RW-DL fast re-format
Dear Katata-san,
As regards the question "2. Question about re-format operation of Mt. Fuji
specification",
we CyberLink would like to choose the option 2:
2. Format type Grow Session (11h) and Quick Grow (13h) shall not modify
??? the recorded user data area. Other format type behavior is vender
specific.
To us, the Quick Grow (13h) is enough.
If the Fast Re-format is mandatory, we hope that drive vendors can support
format type 13h.
If it's optional, we suggest to add one flag "Fast Re-format" at bit 5 of
byte 4
in the
"Feature 002Ch: Rigid Restricted Overwrite Feature Descriptor" so that we can
know whether
the Fast Re-format is supported or not.
When it's "1b", then format type 13h should be supported for DVD-RW DL Fast
Re-Format;
When it's "0b", then Fast Re-format is not supported.
What do you think?
Thanks a lot.
Best Regards,
Mou Huang
CyberLink Corp.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com]On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Tuesday, June 13, 2006 3:59 PM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: Question for RW-DL fast re-format
Hello all,
This is an action item of June meeting.
Please send your selection and commnet by June 21 (if possible).
Best regards,
Keiji Katata
PIONEER CORP.
(See attached file: Question fast re-format.pdf)
?<< File: Question fast re-format.pdf >>
This correspondence is from Cyberlink Corp. and is  intended only for use by
the
recipient named herein, and may contain privileged,  proprietary and/or
confidential information, and is intended only to be seen and  used by named
addressee(s). You are notified that any discussion, dissemination, 
distribution
or copying of this correspondence and any attachments, is strictly 
prohibited,
unless otherwise authorized or consented to in writing by the  sender. If you
have received this correspondence in error, please notify the  sender
immediately, and please permanently delete the original and any copies of  it
and any attachment and destroy any related printouts without reading or 
copying
them.
This correspondence is from Cyberlink Corp. and is intended only for use by
the recipient named herein, and may contain privileged, proprietary and/or
confidential information, and is intended only to be seen and used by named
addressee(s). You are notified that any discussion, dissemination,
distribution or copying of this correspondence and any attachments, is
strictly prohibited, unless otherwise authorized or consented to in writing
by the sender. If you have received this correspondence in error, please
notify the sender immediately, and please permanently delete the original and
any copies of it and any attachment and destroy any related printouts without
reading or copying them.


From mou_huang at goCyberlink.com  Wed Jun 21 20:51:00 2006
From: mou_huang at goCyberlink.com (Mou Huang)
Date: Thu, 22 Jun 2006 11:51:00 +0800
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.550.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r060621d_f.htm">HTML-formatted message</A>

Hello Katata-san,
>> [Question to software venders]
>> The RW-DL physical format allows pre-formatted media by the media
manufacture.
>> If software does not use the Format Unit command Format Type = 00h, 
>> we can stop this discussion now.
>>
>> All software venders, how do you think? 
>> Does the software use Format Unit command?
To answer your question, we CyberLink use the Format Unit command 
but we don't use the Format Type 00h on DVD-RW (SL/DL) disc.
FYR.
Best Regards,
Mou Huang
CyberLink Corp.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com]On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Thursday, June 22, 2006 10:42 AM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: RE: Question for RW-DL fast re-format
Thank you everyone.
I would like to write my comment one by one.
[Answer to question]
Mt.Fuji group did not discuss the change of the DVD-RW SL (Single Layer)
Format
Unit Command. There is no change in other media types (DVD-RAM, +RW, etc.)
RW-DL is new media. So I think Pioneer proposal does not change of the drive
behavior.
[Comment as a chair]
I understand that you do not desire the device behavior which cannot be
checked.
[Comment as Pioneer]
We need to focus the behavior of the default type (Formatting on Format Type
=
00h). Full format of the DVD-RW DL will take more than 1 hour. User never
accept
this long time.
The other hands, 2 hours - 6 hours TV recording on the RW-DL disc may fill
the
disc up. Once it becomes ROM compatible state (Complete state), another full
format is not necessary.
For example, BD-RE drive dose not fill data area up with null data of the RE
disc by the default format operation. Drive changes Defect List only. If
there
was no linear replacement (no defect), host can read user data on the RE disc
before file system re-construction. Usually file system re-construction makes
the old user data unreadable.
[Question to software venders]
The RW-DL physical format allows pre-formatted media by the media
manufacture.
If software does not use the Format Unit command Format Type = 00h, we can
stop
this discussion now.
All software venders, how do you think? Does the software use Format Unit
command?
Best regards,
Keiji Katata
PIONEER CORP.
"David Burg" <daviburg at windows.microsoft.com>@avc-pioneer.com on 2006/06/21
07:22:12
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(J
$BAw?.<T(J:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(J:  <mtfuji5 at avc-pioneer.com>
cc:    <t10 at t10.org>
bcc:
$B7oL>(J:  RE: Question for RW-DL fast re-format
Hello,
Thank you for this host consultation.
We checked this issue at Microsoft optical platform storage and core
file system services.
Most important is we do not want to change existing format code
behavior. Per consistency with DVD-RW SL, existing format code behavior
shall be unchanged. Otherwise it would cause unexpected behavior in our
software. If new format behavior is desired, it needs to be with a new
format code or option.
Also, we do not want vendor specific implementations. If there is a
feature, please make it mandatory. If it is not possible, at least
specify the feature *and the feature availability recognition*.
Please let us know if further clarification is needed.
Best regards,
David Burg,
Research Software Development Engineering Lead,
Microsoft.
This correspondence is from Cyberlink Corp. and is intended only for use by
the recipient named herein, and may contain privileged, proprietary and/or
confidential information, and is intended only to be seen and used by named
addressee(s). You are notified that any discussion, dissemination,
distribution or copying of this correspondence and any attachments, is
strictly prohibited, unless otherwise authorized or consented to in writing
by the sender. If you have received this correspondence in error, please
notify the sender immediately, and please permanently delete the original and
any copies of it and any attachment and destroy any related printouts without
reading or copying them.


From ai.takaharu at jp.panasonic.com  Wed Jun 21 20:45:58 2006
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Thu, 22 Jun 2006 12:45:58 +0900
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.551.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
Hello Katata-san,
>May I confirm your opinion? You prefer Option 2?
Almost yes. Option 2 with my suggestion.
>[Comment as Pioneer]
>Pioneer proposal is not new idea. BD-RE drive does not write user data area
at
>the default format operation of RE disc. I think it is same reason that 1
hour
>operation time is not acceptable.
You are wrong. MMC does not prohibit to overwrite something on the user
data area on BD-RE for Format Type=00h, altough no vendor won't do that.
But Pioneer's proposal tries to prohibit from doing that.
Best Regards,
Harry Ai
VEBU
Panasonic AVC Networks Company
Matsushita/Panasonic
Osaka, Japan
---------------- Start of the original message ----------------
>From: keiji_katata at post.pioneer.co.jp
>To: mtfuji5 at avc-pioneer.com
>Cc: t10 at t10.org
>Date: Thu, 22 Jun 2006 11:30:01 +0900
>Subject: Re: Question for RW-DL fast re-format
>
>
>Thank you Ai san,
>
>May I confirm your opinion? You prefer Option 2?
>
>[Comment as Pioneer]
>Pioneer proposal is not new idea. BD-RE drive does not write user data area
at
>the default format operation of RE disc. I think it is same reason that 1
hour
>operation time is not acceptable.
>
>Best regards,
>
>Keiji Katata
>PIONEER CORP.
>
>
>
>
>
>Takaharu Ai <ai.takaharu at jp.panasonic.com>@avc-pioneer.com on 2006/06/21
>10:03:43
>
>mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
>
>$BAw?.<T(B:	   owner-mtfuji5 at avc-pioneer.com
>
>
>
>
>$B08 at h(B:  mtfuji5 at avc-pioneer.com, t10 at t10.org
>cc:
>bcc:
>$B7oL>(B:  Re: Question for RW-DL fast re-format
>
>
>Hello David,
>
>One of the most important issues Pioneer proposed and Chair wanted to
>gather the opinion of each company is that the Standard can prohibit the
>Logical Unit from doing something during a command although it has not
>been prohibited in the prior version of the standard.
>
>
>According to Pioneer's proposal, although it is not the documented
>proposal, it is prohibited from overwriting a part or whole of the user
>data area by FORMAT UNIT command with Format type=00h, i.e. Full format,
>for DVD-RW DL disc.
>The reason they explained was that some of the software vendors wanted
>to preserve the recorded user data through the format process. They said
>that a software which can write and append data to the incomplete DVD-RW
>disc. But another company requested that they need the method to convert
>the incomplete state to complete state without no recorded data
>modification.
>
>So, Pioneer proposed that the Full format *SHALL* not overwrite data to
>the recorded user data area.
>
>But the current Mt.Fuji and MMC does not prohibit from doing that. So,
>it is possible that the Logical Unit overwrite some of the user data
>area for the security reason or other purpose. This behavior does not
>impact to the execution time of the Full format process. We think
>Pioneer's proposal deny this freedom of the implementation.
>
>
>We understand Pioneer's concern for the execution time of the Full
>format for DVD-RW DL disc, because the DVD-RW DL have a new feature
>which makes the re-formatting function for the recorded disc very fast.
>
>We think that function is very important and we believe no drive vendor want
>to spoil this function. So no one implement the Full format very slow,
>even if Mt.Fuji/MMC does not prohibit.
>
>Our proposal is to add an recommendation that the drive should not
>overwrite all the user data area where is requested to be formatted by
>Full format of FORMAT UNIT command for DVD-RW DL disc during the
>formatting process.
>
>
>If a software vendor want make the incomplete state DVD-RW DL disc to
>complete sate without no modification of the recorded user data through
>the formatting process, we already have this function as Grow format.
>Grow format is not the mandatory function for DVD-RW SL, but we can make
>it a mandatory function for DVD-RW DL. This function can also be defined
>as a fast re-format operation.
>
>
>
>
>Best Regards,
>
>Harry Ai
>VEBU
>Panasonic AVC Networks Company
>Matsushita/Panasonic
>Osaka, Japan
>
>
----------------- End of the original message -----------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Wed Jun 21 21:30:14 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 22 Jun 2006 13:30:14 +0900
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.552.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Ai san, I understood your remark.
So there is no trouble if we use same way as BD-RE.
Best regards,
Keiji Katata
PIONEER CORP.
Takaharu Ai <ai.takaharu at jp.panasonic.com>@avc-pioneer.com on 2006/06/22
12:45:58
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B:  mtfuji5 at avc-pioneer.com, t10 at t10.org
cc:
bcc:
$B7oL>(B:  Re: Question for RW-DL fast re-format
Hello Katata-san,
>May I confirm your opinion? You prefer Option 2?
Almost yes. Option 2 with my suggestion.
>[Comment as Pioneer]
>Pioneer proposal is not new idea. BD-RE drive does not write user data area
at
>the default format operation of RE disc. I think it is same reason that 1
hour
>operation time is not acceptable.
You are wrong. MMC does not prohibit to overwrite something on the user
data area on BD-RE for Format Type=00h, altough no vendor won't do that.
But Pioneer's proposal tries to prohibit from doing that.
Best Regards,
Harry Ai
VEBU
Panasonic AVC Networks Company
Matsushita/Panasonic
Osaka, Japan
---------------- Start of the original message ----------------
>From: keiji_katata at post.pioneer.co.jp
>To: mtfuji5 at avc-pioneer.com
>Cc: t10 at t10.org
>Date: Thu, 22 Jun 2006 11:30:01 +0900
>Subject: Re: Question for RW-DL fast re-format
>
>
>Thank you Ai san,
>
>May I confirm your opinion? You prefer Option 2?
>
>[Comment as Pioneer]
>Pioneer proposal is not new idea. BD-RE drive does not write user data area
at
>the default format operation of RE disc. I think it is same reason that 1
hour
>operation time is not acceptable.
>
>Best regards,
>
>Keiji Katata
>PIONEER CORP.
>
>
>
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kenji-tokumitsu at hlds.co.jp  Wed Jun 21 19:58:45 2006
From: kenji-tokumitsu at hlds.co.jp (=?iso-2022-jp?B?VG9rdW1pdHN1IEtlbmppKBskQkZBOHc3cjtKGyhCKQ==?=)
Date: Thu, 22 Jun 2006 11:58:45 +0900
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.553.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* =?iso-2022-jp?B?VG9rdW1pdHN1IEtlbmppKBskQkZBOHc3cjtKGyhCKQ==?=
<kenji-tokumitsu at hlds.co.jp>
*
Katata-san:
In my understanding, the Fast re-format ("shall not modify the recorded user
data area") is new definition.
So, I prefer new Format Type.
The operation of the default type (Formatting on Format Type = 00h) is vendor
specific.
Some drive may work as "Fast re-format", some drive may modify the recorded
user data area. I think it is the implementation matter.
Best Regards,
Kenji Tokumitsu
Hitachi-LG Data Storage, Inc
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Thursday, June 22, 2006 11:42 AM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: RE: Question for RW-DL fast re-format
Tokumitsu san, if possible, let me know how the default type (Formatting on
Format Type = 00h) shall work?
Best regards,
Keiji Katata
PIONEER CORP.
Tokumitsu Kenji($BFA8w7r;J(J) <kenji-tokumitsu at hlds.co.jp>@avc-pioneer.com
on
2006/06/21 08:05:15
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(J
$BAw?.<T(J:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(J:  <mtfuji5 at avc-pioneer.com>
cc:    <t10 at t10.org>
bcc:
$B7oL>(J:  RE: Question for RW-DL fast re-format
Katata-san:
I prefer another option.
Option 4
New Format Type of the FORMAT UNIT command is used for the fast re-format
operation.
Best Regards,
Kenji Tokumitsu
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From support at terabyteunlimited.com  Thu Jun 22 00:24:02 2006
From: support at terabyteunlimited.com (David F.)
Date: Thu, 22 Jun 2006 00:24:02 -0700
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.554.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "David F." <support at terabyteunlimited.com>
*
It seems obvious to me that a "full format" should be a "full format" and
not something else so either a new format type or format sub-type would make
the most sense.
6.5.4.2.1 Format Type = 00h (Full Format)
Formatting the entire media is specified.
Ultimately the host simply wants to have the drive quickly and reliable
write and read data to/from the media without a bunch of hassle.  Keeping
the commands consistent between media types helps reduce hassle.
Regards,
--
David F.
TeraByte Unlimited
http://www.terabyteunlimited.com
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf
> Of Tokumitsu Kenji(????)
> Sent: Wednesday, June 21, 2006 7:59 PM
> To: mtfuji5 at avc-pioneer.com
> Cc: t10 at t10.org
> Subject: RE: Question for RW-DL fast re-format
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> *
> =?iso-2022-jp?B?VG9rdW1pdHN1IEtlbmppKBskQkZBOHc3cjtKGyhCKQ==?=
>  <kenji-tokumitsu at hlds.co.jp>
> *
> Katata-san:
>
> In my understanding, the Fast re-format ("shall not modify
> the recorded user data area") is new definition.
> So, I prefer new Format Type.
>
> The operation of the default type (Formatting on Format Type
> = 00h) is vendor specific.
> Some drive may work as "Fast re-format", some drive may
> modify the recorded user data area. I think it is the
> implementation matter.
>
> Best Regards,
>
> Kenji Tokumitsu
> Hitachi-LG Data Storage, Inc
>
> -----Original Message-----
> From: owner-mtfuji5 at avc-pioneer.com
> [mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of
> keiji_katata at post.pioneer.co.jp
> Sent: Thursday, June 22, 2006 11:42 AM
> To: mtfuji5 at avc-pioneer.com
> Cc: t10 at t10.org
> Subject: RE: Question for RW-DL fast re-format
>
>
> Tokumitsu san, if possible, let me know how the default type
> (Formatting on Format Type = 00h) shall work?
>
> Best regards,
>
> Keiji Katata
> PIONEER CORP.
>
>
>
>
>
> Tokumitsu Kenji($BFA8w7r;J(B)
<kenji-tokumitsu at hlds.co.jp>@avc-pioneer.com on
> 2006/06/21 08:05:15
>
> mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
>
> $BAw?.<T(B:     owner-mtfuji5 at avc-pioneer.com
>
>
>
>
> $B08 at h(B:  <mtfuji5 at avc-pioneer.com>
> cc:	 <t10 at t10.org>
> bcc:
> $B7oL>(B:  RE: Question for RW-DL fast re-format
>
>
> Katata-san:
>
> I prefer another option.
>
> Option 4
> New Format Type of the FORMAT UNIT command is used for the
> fast re-format operation.
>
> Best Regards,
>
> Kenji Tokumitsu
>
>
>
>
>
>
>
>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Thu Jun 22 08:25:17 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Thu, 22 Jun 2006 09:25:17 -0600
Subject: SAS-2 Zoning Management Telecon Tuesday June 27 9:00a MDT
Message-ID: <mailman.555.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606221_f.htm">HTML-formatted message</A>

SAS-2 Zoning Management Teleconference
Date: Tuesday, June 27, 2006 
Time: 9:00 am, Mountain Daylight Time (8:00 am PDT, 10:00 am CDT, 11:00 am
EDT)
Duration: 2 hours
Audio Information:
Toll-free: 1-800-531-5745 or Direct: 1-719-955-2349
Passcode: 719-533-7560
Webex Information:
Topic: SAS Zoning Management Teleconference 
Meeting number: 572 470 609 
Meeting password: sas2config 
Please click the following link to see more information, or to join the
meeting. 
NEW USER? Prepare your computer in advance of the meeting by clicking New
User on the navigation bar. 
<https://lsilogic.webex.com/lsilogic/j.php?ED=89923512&UID=46277227> 
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907


From MOverby at nvidia.com  Thu Jun 22 14:06:23 2006
From: MOverby at nvidia.com (Mark Overby)
Date: Thu, 22 Jun 2006 14:06:23 -0700
Subject: SAT WG minutes posted
Message-ID: <mailman.556.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606222_f.htm">HTML-formatted message</A>

For the WG meeting on Monday June 19, 2006.
06-287r0
Thanks.
-----------------------------------------------------------------------------
------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.	If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------
------


From Alvin.Cox at seagate.com  Fri Jun 23 11:51:36 2006
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Fri, 23 Jun 2006 13:51:36 -0500
Subject: SAS PHY teleconference minutes posted and meeting reminder for 6/29
Message-ID: <mailman.557.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606230_f.htm">HTML-formatted message</A>

The minutes of the 6/23 teleconference are posted at:
http://www.t10.org/ftp/t10/document.06/06-296r0.pdf
Please review these minutes for our next call on Thursday, June 29. 
Several action items are listed and highlighted by bullets or bold type. 
We would like to close the SSC and speed negotiation issues at the July 
T10 meeting if at all possible. There will also be a conerence call on 
July 6.
Next conference call June 29, 2006 
PARTICIPANT INFORMATION: 
Toll Free Dial in Number: (866) 279-4742 
International Access/Caller Paid Dial In Number: (309) 229-0118 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate 
Topic: SAS-2 PHY WG 
Date: Thursday, June 29, 2006 
Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago) 
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809


From lohmeyer at t10.org  Sat Jun 24 23:02:25 2006
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 25 Jun 2006 00:02:25 -0600
Subject: Recent T10 documents uploaded since 2006/06/18
Message-ID: <mailman.558.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SSC-3 Physical Device Model
(by: Paul Suhler)
T10/05-049r3   Uploaded: 2006/06/20   148982 bytes
ftp://ftp.t10.org/t10/document.05/05-049r3.pdf
SAS-2 SMP Lists (DISCOVER LIST)
(by: Steve Johnson)
T10/06-037r7   Uploaded: 2006/06/21   112802 bytes
ftp://ftp.t10.org/t10/document.06/06-037r7.pdf
SAS-2 Expander Routing Table (REPORT EXPANDER ROUTE TABLE)
(by: Steve Johnson)
T10/06-078r3   Uploaded: 2006/06/21   90988 bytes
ftp://ftp.t10.org/t10/document.06/06-078r3.pdf
SAS-2 Expander Routing Table (REPORT EXPANDER ROUTE TABLE)
(by: Steve Johnson)
T10/06-078r4   Uploaded: 2006/06/22   91043 bytes
ftp://ftp.t10.org/t10/document.06/06-078r4.pdf
SAT revision 8 letter ballot comment resolution as of SATr08
(by: Robert Sheffield)
T10/06-121r2   Uploaded: 2006/06/24   6715609 bytes
ftp://ftp.t10.org/t10/document.06/06-121r2.fdf
SAT revision 8 letter ballot comment resolution as of SATr08
(by: Robert Sheffield)
T10/06-121r2   Uploaded: 2006/06/24   6467985 bytes
ftp://ftp.t10.org/t10/document.06/06-121r2.pdf
SAS-2 Allow table-to-table expander attachment
(by: Rob Elliott)
T10/06-189r2   Uploaded: 2006/06/19   588337 bytes
ftp://ftp.t10.org/t10/document.06/06-189r2.pdf
SAS-2 Add expander change count to most SMP functions
(by: Rob Elliott)
T10/06-197r3   Uploaded: 2006/06/24   135130 bytes
ftp://ftp.t10.org/t10/document.06/06-197r3.pdf
SSC-3: Add Encrypted Write Command proposal
(by: Gideon Avida)
T10/06-207r1   Uploaded: 2006/06/22   50276 bytes
ftp://ftp.t10.org/t10/document.06/06-207r1.pdf
SAS-2 Restrict access to SMP write functions
(by: Rob Elliott)
T10/06-208r2   Uploaded: 2006/06/24   29477 bytes
ftp://ftp.t10.org/t10/document.06/06-208r2.pdf
SAS-2 REPORT GENERAL additions for zoning and self configuration
(by: Steve Johnson)
T10/06-213r2   Uploaded: 2006/06/21   70274 bytes
ftp://ftp.t10.org/t10/document.06/06-213r2.pdf
SAT - Block Mapping Issues
(by: Robert Sheffield)
T10/06-216r1   Uploaded: 2006/06/22   354008 bytes
ftp://ftp.t10.org/t10/document.06/06-216r1.pdf
ADC-2: Fix bridging reservations and other stuff
(by: Paul Entzel)
T10/06-261r0   Uploaded: 2006/06/23   31873 bytes
ftp://ftp.t10.org/t10/document.06/06-261r0.pdf
SAS-2 Spread-spectrum clocking
(by: Rob Elliott)
T10/06-263r2   Uploaded: 2006/06/22   137956 bytes
ftp://ftp.t10.org/t10/document.06/06-263r2.pdf
Minutes of SAT Working Group - June 7 - 8, 2006
(by: Mark Overby)
T10/06-277r0   Uploaded: 2006/06/19   124462 bytes
ftp://ftp.t10.org/t10/document.06/06-277r0.pdf
SAS-2 Enable and disable zoning
(by: Rob Elliott)
T10/06-281r0   Uploaded: 2006/06/19   159887 bytes
ftp://ftp.t10.org/t10/document.06/06-281r0.pdf
SAS-2 Zone Management Models
(by: Tim Symons)
T10/06-285r0   Uploaded: 2006/06/19   52708 bytes
ftp://ftp.t10.org/t10/document.06/06-285r0.pdf
Minutes of SAT Working Group, June 19, 2006
(by: Mark Overby)
T10/06-287r0   Uploaded: 2006/06/22   119418 bytes
ftp://ftp.t10.org/t10/document.06/06-287r0.pdf
SAS-2 SMP ACTIVATE ZONE PERMISSION UPDATE functions
(by: Tim Symons)
T10/06-288r0   Uploaded: 2006/06/20   47090 bytes
ftp://ftp.t10.org/t10/document.06/06-288r0.pdf
SAS-2 CONFIGURE & REPORT  ZONE MANAGEMENT CLIENT ADDRESS functions
(by: Tim Symons)
T10/06-289r0   Uploaded: 2006/06/20   66158 bytes
ftp://ftp.t10.org/t10/document.06/06-289r0.pdf
Minutes of SAS Zoning Management Working Group - June 20, 2006
(by: Ralph O. Weber)
T10/06-290r0   Uploaded: 2006/06/21   16544 bytes
ftp://ftp.t10.org/t10/document.06/06-290r0.htm
Minutes of SAS Zoning Management Working Group - June 20, 2006
(by: Ralph O. Weber)
T10/06-290r0   Uploaded: 2006/06/21   78897 bytes
ftp://ftp.t10.org/t10/document.06/06-290r0.pdf
SAT- ATA PASS-THROUGH additional sense code and other clarifications
(by: Robert Sheffield)
T10/06-291r0   Uploaded: 2006/06/21   103823 bytes
ftp://ftp.t10.org/t10/document.06/06-291r0.pdf
SAT- ATA PASS-THROUGH additional sense code and other clarifications
(by: Robert Sheffield)
T10/06-291r1   Uploaded: 2006/06/24   152274 bytes
ftp://ftp.t10.org/t10/document.06/06-291r1.pdf
Minutes: SSC-3 NIST Key wrapping Phone call
(by: Kevin Butt)
T10/06-292r0   Uploaded: 2006/06/21   36634 bytes
ftp://ftp.t10.org/t10/document.06/06-292r0.pdf
SSC-3: Modification of the REPEAT bit behavior in the Tape Diagnostic
Data log
(by: Veronica Hernandez and Kevin Marks)
T10/06-293r0   Uploaded: 2006/06/21   17122 bytes
ftp://ftp.t10.org/t10/document.06/06-293r0.pdf
ADT-2 More logout reasons
(by: Paul Entzel)
T10/06-294r0   Uploaded: 2006/06/22   13754 bytes
ftp://ftp.t10.org/t10/document.06/06-294r0.pdf
SAS-2 speed negotiation
(by: Amr Wassal and Robert Watson)
T10/06-295r0   Uploaded: 2006/06/23   240335 bytes
ftp://ftp.t10.org/t10/document.06/06-295r0.pdf
Minutes of SAS Physical Working Group teleconference, June 23, 2006
(by: Alvin Cox)
T10/06-296r0   Uploaded: 2006/06/23   35887 bytes
ftp://ftp.t10.org/t10/document.06/06-296r0.pdf
Summary of T10 Activities to ISO/IEC SC 25 / WG 4
(by: John Lohmeyer)
T10/06-297r0   Uploaded: 2006/06/23   135227 bytes
ftp://ftp.t10.org/t10/document.06/06-297r0.pdf
SPC-4 Persistent Reservations correction
(by: Ralph O. Weber)
T10/06-298r0   Uploaded: 2006/06/23   185351 bytes
ftp://ftp.t10.org/t10/document.06/06-298r0.pdf
Working Drafts
--------------
SCSI / ATA Translation
(Editor: Bob Sheffield)
 Rev: 08a      Uploaded: 2006/06/24   1330648 bytes
ftp://ftp.t10.org/t10/drafts/sat/sat-r08a.pdf
(Report generated on 2006/06/25 at 00:02:24)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Elliott at hp.com  Sun Jun 25 17:02:00 2006
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Sun, 25 Jun 2006 19:02:00 -0500
Subject: SAS-2 revision 4a now available
Message-ID: <mailman.559.1441607309.22510.t10@sandbox.t10.org>

Attachment #1: <A HREF="r0606251_smime.p7s">smime.p7s</A>

Serial Attached SCSI - 2 (SAS-2) revision 4a (sas2r04a) is now available on
http://www.t10.org/drafts.htm and http://www.t10.org/new.htm, incorporating
proposals recommended by the June SAS zoning WG (but not yet approved
by a T10 plenary).
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott


From curtis.ballard at hp.com  Sun Jun 25 21:27:12 2006
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Mon, 26 Jun 2006 00:27:12 -0400
Subject: T10/06-046r4 SMC-3 Report Supported Medium Types posted
Message-ID: <mailman.560.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
*
The latest version of the "Report Supported Medium Types" proposal,
06-046r4, has been posted to the t10 web site.
Curtis Ballard
Hewlett Packard
-----Original Message-----
From: jlohmeye at scsibbs.co.lsil.com [mailto:jlohmeye at scsibbs.co.lsil.com]
On Behalf Of T10 Document Administrator
Sent: Sunday, June 25, 2006 10:25 PM
To: Ballard, Curtis C (StorageWorks)
Subject: Re: Re: T10 Document Number Assigned (T10/06-046r4)
2006/06/25 22:24:53 
Your request to upload a file or files to the T10 site has been
accepted.
Your PDF file will be posted at:
   http://www.t10.org/ftp/t10/document.06/06-046r4.pdf
Normally, the posting/archiving process takes about 30 minutes.
Please contact John Lohmeyer <lohmeyer at t10.org>
should you need further assistance.
curtis.ballard at hp.com wrote:
> Date: Sun Jun 25 22:23:35 2006
> From: curtis.ballard at hp.com
> To: T10 Document Administrator via web upload <docs at t10.org>
> Subject: Re: T10 Document Number Assigned (T10/06-046r4)
> 
> T10 document upload details:
> 
>   Document Number: T10/06-046r4
>	Upload Code: AC_02098xnAsoqf6wh
>     Document_Date: 2006/06/25
>   Document_Author: Curtis Ballard
>    Document_Title: SMC-3 Report Supported Medium Types
>    Meeting_Agenda: none
> Document_Comments: <none>
>      Other_Number: <none>
>	  Post_File: pdf
> 
> ## COPYRIGHT POLICY
> ## ----------------
> ##
> ## Do not submit documents containing a copyright statement
> ## unless you add the following statement:
> ##
> ##	Permission is granted to members of INCITS, its technical
> ##	committees and their associated task groups to reproduce
> ##	this document for the purposes of INCITS standardization
> ##	activities, provided this notice is included.
> ##
> ## If you upload a copyrighted document, with or without
> ## this statement, it will be assumed implicitly that you
> ## and your organization have given the above permission.
> ##
> ##
> ## APPROPRIATE CONTENT
> ## -------------------
> ##
> ## Do not upload inappropriate material.  If you do, your
> ## files will be removed and your posting privileges will
> ## be revoked.
> 
> Attachment Converted: "D:\T10\ATTACH\06-046r4.pdf"
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From shunsuke.kimura at toshiba.co.jp  Mon Jun 26 07:53:47 2006
From: shunsuke.kimura at toshiba.co.jp (Shunsuke Kimura)
Date: Mon, 26 Jun 2006 23:53:47 +0900
Subject: Updated draft for HD DVD-R DL
Message-ID: <mailman.561.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Shunsuke Kimura <shunsuke.kimura at toshiba.co.jp>
*
Dear all,
Toshiba prepared the updated draft for HD DVD-R DL.
I asked Pioneer to upload the draft to Mt.Fuji FTP site just now.
Please confirm the new draft later.
The revised points are as follows;
1. Writing data on L1
The WRITE command which intends to write data on L1 is allowed 
even if Guard Track Zone is not padded by issuing Format Unit command (Format
code = 17h). 
In this case, the drive shall pad Guard Track Zone automatically.
This issue is a request from the software vender.
2. Middle Area expansion
Format code (READ/SEND DISC STRUCTURE command) is changed from 25h to 20h.
If you have any comments, please send your comment to reflector. 
Best Regards,
Shunsuke Kimura
TOSHIBA
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From robert.l.sheffield at intel.com  Mon Jun 26 08:26:37 2006
From: robert.l.sheffield at intel.com (Sheffield, Robert L)
Date: Mon, 26 Jun 2006 08:26:37 -0700
Subject: SAT revision 8a now available
Message-ID: <mailman.562.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606261_f.htm">HTML-formatted message</A>

SCSI / ATA Translation (SAT) revision 8a (sat-r08a.pdf) is now available
on http://www.t10.org/drafts.htm <http://www.t10.org/drafts.htm&gt;  and
http://www.t10.org/new.htm <http://www.t10.org/new.htm&gt; .
The direct link is http://www.t10.org/ftp/t10/drafts/sat/sat-r08a.pdf.
SAT revision 8a incorporates 963 letter ballot comment resolutions
identified with status "Completed" as documented in 06-121r2, "SAT
revision 8 letter ballot comment resolution as of SATr08"
(http://www.t10.org/ftp/t10/document.06/06-121r2.pdf).
Two proposals listed below incorporate resolutions to most of the
remanining letter ballot comments:
*	06-216r1 SAT - Block Mapping Issues
http://www.t10.org/ftp/t10/document.06/06-216r1.pdf
*	06-291r1 SAT- ATA PASS-THROUGH additional sense code and other
clarifications http://www.t10.org/ftp/t10/document.06/06-291r1.pdf
There are some 70 letter ballot comments marked with the term "DISCUSS"
to be addressed in the July SAT WG that are neither incorporated into
the latest draft nor in the two propoposals listed above. Those
remaining LB comments relate to the TEST UNIT READY command translation,
the READ/WRITE BUFFER commands, the REQUEST SENSE command, the SEND
DIAGNOSTIC self-test function, START STOP UNIT (SLEEP, vs STANDBY, vs
STANDBY IMMEDIATE), and a handful of scattered comments that are mostly
editorial.
Bob Sheffield


From lohmeyer at t10.org  Mon Jun 26 13:06:45 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Mon, 26 Jun 2006 14:06:45 -0600
Subject: Fwd: Third Call for Volunteers - Convener, JTC 1/SC 25/WG 4 -
  Interconnection of Computer Systems and Attached Equipment
Message-ID: <mailman.563.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606262_f.htm">HTML-formatted message</A>

A volunteer has come forward, but not before the second call closed. So this
call is being made just in case someone else cares to volunteer. -- John
>in060743 
>
>INCITS
>InterNational Committee for Information Technology Standards 
>INCITS Secretariat, Information Technology Industry Council (ITI) 
>1250 Eye St. NW, Suite 200, Washington, DC 20005 
>Telephone 202-737-8888; Fax 202-638-4922
>
>----------
>
>  
>
>ACTION REQUESTED 
>
> 
>
>Date:
>
>June 26, 2006
>
>Responses Due:
>
>July 26, 2006
>
>Replaces:
>
>in060487
>
>Reply to:
>
>Jennifer Garner
>
>Phone:
>
>(202) 626-5737
>
>Email:
>
>jgarner at itic.org
>
> 
>
> 
>
>To:
>
>Mr. John Lohmeyer and Mr. Robert Snively - For Distribution to the Members
of the US TAG to JTC 1/SC 25/WG 4
>INCITS Executive Board Members - For Information
>
>Subject:
>
>Third Call for Volunteers - Convener, JTC 1/SC 25/WG 4 - Interconnection of
Computer Systems and Attached Equipment 
>
>----------
>
>In anticipation of the expiration of the term of the current JTC 1/SC 25/WG
4 Convener, Mr. Gary Robinson, following the September 2006 JTC 1/SC 25
Plenary, two call for volunteers to serve as the US candidate for JTC 1/SC
25/WG 4 Convener were issued to the members of INCITS/10 and T11 and closed
without response.
>
>A candidate has come forward, and this third call for volunteers to serve as
the US candidate for JTC 1/SC 25/WG 4 Convener is being issued to the members
of INCITS/10 and T11 to identify a US candidate for endorsement and will
close on July 26, 2006. 
>
>Any member of the US TAG meeting the requirements set forth below is welcome
to volunteer to serve. Before one considers doing so, however, the commitment
in time and responsibilities should be considered. Officers must actively
support the administrative structure that ensures due process to all
participants, assists in reaching consensus and protects the accreditation of
the entire system. 
>
>Those willing to make this commitment must submit four written statements in
support of their candidacy: 
>    * A statement of experience, indicating the volunteer's expertise in the
subgroup's program of work, voluntary standards efforts, committee experience
and leadership abilities.  
>    * A statement indicating that the volunteer's organization is a member
in good standing of the associated US TAG. 
>    * A statement of management support for a three-year term on company
letterhead acknowledging the additional workload, financial resources and
duties required of an officer over and above that of a technical participant.
 This statement must be signed by the candidate's management and submitted on
organizational letterhead. 
>
>The statement of management support for the three-year term is a good faith
commitment, not a legal binding commitment. If future circumstances require
the applicant to resign from the office before the term has been fulfilled,
this will be accepted without prejudice. 
>    * A statement as to whether or not the candidate is a representative of
a US domiciled organization. 
>
>The statements from candidates wishing to serve in the above referenced
position should be sent to the INCITS Secretariat's attention
(jgarner at itic.org) no later than July 26, 2006. 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 
>
> 
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907


From takeshi_kohda at post.pioneer.co.jp  Mon Jun 26 17:14:04 2006
From: takeshi_kohda at post.pioneer.co.jp (takeshi_kohda at post.pioneer.co.jp)
Date: Tue, 27 Jun 2006 09:14:04 +0900
Subject: Updated draft for HD DVD-R DL
Message-ID: <mailman.564.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* takeshi_kohda at post.pioneer.co.jp
*
Dear Kimura-san,
Your updated proposal is now placed on the following url.
ftp://ftp.avc-pioneer.com/Mtfuji_7/Proposal/July06/Toshiba/
The filename is HD_DVD_R_DL.zip.
Kind regards,
---
Takeshi Kohda
2006/06/26 23:52, Shunsuke Kimura <shunsuke.kimura at toshiba.co.jp> wrote:
>
> Dear all,
>
> Toshiba prepared the updated draft for HD DVD-R DL.
> I asked Pioneer to upload the draft to Mt.Fuji FTP site just now.
> Please confirm the new draft later.
>
> The revised points are as follows;
>
> 1. Writing data on L1
> The WRITE command which intends to write data on L1 is allowed
> even if Guard Track Zone is not padded by issuing Format Unit command (Fo
> rmat code = 17h).
> In this case, the drive shall pad Guard Track Zone automatically.
> This issue is a request from the software vender.
>
> 2. Middle Area expansion
> Format code (READ/SEND DISC STRUCTURE command) is changed from 25h to 20h
> .
>
>
> If you have any comments, please send your comment to reflector.
>
>
> Best Regards,
> Shunsuke Kimura
> TOSHIBA
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From David.Peterson at mcdata.com  Tue Jun 27 10:50:52 2006
From: David.Peterson at mcdata.com (David Peterson)
Date: Tue, 27 Jun 2006 12:50:52 -0500
Subject: [T11.3] TPRLO change proposal
Message-ID: <mailman.565.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606270_f.htm">HTML-formatted message</A>

Howdy All,
I have uploaded T11/06-421v1 to the T11 web site for discussion at
today's FC-LS conf call.
Thanks...Dave
(no disclaimer)


From David.Peterson at mcdata.com  Tue Jun 27 10:50:52 2006
From: David.Peterson at mcdata.com (David Peterson)
Date: Tue, 27 Jun 2006 12:50:52 -0500
Subject: TPRLO change proposal
Message-ID: <mailman.566.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606271_f.htm">HTML-formatted message</A>

Howdy All,
I have uploaded T11/06-421v1 to the T11 web site for discussion at
today's FC-LS conf call.
Thanks...Dave
(no disclaimer)


From Alvin.Cox at seagate.com  Tue Jun 27 11:24:26 2006
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Tue, 27 Jun 2006 13:24:26 -0500
Subject: SAS PHY teleconference minutes posted and meeting reminder for 6/29
Message-ID: <mailman.567.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606272_f.htm">HTML-formatted message</A>

The minutes of the 6/23 teleconference are posted at:
http://www.t10.org/ftp/t10/document.06/06-296r0.pdf
Please review these minutes for our next call on Thursday, June 29. 
Several action items are listed and highlighted by bullets or bold type. 
We would like to close the SSC and speed negotiation issues at the July 
T10 meeting if at all possible. There will also be a conerence call on 
July 6.
Next conference call June 29, 2006 
PARTICIPANT INFORMATION: 
Toll Free Dial in Number: (866) 279-4742 
International Access/Caller Paid Dial In Number: (309) 229-0118 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate 
Topic: SAS-2 PHY WG 
Date: Thursday, June 29, 2006 
Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago) 
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809


From lohmeyer at t10.org  Tue Jun 27 12:41:12 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 27 Jun 2006 13:41:12 -0600
Subject: SAS-2 Zoning Management Telecon Thursday July 6 10:00a MDT
Message-ID: <mailman.568.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606273_f.htm">HTML-formatted message</A>

SAS-2 Zoning Management Teleconference
Date: Thursday, July 6, 2006 
Time: 10:00 am, Mountain Daylight Time (9:00 am PDT, 11:00 am CDT, 12:00 noon
EDT)
Duration: 2 hours
Audio Information:
Toll-free: 1-800-531-5745 or Direct: 1-719-955-2349
Passcode: 719-533-7560
Webex Information:
Topic: SAS Zoning Management Teleconference 
Meeting number: 571 385 391 
Meeting password: sas2config 
Please click the following link to see more information, or to join the
meeting. 
NEW USER? Prepare your computer in advance of the meeting by clicking New
User on the navigation bar. 
<https://lsilogic.webex.com/lsilogic/j.php?ED=89994137&UID=46487037> 
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907


From Alvin.Cox at seagate.com  Wed Jun 28 12:35:52 2006
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Wed, 28 Jun 2006 14:35:52 -0500
Subject: SAS PHY call on 6/29
Message-ID: <mailman.569.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606280_f.htm">HTML-formatted message</A>

Since Rob is out tomorrow, he has provided the following list of items to 
be discussed concern two of the proposals:
06-263
* is a 1/(non-power-of-two) ALIGN rate a good idea?
* separate ALIGN rates to optimize performance or just one rate for all
cases
* what is the best term to replace "clock skew management" in 7.3
* The average up-spreading cannot exactly match the average
down-spreading in an SSC profile.  How do we specify the accuracy?  Does
the ALIGN rate of
1/2048 provide enough extra ALIGNs to account for the inaccuracy?
* make sure everyone agrees with the math on the last page, and that
we're not off by a factor of 2 anywhere.
06-290
* is the frame too big or otherwise unwieldly?
* there are lots of "informative" SSC bits that are not strictly needed.
e.g. an expander must support all 3 types, an HBA 2 types, and a disk
drive
1 type or the other, so passing that along in the frame is unnecessary.
However, it might make it easier for someone using an analyzer to be
clear on where they're attached.
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809


From billmc37 at ctesc.net  Thu Jun 29 15:09:51 2006
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Thu, 29 Jun 2006 17:09:51 -0500
Subject: MMC5 Rev 3a
Message-ID: <mailman.570.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Members:
I posted version 3a of MMC-5 that addresses the letter ballot comments 
as referenced in 06-308 r0.  There is a problem that disallowed creation 
of a table of contents, but I wanted to get the content posted.  I will 
get the word processor problems fixed before the T10 meeting week.
Kind Regards.
Bill McFerrin
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Larry_Chen at pmc-sierra.com  Thu Jun 29 17:07:10 2006
From: Larry_Chen at pmc-sierra.com (Larry Chen)
Date: Thu, 29 Jun 2006 17:07:10 -0700
Subject: SAS error recovery use case - Device Server detected Data Offset 
	Error
Message-ID: <mailman.571.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606291_f.htm">HTML-formatted message</A>

Hi,
I have an SAS error recovery use case which can not
Solve by myself after reading the SAS-1.1 specification Rev 9e.
The use case scenario starts when the Device Server detects
A Data Offset Error (assume that the first of two data
Frames is dropped/lost) during a Write command.
As stated in the spec, the Device Server sets the appropriate
SCSI error message in the SSP_RESPONSE frame and sends
It to the initiator.
Ex)
Initiator						   Target
---------------SSP_Command(WRITE)-------------->
<-------------------------------ACK-------------------------
<------------------------------SSP_XFR_RDY----------
---------------------------------ACK------------------------->
--------------SSP_DATA-1---------------> DROPPED/LOST
--------------SSP-DATA-2-------------------------------->      Data Offset
Error is detected
<--------------------------------ACK-2-----------------------
<-------------SSP_RESPONSE(DATA_OFFSET_ERROR)
QUESTION-1: Can SSP_RESPONSE be sent in the same connection
Or does it need to open a new connection?
QUESTION-2: If SSP_RESPONSE is received when ACK-TOV is still
Running, is the ACK_TOV timer supposed to be cancelled? If so, can someone
Refer me to the place in the SAS spec where this is mentioned.
QUESTION-3: Does closing a connection force cancelling of all
Active timers, such as, ACK_TOV timer?
QUESTION-4: does SAS spec mention about how ACK_TOV,
DONE_TOV, AND BREAK_TOV timers interact e.g. priority, preemption?


From daviburg at windows.microsoft.com  Thu Jun 29 18:18:33 2006
From: daviburg at windows.microsoft.com (David Burg)
Date: Thu, 29 Jun 2006 18:18:33 -0700
Subject: Question for RW-DL fast re-format
Message-ID: <mailman.572.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "David Burg" <daviburg at windows.microsoft.com>
*
Dear Katata-san,
Microsoft uses both format types 10h and 15h.
Best regards,
David Burg.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Wednesday, June 21, 2006 7:42 PM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: RE: Question for RW-DL fast re-format
Thank you everyone.
I would like to write my comment one by one.
[Answer to question]
Mt.Fuji group did not discuss the change of the DVD-RW SL (Single Layer)
Format
Unit Command. There is no change in other media types (DVD-RAM, +RW, etc.)
RW-DL is new media. So I think Pioneer proposal does not change of the drive
behavior.
[Comment as a chair]
I understand that you do not desire the device behavior which cannot be
checked.
[Comment as Pioneer]
We need to focus the behavior of the default type (Formatting on Format Type
=
00h). Full format of the DVD-RW DL will take more than 1 hour. User never
accept
this long time.
The other hands, 2 hours - 6 hours TV recording on the RW-DL disc may fill
the
disc up. Once it becomes ROM compatible state (Complete state), another full
format is not necessary.
For example, BD-RE drive dose not fill data area up with null data of the RE
disc by the default format operation. Drive changes Defect List only. If
there
was no linear replacement (no defect), host can read user data on the RE disc
before file system re-construction. Usually file system re-construction makes
the old user data unreadable.
[Question to software venders]
The RW-DL physical format allows pre-formatted media by the media
manufacture.
If software does not use the Format Unit command Format Type = 00h, we can
stop
this discussion now.
All software venders, how do you think? Does the software use Format Unit
command?
Best regards,
Keiji Katata
PIONEER CORP.
"David Burg" <daviburg at windows.microsoft.com>@avc-pioneer.com on 2006/06/21
07:22:12
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(J
$BAw?.<T(J:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(J:  <mtfuji5 at avc-pioneer.com>
cc:    <t10 at t10.org>
bcc:
$B7oL>(J:  RE: Question for RW-DL fast re-format
Hello,
Thank you for this host consultation.
We checked this issue at Microsoft optical platform storage and core
file system services.
Most important is we do not want to change existing format code
behavior. Per consistency with DVD-RW SL, existing format code behavior
shall be unchanged. Otherwise it would cause unexpected behavior in our
software. If new format behavior is desired, it needs to be with a new
format code or option.
Also, we do not want vendor specific implementations. If there is a
feature, please make it mandatory. If it is not possible, at least
specify the feature *and the feature availability recognition*.
Please let us know if further clarification is needed.
Best regards,
David Burg,
Research Software Development Engineering Lead,
Microsoft.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Thu Jun 29 22:53:49 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 30 Jun 2006 14:53:49 +0900
Subject: Question for cancel method of RW-DL Format operation
Message-ID: <mailman.573.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
Thank you for your answer to my question.
My next proposal does not change the description of the default format
operation
for RW-DL media.
I have another question to members.
Full formatting of a RW-DL disc will take more than 1 hour by 2X regardless
of
IMMED bit setting.
In the case of RW-SL, we had a prospect of the higher speed data recording.
At
the beginning, Full format of RW-SL took 1 hour. Now it takes 10 min by 6X.
The other hands, the forecast of RW-DL formatting time may be 30 min by 4X.
Under this condition, I think that many of the end users should have a method
to
cancel the full format operation after it began.
In the current definition, all commands except several specials shall be
terminated with check condition "Formatting in Progress" during formatting.
Therefore user only can remove the power from the system.
I think that some method should be describe to stop the 1 hour operation.
Here is my idea.
1. use existing command
 Start Stop unit command for Stop, Eject and Sleep
2. use other existing command than No.1
3. create a new command
4. no such command or vender specific
Let me know your idea.
Best regards,
Keiji Katata
PIONEER CORP.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From sandeep.taneja at mail.nsysinc.com  Fri Jun 30 00:33:41 2006
From: sandeep.taneja at mail.nsysinc.com (sandeep taneja)
Date: 30 Jun 2006 13:03:41 +0530
Subject: queries Regarding Transport layer
Message-ID: <mailman.574.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* sandeep taneja <sandeep.taneja at mail.nsysinc.com>
*
Hello !!
Could anybody help me for solving some doubts in Transport layer.
I have few doubts regarding implementation of Transport layer state
machines.
I am referring to SAS2r03a 22 April 2006.
Following are queries :
1.How does ST_ITS state machine notify ST_IFR state machine that NAK or
ACK/NAK timeout have occurred for DATA frame corresponding to first
enable burst.Is it going to use same message as it is using for the DATA
frame corresponding to XFER_RDY frame? 
if yes, then message( Transmission complete(Data-out failed,NAK
received)corresponding to NAK & message Transmission complete(Data-out
failed,ACK/NAK Timeout)) ST_ITS uses to notify ST_IFR is given but How
ST_IFR will handle these message or notify Application layer about data
sending failure seems to be missing.
Thanks.     
-- 
--------------------------------------------
Regards
Sandeep Taneja
nSys Design Systems
Accelerating designs
http://www.nsysinc.com
--------------------------------------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From mou_huang at goCyberlink.com  Fri Jun 30 01:05:52 2006
From: mou_huang at goCyberlink.com (Mou Huang)
Date: Fri, 30 Jun 2006 16:05:52 +0800
Subject: Question for cancel method of RW-DL Format operation
Message-ID: <mailman.575.1441607309.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0606302_f.htm">HTML-formatted message</A>

Hi Katata-san,
It's really a good idea to implement such command 
so that user can stop Full Formatting operation.
But we suggest to use the existent CLOSE TRACK/SESSION 
command with the Close Function 000b to do it.
What do you think?
Thanks a lot.
Best Regards,
Mou Huang
CyberLink Corp.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com]On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Friday, June 30, 2006 1:54 PM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: Question for cancel method of RW-DL Format operation
Hello all,
Thank you for your answer to my question.
My next proposal does not change the description of the default format
operation
for RW-DL media.
I have another question to members.
Full formatting of a RW-DL disc will take more than 1 hour by 2X regardless
of
IMMED bit setting.
In the case of RW-SL, we had a prospect of the higher speed data recording.
At
the beginning, Full format of RW-SL took 1 hour. Now it takes 10 min by 6X.
The other hands, the forecast of RW-DL formatting time may be 30 min by 4X.
Under this condition, I think that many of the end users should have a method
to
cancel the full format operation after it began.
In the current definition, all commands except several specials shall be
terminated with check condition "Formatting in Progress" during formatting.
Therefore user only can remove the power from the system.
I think that some method should be describe to stop the 1 hour operation.
Here is my idea.
1. use existing command
 Start Stop unit command for Stop, Eject and Sleep
2. use other existing command than No.1
3. create a new command
4. no such command or vender specific
Let me know your idea.
Best regards,
Keiji Katata
PIONEER CORP.
This correspondence is from Cyberlink Corp. and is intended only for use by
the recipient named herein, and may contain privileged, proprietary and/or
confidential information, and is intended only to be seen and used by named
addressee(s). You are notified that any discussion, dissemination,
distribution or copying of this correspondence and any attachments, is
strictly prohibited, unless otherwise authorized or consented to in writing
by the sender. If you have received this correspondence in error, please
notify the sender immediately, and please permanently delete the original and
any copies of it and any attachment and destroy any related printouts without
reading or copying them.


From ai.takaharu at jp.panasonic.com  Fri Jun 30 01:26:08 2006
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Fri, 30 Jun 2006 17:26:08 +0900
Subject: Question for cancel method of RW-DL Format operation
Message-ID: <mailman.576.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
Hello Katata-san,
Let me confirm one thing.
What is the required or proposed disc state after the Full format is
terminated? Intermediate State, Complete State or format in progress
state?
Best Regards,
Harry Ai
VEBU
Panasonic AVC Networks Company
Matsushita/Panasonic
Osaka, Japan
---------------- Start of the original message ----------------
>From: keiji_katata at post.pioneer.co.jp
>To: mtfuji5 at avc-pioneer.com
>Cc: t10 at t10.org
>Date: Fri, 30 Jun 2006 14:53:49 +0900
>Subject: Question for cancel method of RW-DL Format operation
>
>
>Hello all,
>
>Thank you for your answer to my question.
>My next proposal does not change the description of the default format
operation
>for RW-DL media.
>
>
>I have another question to members.
>
>Full formatting of a RW-DL disc will take more than 1 hour by 2X regardless
of
>IMMED bit setting.
>In the case of RW-SL, we had a prospect of the higher speed data recording.
At
>the beginning, Full format of RW-SL took 1 hour. Now it takes 10 min by 6X.
>The other hands, the forecast of RW-DL formatting time may be 30 min by 4X.
>Under this condition, I think that many of the end users should have a
method to
>cancel the full format operation after it began.
>
>In the current definition, all commands except several specials shall be
>terminated with check condition "Formatting in Progress" during formatting.
>Therefore user only can remove the power from the system.
>
>I think that some method should be describe to stop the 1 hour operation.
>Here is my idea.
>
>1. use existing command
> Start Stop unit command for Stop, Eject and Sleep
>
>2. use other existing command than No.1
>
>3. create a new command
>
>4. no such command or vender specific
>
>Let me know your idea.
>
>Best regards,
>
>Keiji Katata
>PIONEER CORP.
>
----------------- End of the original message -----------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Fri Jun 30 01:56:50 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 30 Jun 2006 17:56:50 +0900
Subject: Question for cancel method of RW-DL Format operation
Message-ID: <mailman.577.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hi Mou, it is good idea.
By the way, why +RW does not use Stop, Eject and Sleep?
Bill, could you tell me the reason?
Best regards,
Keiji Katata
PIONEER CORP.
"Mou Huang" <mou_huang at goCyberlink.com>@avc-pioneer.com on 2006/06/30
17:05:52
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B: <mtfuji5 at avc-pioneer.com>
cc:   <t10 at t10.org>
bcc:
$B7oL>(B: RE: Question for cancel method of RW-DL Format operation
Hi Katata-san,
It's really a good idea to implement such command
so that user can stop Full Formatting operation.
But we suggest to use the existent CLOSE TRACK/SESSION
command with the Close Function 000b to do it.
What do you think?
Thanks a lot.
Best Regards,
Mou Huang
CyberLink Corp.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com]On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Friday, June 30, 2006 1:54 PM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: Question for cancel method of RW-DL Format operation
Hello all,
Thank you for your answer to my question.
My next proposal does not change the description of the default format
operation
for RW-DL media.
I have another question to members.
Full formatting of a RW-DL disc will take more than 1 hour by 2X regardless
of
IMMED bit setting.
In the case of RW-SL, we had a prospect of the higher speed data recording.
At
the beginning, Full format of RW-SL took 1 hour. Now it takes 10 min by 6X.
The other hands, the forecast of RW-DL formatting time may be 30 min by 4X.
Under this condition, I think that many of the end users should have a method
to
cancel the full format operation after it began.
In the current definition, all commands except several specials shall be
terminated with check condition "Formatting in Progress" during formatting.
Therefore user only can remove the power from the system.
I think that some method should be describe to stop the 1 hour operation.
Here is my idea.
1. use existing command
?Start Stop unit command for Stop, Eject and Sleep
2. use other existing command than No.1
3. create a new command
4. no such command or vender specific
Let me know your idea.
Best regards,
Keiji Katata
PIONEER CORP.
This correspondence is from Cyberlink Corp. and is  intended only for use by
the
recipient named herein, and may contain privileged,  proprietary and/or
confidential information, and is intended only to be seen and  used by named
addressee(s). You are notified that any discussion, dissemination, 
distribution
or copying of this correspondence and any attachments, is strictly 
prohibited,
unless otherwise authorized or consented to in writing by the  sender. If you
have received this correspondence in error, please notify the  sender
immediately, and please permanently delete the original and any copies of  it
and any attachment and destroy any related printouts without reading or 
copying
them.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Fri Jun 30 02:19:05 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 30 Jun 2006 18:19:05 +0900
Subject: Question for cancel method of RW-DL Format operation
Message-ID: <mailman.578.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hi Ai san,
The disc status may be set to the intermediate state (disc and session are
incomplete state).
Basically the RZone size and state may be return to the original size and the
state.
In the case of the full format operation with some formatting size, NWA may
be
set to the original capacity+1 (or set to 0h).
In the case of the grow format operation with some formatting size, NWA may
be
set to the original capacity+1.
Intermediate Marker shall be recorded at the reported NWA.
These are similar to the unclose disc operation.
If all user data area has been recorded already and if drive was writing
other
areas (e.g. Lead-in) the RZone state was Complete state, the RZone state
should
not be changed.
These are my current idea.
Best regards,
Keiji Katata
PIONEER CORP.
Takaharu Ai <ai.takaharu at jp.panasonic.com>@avc-pioneer.com on 2006/06/30
17:26:08
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B:  mtfuji5 at avc-pioneer.com, t10 at t10.org
cc:
bcc:
$B7oL>(B:  Re: Question for cancel method of RW-DL Format operation
Hello Katata-san,
Let me confirm one thing.
What is the required or proposed disc state after the Full format is
terminated? Intermediate State, Complete State or format in progress
state?
Best Regards,
Harry Ai
VEBU
Panasonic AVC Networks Company
Matsushita/Panasonic
Osaka, Japan
---------------- Start of the original message ----------------
>From: keiji_katata at post.pioneer.co.jp
>To: mtfuji5 at avc-pioneer.com
>Cc: t10 at t10.org
>Date: Fri, 30 Jun 2006 14:53:49 +0900
>Subject: Question for cancel method of RW-DL Format operation
>
>
>Hello all,
>
>Thank you for your answer to my question.
>My next proposal does not change the description of the default format
operation
>for RW-DL media.
>
>
>I have another question to members.
>
>Full formatting of a RW-DL disc will take more than 1 hour by 2X regardless
of
>IMMED bit setting.
>In the case of RW-SL, we had a prospect of the higher speed data recording.
At
>the beginning, Full format of RW-SL took 1 hour. Now it takes 10 min by 6X.
>The other hands, the forecast of RW-DL formatting time may be 30 min by 4X.
>Under this condition, I think that many of the end users should have a
method
to
>cancel the full format operation after it began.
>
>In the current definition, all commands except several specials shall be
>terminated with check condition "Formatting in Progress" during formatting.
>Therefore user only can remove the power from the system.
>
>I think that some method should be describe to stop the 1 hour operation.
>Here is my idea.
>
>1. use existing command
> Start Stop unit command for Stop, Eject and Sleep
>
>2. use other existing command than No.1
>
>3. create a new command
>
>4. no such command or vender specific
>
>Let me know your idea.
>
>Best regards,
>
>Keiji Katata
>PIONEER CORP.
>
----------------- End of the original message -----------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From daviburg at windows.microsoft.com  Fri Jun 30 10:44:59 2006
From: daviburg at windows.microsoft.com (David Burg)
Date: Fri, 30 Jun 2006 10:44:59 -0700
Subject: Question for cancel method of RW-DL Format operation
Message-ID: <mailman.579.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "David Burg" <daviburg at windows.microsoft.com>
*
Hello Katata-san,
Yes, this is a good idea.
I would be for 2. or 3.
Please make sure we can identify the availability of the cancellation
through some feature or feature bit.
Ideally Format cancellation should be generic and expandable to other
disc types, not just DVD-RW DL.
Best regards,
David Burg.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com
[mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of
keiji_katata at post.pioneer.co.jp
Sent: Thursday, June 29, 2006 10:54 PM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: Question for cancel method of RW-DL Format operation
Hello all,
Thank you for your answer to my question.
My next proposal does not change the description of the default format
operation
for RW-DL media.
I have another question to members.
Full formatting of a RW-DL disc will take more than 1 hour by 2X
regardless of
IMMED bit setting.
In the case of RW-SL, we had a prospect of the higher speed data
recording. At
the beginning, Full format of RW-SL took 1 hour. Now it takes 10 min by
6X.
The other hands, the forecast of RW-DL formatting time may be 30 min by
4X.
Under this condition, I think that many of the end users should have a
method to
cancel the full format operation after it began.
In the current definition, all commands except several specials shall be
terminated with check condition "Formatting in Progress" during
formatting.
Therefore user only can remove the power from the system.
I think that some method should be describe to stop the 1 hour
operation.
Here is my idea.
1. use existing command
 Start Stop unit command for Stop, Eject and Sleep
2. use other existing command than No.1
3. create a new command
4. no such command or vender specific
Let me know your idea.
Best regards,
Keiji Katata
PIONEER CORP.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From curtis.ballard at hp.com  Fri Jun 30 14:30:37 2006
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Fri, 30 Jun 2006 17:30:37 -0400
Subject: T10/06-046r5 posted
Message-ID: <mailman.580.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
*
I received several good comments on the 06-046r4 version posted last
week so I have updated that document and am posting a new version.  If
you read the previous version most of these changes are editorial but I
did expand a little on the requirements around support of a universal
volume qualifier description for all volume types.
Curtis Ballard
-----Original Message-----
From: jlohmeye at scsibbs.co.lsil.com [mailto:jlohmeye at scsibbs.co.lsil.com]
On Behalf Of T10 Document Administrator
Sent: Friday, June 30, 2006 3:26 PM
To: Ballard, Curtis C (StorageWorks)
Subject: Re: Re: T10 Document Number Assigned (T10/06-046r5)
2006/06/30 15:26:20 
Your request to upload a file or files to the T10 site has been
accepted.
Your PDF file will be posted at:
   http://www.t10.org/ftp/t10/document.06/06-046r5.pdf
Normally, the posting/archiving process takes about 30 minutes.
Please contact John Lohmeyer <lohmeyer at t10.org>
should you need further assistance.
curtis.ballard at hp.com wrote:
> Date: Fri Jun 30 15:25:35 2006
> From: curtis.ballard at hp.com
> To: T10 Document Administrator via web upload <docs at t10.org>
> Subject: Re: T10 Document Number Assigned (T10/06-046r5)
> 
> T10 document upload details:
> 
>   Document Number: T10/06-046r5
>	Upload Code: AC_02121vHk4jlpbf4
>     Document_Date: 2006/06/30
>   Document_Author: Curtis Ballard
>    Document_Title: SMC-3 Report Supported Medium Types
>    Meeting_Agenda: none
> Document_Comments: <none>
>      Other_Number: <none>
>	  Post_File: pdf
> 
> ## COPYRIGHT POLICY
> ## ----------------
> ##
> ## Do not submit documents containing a copyright statement
> ## unless you add the following statement:
> ##
> ##	Permission is granted to members of INCITS, its technical
> ##	committees and their associated task groups to reproduce
> ##	this document for the purposes of INCITS standardization
> ##	activities, provided this notice is included.
> ##
> ## If you upload a copyrighted document, with or without
> ## this statement, it will be assumed implicitly that you
> ## and your organization have given the above permission.
> ##
> ##
> ## APPROPRIATE CONTENT
> ## -------------------
> ##
> ## Do not upload inappropriate material.  If you do, your
> ## files will be removed and your posting privileges will
> ## be revoked.
> 
> Attachment Converted: "D:\T10\ATTACH\06-046r5.pdf"
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From mikeb at bustrace.com  Fri Jun 30 15:24:45 2006
From: mikeb at bustrace.com (Mike Berhan)
Date: Fri, 30 Jun 2006 15:24:45 -0700
Subject: MMC5 Rev 3a - minor editorial requests
Message-ID: <mailman.581.1441607309.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
In reviewing the MMC-5 draft Rev 3a, I noted a few minor editorial
inconsistencies within the spec.  Also copying Mt. Fuji in case consistency
changes are desired there.
This draft, per earlier discussions, has moved the TSR bit to bit 2 of byte
1 of the Write 10 and Write 12 CDBs.  Bit 1 of byte 1 is now defined as
"Restricted for [SBC-2]".  Bits 7-4 are also defined as "Restricted for
[SBC-2]".
1.)  I believe bit 0 of byte 1 of the Write 10 CDB should be marked as
"Obsolete" instead of reserved.
2.)  Bit 4 of byte 1 of READ (10), READ (12), and VERIFY (10) should be
included in the "Restricted for [SBC-2]" field (bits 7-4) instead of defined
as DPO to be consistent with the other CDBs (e.g. WRITE (10), WRITE (12)).
3.)  MMC-5 defines bit 7 of byte 10 of the WRITE (12) CDB as "Streaming"
while leaving the READ (12) bit defined as Reserved.  Mt. Fuji defines both
as the "Streaming" bit as does MMC-4.  I believe this is just a
typographical error in MMC-5 Rev 3a.
Mike
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org