From roger_cummings at symantec.com  Wed Jan  2 10:06:41 2008
From: roger_cummings at symantec.com (Roger Cummings)
Date: Wed, 2 Jan 2008 11:06:41 -0700
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.0.1441607334.22514.t10@sandbox.t10.org>

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

Folks,
A Happy New Year to everyone!
I'd headed off to the UK for Christmas before the last few messages in
the thread below were sent, and have only been back reading e-mail
today. Because of the time that's passed, I've not added to the existing
four levels of comments, but here's my 2c on the ideas contained below:
1) I like the idea of using an opaque shared secret (GRID) to define a
group rather than a list of Transport IDs - I think it's potentially
simpler and may have less corner cases. And I agree that we need a new
construct for this - overloading the Reservation Key would probably be
way to complex.
2) I don't see why a bit in the RESERVE is now necessary to identify the
reservation holder - it seems like this should be derived from the
reservation type as today.
3) I agree that we need to change Preempt case as little as necessary,
and that a preempt from outside of the group has to be supported.
4) I'm not sure if there really is a need for the "add initiator to an
existing group" function, but I'm not ready to absolutely prohibit it at
this time.
5) Fred asks if defining new (reserved only) reservation types could be
an approach to this requirement. Yes I think it could, BUT as the
proposer of the "last new" reservation type I can testify that any new
type will have a major impact on the existing functionality, way beyond
what might be expected. And, frankly, it just feels like the wrong
approach here - what's being asked for is a way of providing
incrementally tighter control of the existing types, not new ones. And
I'm not ready to give up on the two step register/reserve approach
either - there are good reasons why some architectures only allow
specific Initiators to kick off a Reserve whereas all Initiators can
register. 
Thus, based on what I've read below, my preferred approach would be:
1) Define a new type of REGISTER that contains one (or more) GRIDs;
2) Extend RESERVE to include a single GRID, and only Initiators that
have registered (or will register) with a matching GRID get access under
the reservation;
3) Don't change PREEMPT, superseding reservations etc. at all - keep the
rules for handling the reservation keys completely orthogonal to the
GRID;
4) Don't allow GRIDs to be accessed via PR In.
Did I miss something? 
Regards,
Roger Cummings
SYMANTEC
roger_cummings at symantec.com
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Knight, Frederick
	Sent: Thursday, December 27, 2007 9:59 AM
	To: Kevin D Butt
	Cc: Christine R Knibloe; t10 at t10.org
	Subject: RE: Persistent Reservation Proposal - Group
Reservations
	Would moving access restrictions from being based on the
registration to
	being based on a specific reservation type help for this?
	Today, a bunch of initiators register - and that basically has
no impact on
	anyones access.  When 1 initiator does the reservation, then
that action
	impacts all previous registrations (allowing continued access),
and all other
	(non-registered) initiators (denying them access).  Anyone who
registers
	after that immediately joins the existing reservation.	That is
what this
	group reservation is trying to deal with (getting free access
under the
	reservation just by doing a register - which is easy to do).
	Could we create reservations types for:
	  write exclusive - reserved only
	  exclusive access - reserved only
	This would create reservation types that require reservation
actions to allow
	access.  A simple registration all by itself would still have no
impact on access
	until an initiator also performed the reservation step.  Once
any initiator
	uses this new type reservation, then a registered node would
loose access
	(a reservation conflict status) until that initiator also
performed a reserve
	function (with type reserved only).  This also means there would
be multiple
	reservation holders (since every initiator does a reserve); so
no need to deal
	with the one reservation holder case (#5 below).
	Once this reservation type (reserved only) is in place, an
initiator that is already
	registered but not reserved, could not do I/O or change the
reservation type (reserves
	with other reservation types would fail).  Only a reserved
initiator could change
	the reservation type (with a new reserve).
	This would cover all cases below (1-6) except for #5.  As for #4
(preempt),
	the process could be a little more protected.  With all the
existing reservation
	types, the initiator just registers and preempts.  With these
new types, the
	initiator would have to register, reserve, and then preempt.
Would that meet
	the #4 requirement, or do you feel preempt can't have any
changes at all?
	My opinion is that a new reservation type could when it is used,
create new
	requirements.  On the other hand, if you want to have preempt
without reserve,
	then we could exempt that 1 function from the reserve
requirement.
	The question would be a group ID.  Is one needed? or would the
simple change
	to require a matching reservation (of type reserved only) be
enough?  Using a
	simple shared value wouldn't work for this idea because of the
problem it
	would create for preempt (register, reserve with shared value,
then preempt);
	if you don't know the shared value, you can't preempt; so that
would make
	using a shared value impracticle; unless we exempt preempt from
the
	reserve requirement, and just allow register; preempt (without a
reserve);
	then, this approach could work.
	More comments below on the existing proposal.
	    Fred Knight
________________________________
	From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
	Sent: Monday, December 24, 2007 10:40 AM
	To: Raymond Gilson
	Cc: Christine R Knibloe; Knight, Frederick; Roger Cummings;
t10 at t10.org
	Subject: RE: Persistent Reservation Proposal - Group
Reservations
	Ray, 
	Please see this font. 
	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/ 
"Raymond Gilson" <raymond_gilson at symantec.com> 
12/22/2007 07:06 AM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
Christine R Knibloe/Tucson/IBM at IBMUS, "Knight, Frederick"
<Frederick.Knight at netapp.com>, "Roger Cummings"
<roger_cummings at symantec.com>, <t10 at t10.org> 
Subject
RE: Persistent Reservation Proposal - Group Reservations	
	Comments in line 
________________________________
	From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
	Sent: Friday, December 21, 2007 5:33 PM
	To: Raymond Gilson
	Cc: Christine R Knibloe; Knight, Frederick; Roger Cummings;
t10 at t10.org
	Subject: RE: Persistent Reservation Proposal - Group
Reservations
	Ray, 
	Thanks for joining in.	Let me summarize what I think has been
said by all parties who have joined in these discussions. 
	1) (From Ray) Some applications will have trouble providing a
list of Transport IDs. 
	2) (From Fred) There is a desire to allow members of a cluster
that were not active at the creation of the reservation to join in. 
	3) (From Kevin) Who can join or participate in a group
reservation is required to be controlled such that only those initiators
that are part of the cluster (i.e. group) can join. 
	4) PREEMPT must be allowed (i.e., what we do cannot lock out
PREEMPT or make it not work correctly) 
	5) Both Registrants Only and All Registrants types of
functionality need to be provided for. 
	6) There should be an option for all target ports 
	If we can't require a list of Transport ID's then it seems that
the suggested "shared secret" (not cryptographic, just some unique value
that is protected through obfuscation) is probably the best way to do
this.  This would be something akin to requiring the same reservation
key value.  However, using the reservation key does not seem to be
plausible because of how it is being used today.  What we need would be
some different value that would not be reportable via a Persistent
Reserve In.  This would keep third-party initiators from joining the
reservation.  If this new Group Reservation Identifier (GRID) were
added, that would take care of #1, #2, and #3 above. 
	For #5 above, it seems that we could provide that by adding a
bit in the reserve command that indicates "All Participants are
reservation holders".  If set to one, then it acts like an All
Registrants.  If set to zero then it acts like Registrants Only.  This
includes in the unregistering. 
	I'm not sure a bit is the right place for this.  Right now, it's
specified in the reservation type (registrants only, or all
registrants).  Creating a bit creates a place for conflicting
information to be supplied.  Are you suggesting this bit would apply to
only some reservation types, and be unused for other reservation types?
What would it mean if you did a registrants only reservation type, but
set the all registrants bit?
	Another method would be to use all the existing reservation
types (for #5 above), but add a GRID bit to specify that the reservation
applies to only those that supply a matching GRID (all others get
reservation conflict until they supply a matching GRID).  Then it could
in fact apply to all reservation types.   
	For #6 we use the ALL_TGT_PORTS bit the same as other
reservations today. 
	Issues still to be resolved: 
	a) Some systems won't want to require all initiators to send a
Persistent Reserve Out command.  Possible solution is to allow reserving
multiple initiators if a Transport ID list is sent.  Additional
initiators could join later if they have the GRID.  However this would
make it more complicated and if it is not needed I would rather not add
this option. 
	In a practical sense, I cannot see how this could be avoided
(all initiators sending PRO) -- since PR requires trust and good
behavior, each initiator must make no assumption about what the
protection level is currently set at -- so it must verify the settings
as the correct and expected.  If the settings aren't as expected, it
must bail out, or go into error recovery to attempt to avoid messing up
some other application (a fist fight on the SAN for device control does
nobody any good).  I see no reason to provide for this (I do know that
the current command allows a registration for multiple ports, but I
cannot imagine using it in the real world).  
	I'm not sure I understand the issue here.  How can a system that
doesn't want to send PR commands take advantage of the features offered
by that command?  Are you thinking of multi-path systems (where a single
host system has multiple initiators with access to the same target)?
How does this new proposal make this different than the situation today
(where they need to use the transport ID list and the spec_i_pt bit), or
send PR-OUT from every initiator?  I guess I''m mostly agreeing that
good behavior is already required.
	<<kdbutt: I am certainly willing to agree.  All could still be
registered by using the all_i_pt bit. However, I suspect there will be
those that will find this unacceptable.  Anybody who needs a way to add
all initiators who are currently registered to the group reservation,
please speak up (and comment on a method to accomplish this).>> 
	I would suggest we do not want a way to add all currently
registered initiators to the group.  This would tend to have the
potential to enlarge the group beyond what is intended.  I'd prefer a
method that requires explicit action.
	b) If the first I_T nexus sets the "All Participants are
reservation holders" to zero when it creates the reservation and then a
subsequent I_T nexus sets it to one, what is the behavior?  Change the
type?  Reject?	Also, what is reported in the Report Full Status if All
Participants are reservation holders is set to zero?   
	I don't think this is a problem -- once a reservation is
established it cannot be changed without a preempt, clear, or removal of
the old.  If this isn't either true, I would want the attempt to change
it to get rejected.  I would expect a change to require a preempt type
operation.  <<kdbutt: I think the correct response for a new participant
that attempts to change the type is to reject a command that attempts to
change the type. 
	I don't think you can require a preempt/clear in order to change
the type.  The whole point of PR is that a reservation is present at all
times; you can change the type, you can move the owner of the
reservation (such as preempt on a registrants only type), but you never
want to loose the protection provided by the PR (see note 10 in SPC4 -
section 5.6 - clearing).
	For what to return in Report Full Status if  "All Participants
are reservation holders" is set to zero, I am concerned about confusion.
In reality, only the first is a reservation holder and therefore only
the first should set the reservation_holder bit to one.  However, there
would now be two groups that cannot be distinguished.  There first is
not the reservation_holder but part of the reservation and the second is
not the reservation_holder and not part of the reservation.  I think we
should probably add a "group reservation participant" bit to distinguish
the two.>> .   
	c) If we go to this method of using the GRID to determine who
can join, then the Reservation Key may or may not be different. 
	c-1) if the Reservation Key is different, then a PREEMPT of a
Reservation Key will do what? 
	c-2) if the Reservation Key is the same, then a PREEMPT will act
the same as an AR or RO reservation today. 
	c-3) Do we require the Reservation Key to be the same?	 
	Preempt is of a reservation, not a key.  The key's currently are
not compared, and have no valid use (by the device) except that each
initiator has registered one, and only one at a time.  We don't want to
change this behavior -- a key is random number assigned for some
external purpose that the device records and reports.  (My application
requires this to operate properly) 
	<<kdbutt: Look at clause 5.6.10.4 of SPC-4r11.	This looks to me
like the Reservation Key is used to decide between unregistering I_T
nexuses with the sent reservation key or if the reservation key is that
of the reservation holder, then removing the reservation and
registrations of all that have that reservation key.  My intent is not
to change the current behavior.>> 
	Agreed Kevin.  A Preempt should impact the
registration/reservation of all those initiators with a key that matches
the one that is being preempted - the same as current behavior.
	d) Does this approach still have the issues that Roger was
concerned about (e.g., the corner cases)? 
	I hope the use of a GRID would not introduce any new issues to
SPR -- it only prevents a registrant from becoming a reservation
participant without some external knowledge.  It doesn't prevent a
registrant from preempt, clear, or any other error recovery operations
(and MUST not). 
	I think this is one of the questions.  Error recovery is often
one of the cases where you end up with fist-fights out in the SAN over
who owns the device.  Hosts do exactly what you suggested above (host 1
checks with PR-IN, doesn't like what it sees, and preempts and "fixes"
it; then, host 2 does exactly the same - and the fight is on).	It's
perfectly valid to want to leave this working as is.  I understand that
desire.  I just would like to discuss the possibility of improving the
situation.  If we can't or have other requirements not to change it,
that's fine. 
	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/ 
"Raymond Gilson" <raymond_gilson at symantec.com> 
12/21/2007 12:45 PM 
To
"Roger Cummings" <roger_cummings at symantec.com>, "Knight, Frederick"
<Frederick.Knight at netapp.com>, Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org>, Christine R Knibloe/Tucson/IBM at IBMUS 
Subject
RE: Persistent Reservation Proposal - Group Reservations	
	Several years ago I was trying to figure out a way to introduce
a "JOIN" function to the SPR.  The initiator would register, but that
would not grant it access to a reservation of the "joined only" type.
To join it, the initiator would have to send a join SPR command -- we
could add a "shared secret" field to the join, so that only those
initiators that knew the secret could join. 
	I think we will have a great deal of trouble with a "white list"
approach -- as an application, I have no idea what my port ID is (or
anything else for that matter). 
	Would something like this make sense? 
	Thanks, 
	Ray Gilson 
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Roger Cummings
	Sent: Tuesday, December 18, 2007 10:24 AM
	To: Knight, Frederick; Kevin D Butt
	Cc: t10 at t10.org; Christine R Knibloe
	Subject: RE: Persistent Reservation Proposal - Group
Reservations
	Fred, 
	The way you clean up from a disaster is to Preempt, that's what
it's there for. Most of the applications that I know that will actually
issue a Preempt make it a very special function that doesn't happen in
the normal flow, and one app at least DOES require manual intervention
of an operator before kicking off the preempt. 
	Yes, today, a Preempt has to be issued through a registered I_T
nexus, but a registration with the SPEC_I_T bit doesn't have to come
|from an already registered initiator - see Table 33 in SPC-4, and I
don't believe Kevin changed that in his proposal. 
	For the future, however we define a "group" for the purposes of
new reservation types, we will have to make sure that an Initiator
outside of the "group" can issue a Preempt to handle the disaster
recovery case. 
	Regards, 
	Roger 
________________________________
	From: Knight, Frederick [mailto:Frederick.Knight at netapp.com] 
	Sent: Tuesday, December 18, 2007 10:56 AM
	To: Roger Cummings; Kevin D Butt
	Cc: t10 at t10.org; Christine R Knibloe
	Subject: RE: Persistent Reservation Proposal - Group
Reservations
	My question has had to do with differentiating the disaster
clean up 
	case from the non-cooperating host case. 
	How do I clean up from a disaster?  If all my "reserved"
initiators 
	melt down, and there aren't any of them left anymore (because of
	a site disaster, or whatever), how does some other node come
along 
	and clean up so it can gain access? 
	Would it require manual intervention?  Or, is there a way in the
protocol 
	that I can register and preempt the group reservation (does the
use 
	of the SPEC_I_PT bit allow this as you have suggested Roger).  I
	thought the SPEC_I_PT had to come from an already registered 
	initiator (which in a disaster, none exist anymore). 
	   Fred Knight 
________________________________
	From: Roger Cummings [mailto:roger_cummings at symantec.com] 
	Sent: Tuesday, December 18, 2007 10:03 AM
	To: Kevin D Butt; Knight, Frederick
	Cc: t10 at t10.org; Christine R Knibloe
	Subject: RE: Persistent Reservation Proposal - Group
Reservations
	Kevin, 
	I'm sorry, I don't think it's as cut and dried as you make out.
This gets into some of the corner cases that I listed in my first
response. 
	The point to be made in response to Fred's case is that a
third-party can create registrations for a downed initiator (via the
SPEC_I_PT) bit, so that when it comes up again it will be able to
participate in the reservation without having to register itself. 
	Also, you say that "We have made provisions for adding members
once the reservation exists, but only one of the reservation holders can
add another entity." Two things in response to that: 
	1) I didn't see any specific provision for adding members in
your proposal, so I presume you'd just issue another RESERVE with the
same type and the whole list of transport IDs to be included again, and
thus the Target would have a whole lot of work to do again to set up
another reservation. 
	2) I that really what you want, that an member of the existing
group can reissue the RESERVE with a whole bunch of different
TransportIDs, perhaps excluding some that were previously there? 
	Regards, 
	Roger 
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Kevin D Butt
	Sent: Monday, December 17, 2007 3:54 PM
	To: Knight, Frederick
	Cc: t10 at t10.org; Christine R Knibloe
	Subject: RE: Persistent Reservation Proposal - Group
Reservations
	Fred, 
	This is being proposed for SPC. 
	There are multiple types of reservations.  In an environment
where one node of a cluster must join later, one of the other types can
be used.  Either that or have an existing node in your cluster add the
new node.  The whole intent of this Group reservation is to lock out
everybody that is not explicitly specified during the reserve.	We have
made provisions for adding members once the reservation exists, but only
one of the reservation holders can add another entity.	The new entity
cannot add itself.  This is the whole point of reservations (i.e., lock
out others from doing stuff while I think I have exclusive rights). 
	To put it in other word's, to allow somebody to join the
reservation of their own accord without permission is EXACTLY what I am
trying to protect against. 
	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/ 
"Knight, Frederick" <Frederick.Knight at netapp.com> 
12/17/2007 01:38 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
Subject
RE: Persistent Reservation Proposal - Group Reservations	
	Sorry, you can't require everyone to register before the
reserve. 
	That's like saying my whole cluster can't boot because 1 node is
down.  You need 
	to have a way for a "down" initiator to join the fun after the
fact. 
	I helped write a host cluster product that used a shared tape
(failover model).  The 
	backup application would write to the tape.  If a system failure
ever happened, the 
	backup application would failover to a different host.	It would
skip backwards on 
	the tape for a few records, recognize where it left off, and
then resume operation. 
	BUT, for some protection, we used reservations to make sure only
1 initiator at a 
	time could access the tape.  The interesting point however, is
that we were in the 
	process of upgrading from old SCSI-2 RESERVE to using PR.
Because, we also 
	have multiple HBAs in the host, and we wanted to be able to use
more than 1 of 
	those HBAs (so we needed multiple reservations - aka PR).
Having this idea 
	(group reservations) would have been a real nice addition. 
	As for the RA/AR differences.  It seemed to be timing.
Registrants Only was fairly 
	early on (as I remember), and so implemented by several O/S
vendors.  Later on, 
	some issues were found (which got complicated spec-ees added to
address), but also, 
	the All Registrants was added (which didn't have those issues).
But, since there were 
	implementations, it couldn't be removed like the other old PR
types that no one ever 
	used.  Anyway, I agree, they offer basically the same
capabilities, but RO is already 
	out there, and AR is probably what new implementers are using
(it's easier to understand 
	and implement from the host side).  Most of the differences are
already documented, 
	so there wouldn't be that much extra for you to write to have
both types (which I think 
	would be better than bit somewhere - do it the same way all the
others are done).  But, 
	you could also just do the AR version, and let someone else add
the RO version if they 
	want it. 
	Are you proposing this for tape only? or SPC in general?  I
assume SPC in general. 
	  Fred Knight 
________________________________
	From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
	Sent: Monday, December 17, 2007 9:51 AM
	To: Roger Cummings
	Cc: t10 at t10.org
	Subject: RE: Persistent Reservation Proposal - Group
Reservations
	Roger, 
	Thank you for your feedback.  I am certainly willing to
entertain  other methods for accomplishing the end goal in an easier
fashion.  I am not sure I understand how your proposed method makes it
more backward compatible.  In my proposal PRin would show a different
type of reservation and hence the application clients would not try to
join the reservation because they don't know about the type.  In your
proposal, application clients would not be allowed to register.  This is
a deviation from what they can always do today - unless there is a
resource issue.  This seems more disruptive to me.  I would assume that
there would be a new additional sense code added for UNABLE TO REGISTER
BECAUSE A GROUP RESERVATION IS IN PLACE (or analogous).  This would be a
new thing for failure to register and there would be pain at the
register point.  Perhaps that is better than at the reserve point - but
I would think that it would be better handled as a reservation conflict
since that is what it is instead of something the application client
does not understand. 
	As for "all registrants" type vs. "registrants only" I didn't
see where the difference would be interesting, but I am not opposed to
providing a way to switch between which of these two types is done.
Whether it is additional types or some bit during registration etc. 
	As for some of the corner cases mentioned below, if each I_T
nexus that is supposed to be part of the group reservation is required
to be registered before the reservation is made, and if the reservation
is released when the last group reservation participant is unregistered,
then I think we don't have an issue. 
	I would prefer that we work together to shape a mutually
beneficial proposal as opposed to have "competing" proposals.  I am
willing to modify my proposal where it can be made easier and such.  I
am not sold that my proposed method is the only way or even the best -
it's just the way I thought of doing it.  I admit that I have always
been very confused about the usefulness of RA and AR types.  They make
absolutely no sense in the tape world. 
	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/ 
"Roger Cummings" <roger_cummings at symantec.com> 
Sent by: owner-t10 at t10.org 
12/14/2007 12:10 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org> 
Subject
RE: Persistent Reservation Proposal - Group Reservations	
	Kevin, 
	First of all, let me say that I completely support what you're
trying to do here. I think that providing a method in persistent
reservations (PRs) to support shared access between ONLY a
specifically-designated set of systems is a worthy goal, and something
we should do in SPC-4. 
	Adding a set of Transport IDs to Reserve as per your document
08-024 & 08-025 is certainly possible, but it's a massive change to the
way that PRs work today, and it throws up a bunch of nasty corner cases
and backwards compatibility issues. 
	The massive change comes from the fact that now the Target will
have to remember which registrations are in the Reservation, and which
are not. It will probably have to preserve all of the transport
information for the life of the reservation. 
	The corner cases are things like, what happens if there's no
longer a registration that corresponds to the transport ID in the
Reserve? Does the Reserve succeed? What happens if a registration comes
in later, after the reservation has been established - does that device
it get access? 
	Backwards compatibility issues may arise like this: An existing
device registers, and finds it has no access, so it does a PR In and
finds out that a reservation is in place, retries its access and still
it has no access. What does it do next, preempt the reservation because
it assumes the Target is broken? 
	Reserve also has to be an "atomic" command, and I've always
thought that was why it's functionality is as compact as it is today.
Most of the complex operations related to addresses and keys are done at
registration time, and those operations don't have to be atomic. 
	One more thing: you chose for your new "group" reservations to
follow the "all registrants" approach is terms of the definition of the
reservation holder. While that's fine by me (obviously), I suspect there
are also situations where group reservations that follow the
"registrants only" approach might be useful. 
	The bottom line from my point of view is this: Your proposal is
feasible and we can probably make it work. But I wonder if there's an
easier way to achieve the same goal that is more compatible with
existing practice and requires less of a change in functionality on the
Target side. 
	What if we didn't add any new reservations types, but instead
added some new functionality to the registration process? What I'm
thinking of a new Register feature that causes the Target to kill all
existing registrations, create the registrations identified in the
transport IDs in the Register command, and not accept any future
registrations. That way, we don't need any changes to Reserve, and an
Initiator with existing functionality would just not be able to register
and therefore would not be confused. 
	Does that make sense to you? Is there a chance this is an easier
approach? If so, I'll write up a detailed proposal that's the equivalent
of 08-025r0 and we can compare and contrast at the next CAP. 
	Again, thanks for getting this started, I think it's a
worthwhile endeavor and I'll be glad to put some cycles towards defining
this sort of functionality for SPC-4. 
	Regards, 
	Roger 
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Kevin D Butt
	Sent: Monday, December 10, 2007 4:18 PM
	To: t10 at t10.org
	Subject: Persistent Reservation Proposal - Group Reservations
	I have posted two documents related to an additional Persistent
Reservation Type.  The first document is a presentation on where
persistent reservations are today and where they fall short in the
scenarios covered by the proposal.  It also covers the intent of the
proposal and what will be proposed.  The second is the actual proposal 
	Your PDF file will be posted at:
	http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
	http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
	Normally, the posting/archiving process takes about 30 minutes. 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware, IBM
	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/ 


From Black_David at emc.com  Wed Jan  2 11:18:55 2008
From: Black_David at emc.com (Black_David at emc.com)
Date: Wed, 2 Jan 2008 14:18:55 -0500
Subject: DS_SAI length conflict between 07-437r4 and 07-169 & SPC-4
Message-ID: <mailman.1.1441607334.22514.t10@sandbox.t10.org>

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

Kevin,
We need to make a decision on this one because there is no obvious
right answer.  IETF uses separate SPIs (what T10 calls SAIs) for
IKEv2 and ESP - 8 bytes SPIs are used for IKEv2, but ESP uses 4 byte
SPIs.  SCSI is using the same SPI for both purposes, and hence needs
to pick one length - I agree with your suggestion that 8 bytes (as
used in IKEv2-SCSI) is preferable.  From an implementation standpoint
this would reduce the impact on reuse of the more complex IKEv2
implementations (more complex is by comparison to ESP).
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953	      FAX: +1 (508) 293-7786
black_david at emc.com	   Mobile: +1 (978) 394-7754
----------------------------------------------------
________________________________
	From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
	Sent: Friday, December 21, 2007 11:24 AM
	To: roweber at ieee.org; Black, David; matt.ball at ieee.org
	Cc: t10 at t10.org
	Subject: DS_SAI length conflict between 07-437r4 and 07-169 &
SPC-4
	Ralph, David, and Matt, 
	All the DS_SAI values in the ESP-SCSI (07-169r5) (e.g., Table x3
- ESP-SCSI data-out buffer parameter list descriptor without
initialization vector) are shown as 4-byte values as they are in SPC-4
Table 44 - Minimum SA parameters.  However 07-437r4 shows them as 8-byte
values.  I think 07-437r4 is correct and SPC-4 and 07-169 need to be
modified to match. 
	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/ 


From george at penokie.com  Wed Jan  2 11:23:54 2008
From: george at penokie.com (George Penokie)
Date: Wed, 02 Jan 2008 13:23:54 -0600
Subject: Fw: OSD Perform Scsi Command ( Inquiry )
Message-ID: <mailman.2.1441607334.22514.t10@sandbox.t10.org>

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

Eddy,
Yes, you are correct.
Bye for now,
George Penokie
>
> ----- Forwarded by George Penokie/Rochester/IBM on 12/30/2007 03:00 PM 
> -----
> *"Eddy Quicksall" <Quicksall_SCSI at bellsouth.net>*
> Sent by: owner-t10 at t10.org
>
> 12/20/2007 11:07 AM
>
>	
> To
>	<t10 at t10.org>
> cc
>	
> Subject
>	OSD Perform Scsi Command ( Inquiry )
>
>
>
>	
>
>
>
>
>
> According to SAM4r13b 5.8.7 2nd instance of 'a', an INQUIRY should not 
> report a Unit Attention; what about an INQUIRY given via PERFORM SCSI 
> COMMAND? My guess is that it should report a Unit Attention (if 
> pending) because the PERFORM SCSI COMMAND fits into the category of 
> "If a command other than INQUIRY ..." (see SAM4r13b 5.8.7 2nd instance 
> of 'e').
>  
> Am I correct?
>  
> Eddy 


From plavarre at lexar.com  Wed Jan  2 13:15:25 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Wed, 2 Jan 2008 13:15:25 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.3.1441607334.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
Here's one specific way we could correct the Spc4r11.pdf 6.4 Inquiry
English:
"""The ALLOCATION LENGTH field is defined in 4.3.4.6. [+ The allocation
length should be zero else at least four or five.] If EVPD is set to
zero, the allocation length should be at least five, so that the
ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is returned.
If EVPD is set to one, the allocation length should be [- should be] at
least four, so that the PAGE LENGTH field in the parameter data (see
7.6) is returned."""
Like it?
The [+] change notation indicates text I think we should add. The [-]
change notation indicates text I think we should subtract. The
"""quotes""" enclose the wrong I see in our 14 May 2007 Spc4r11.
Right way to move forward?
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Paul.Suhler at Quantum.Com  Wed Jan  2 13:18:45 2008
From: Paul.Suhler at Quantum.Com (Paul Suhler)
Date: Wed, 2 Jan 2008 13:18:45 -0800
Subject: Call for Secretary for ADI Working Group
Message-ID: <mailman.4.1441607334.22514.t10@sandbox.t10.org>

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

This is a reminder that Michael Banther's tenure as secretary of the
Automatin/Drive Interface (ADI) working group will end in two weeks,
following the T10 Plenary Week in Santa Ana.  I am searching for a
volunteer to be the new secretary.
Thanks very much,
Paul Suhler
Quantum Corporation
ADI Project Leader
+++++++++++++++++
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.
Permission is hereby explicitly granted to disclose, copy, and further
distribute to any individual(s) or organization(s), without restriction.
-----------------------------------------------------------
The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.


From Gerry.Houlder at seagate.com  Wed Jan  2 13:39:31 2008
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Wed, 2 Jan 2008 15:39:31 -0600
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.5.1441607334.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
So this is Roger's preference:
>1) Define a new type of REGISTER that contains one (or more) GRIDs;
>2) Extend RESERVE to include a single GRID, and only Initiators that have
registered (or will register) with a matching GRID get access under the
reservation;
>3) Don't change PREEMPT, superseding reservations etc. at all - keep the
rules for handling the reservation keys completely orthogonal to the GRID;
>4) Don't allow GRIDs to be accessed via PR In.
If we don't add a new reservation type, it sounds like you are describing a
new registration type (existing one without GRID, new one with GRID). This
seems to complicate the rules for making an "all registrants" reservation.
If the initiator making the reservation specifies a GRID, only other
initiators that registered with that GRID value inherit the reservation and
the others are excluded. This would be a very different result for current
initiators that expect to inherit any reservations just by registering.
Further, the "unexpectedly excluded" registered initiator will get no clue
as to why it doesn't inherit the reservation. if it issues READ RESERVATION
it gets back a response that says an all registrants reservation is in
force. The PR generation and reservation key values returned won't help any
either, and the GROUP ID value of course will not be returned. Creating a
new reservation type would help here, since the reservation type is
returned by READ RESERVATION. This might be an advantage of creating a new
reservation type for GRID Registrants Only (or something like that). The
new reservation type would make it more obvious why you didn't inherit a
reservation you expected to inherit.
Also for backwards compatibility, will initiators be able to register with
existing method (i.e., not specifying a GROUP ID) as well as a new method
that specifies a GROUP ID? The standard will have to describe how
registrants without a group ID, registrants with a non-matching group ID,
and registrants with a matching group ID will interact with the current
registrants only reservation and a "GRID registrants only" reservation.
Do we really lose that much if we simply create a "matching reservation
key" reservation instead? That means only initiators that register with a
matching reservation key inherit the reservation. We lose a little bit of
security because the matching ID value is publicly reported and a malicious
initiator can still join, but a malicous initiator could probably get
around the Group ID value match just by bute force retries anyway (how many
bytes of group ID is enough?), or just preempt the group ID reservation and
replace it with a regular registrants only reservation. This is a simpler
method of creating a Group ID reservation that probably works just fine for
co-operating initiators (as opposed to previously described malicious
ones).
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From plavarre at lexar.com  Wed Jan  2 14:00:45 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Wed, 2 Jan 2008 14:00:45 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.6.1441607334.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
Kindly offline we have an alternative preferred there:
"""The ALLOCATION LENGTH field is defined in 4.3.4.6. If EVPD is set to
zero, the allocation length should be [+ zero else] at least five, so
that the ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is
returned. If EVPD is set to one, the allocation length should be [-
should be] [+ zero else] at least four, so that the PAGE LENGTH field in
the parameter data (see 7.6) is returned."""
*
* 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 wdc.com  Wed Jan  2 14:36:55 2008
From: Mark.Evans at wdc.com (Mark Evans)
Date: Wed, 2 Jan 2008 14:36:55 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.7.1441607334.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Mark Evans" <Mark.Evans at wdc.com>
*
Hi Pat,
I'm not sure what you're trying to fix.  The only possible clarification I
can see is to explain a touch more about the reason for the five and four.
This could be done by adding a few words the paragraph you mention in 6.4.1
INQUIRY command introduction as follows:
The ALLOCATION LENGTH field is defined in 4.3.4.6.  If EVPD is set to zero,
then the allocation length should be at least five so that the ADDITIONAL
LENGTH field (i.e., byte 4 in the standard INQUIRY data) is returned
providing the application client with the length of the data available (see
6.4.2).  If EVPD is set to one, then the allocation length should be should
be at least four so that the PAGE LENGTH field (i.e., byte 3 or bytes 2 and
3 in a vital product data page) is returned providing the application client
with the length of the data in the specified VPD page (see 7.6).
The cross references are already in the paragraph, but I guess a few more
words wouldn't hurt.  Am I missing the issue that you're trying to resolve?
Please let me know.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose,  CA  95138
Email: mark.evans at wdc.com
Office: 408.363.5257
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
plavarre at lexar.com
Sent: Wednesday, January 02, 2008 1:15 PM
To: T10 at t10.org
Subject: RE: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
maybe
* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
Here's one specific way we could correct the Spc4r11.pdf 6.4 Inquiry
English:
"""The ALLOCATION LENGTH field is defined in 4.3.4.6. [+ The allocation
length should be zero else at least four or five.] If EVPD is set to
zero, the allocation length should be at least five, so that the
ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is returned.
If EVPD is set to one, the allocation length should be [- should be] at
least four, so that the PAGE LENGTH field in the parameter data (see
7.6) is returned."""
Like it?
The [+] change notation indicates text I think we should add. The [-]
change notation indicates text I think we should subtract. The
"""quotes""" enclose the wrong I see in our 14 May 2007 Spc4r11.
Right way to move forward?
*
* 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 Alvin.Cox at seagate.com  Wed Jan  2 15:16:40 2008
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Wed, 2 Jan 2008 17:16:40 -0600
Subject: Reminder, SAS PHY WG call, Jan 3, 10:00am CST
Message-ID: <mailman.8.1441607334.22514.t10@sandbox.t10.org>

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

Conference calls on Thursday at 10:00 am Central time.
Next conference call: 1/3/08
Additional call:
January 10, 2008
Toll Free Dial in Number: (877)810-9442 
International Access/Caller Paid Dial In Number: (636)651-3190 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate 
Topic: SAS-2 PHY WG 
Date: Thursday 
Time: 10:00 am, Central Standard Time
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS 
Agenda (items to be covered based on attendees and readiness to discuss): 
1. Proposed Cable Tables for SAS2 6Gbs Phy [McSorley] 
http://www.t10.org/ftp/t10/document.07/07-471r0.pdf 
No update last call. Asks Galen Fromm to help with review and possible 
update suggestions for 07-471.
2. Description of SSC profile allowed discontinuities. [Hernandez, Fortin] 
http://www.t10.org/ftp/t10/document.08/08-027r3.pdf
http://www.t10.org/ftp/t10/document.08/08-032r0.pdf
Discussed at length the jitter budget, math behind the residual SSC jitter 
after JTF, and whether limit values should be normative or informative. 
Rev 3 along with a separate proposal in a format updating the 
specification text were posted (links above). 
3. SAS-2 Interconnect Signal-to-Noise Ratio Study [Olawsky] 
http://www.t10.org/ftp/t10/document.07/07-484r0.pdf 
4. SAS-2 Receiver Device Physical Testing [Witt, Bari] 
http://www.t10.org/ftp/t10/document.07/07-486r1.pdf 
5. Refine/provide status on simulation technology. [Jenkins, Newman]
6. SAS-2: Remove restrictions for SSC [Houlder, Cox] 
http://www.t10.org/ftp/t10/document.08/08-014r2.pdf
Update posted at the link above. Although this text discusses an 
implementation-specific behavior, it is considered necessary as the 
subtleties in the specification that allow it do not make the impact of 
the implementation readily apparent.
7. SAS-2 6Gbps PHY specification [Cox] 
http://www.t10.org/ftp/t10/document.07/07-339r8.pdf 
Updates to references included. Please provide additional comments.
Alvin Cox
Seagate Technology, LLC
Cell 405-206-4809


From roweber at IEEE.org  Wed Jan  2 19:26:10 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Wed, 02 Jan 2008 21:26:10 -0600
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.9.1441607334.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Mark,
> ... The only possible clarification I can see is to explain
> a touch more about the reason for the five and four. ...
This of course assumes that some *reason* other than
"because the standard says so" is needed. :-)
All the best,
.Ralph
Mark Evans wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Mark Evans" <Mark.Evans at wdc.com>
> *
> Hi Pat,
>
> I'm not sure what you're trying to fix.  The only possible clarification I
> can see is to explain a touch more about the reason for the five and four.
> This could be done by adding a few words the paragraph you mention in 6.4.1
> INQUIRY command introduction as follows:
>
> The ALLOCATION LENGTH field is defined in 4.3.4.6.  If EVPD is set to zero,
> then the allocation length should be at least five so that the ADDITIONAL
> LENGTH field (i.e., byte 4 in the standard INQUIRY data) is returned
> providing the application client with the length of the data available (see
> 6.4.2).  If EVPD is set to one, then the allocation length should be should
> be at least four so that the PAGE LENGTH field (i.e., byte 3 or bytes 2 and
> 3 in a vital product data page) is returned providing the application
client
> with the length of the data in the specified VPD page (see 7.6).
>
> The cross references are already in the paragraph, but I guess a few more
> words wouldn't hurt.	Am I missing the issue that you're trying to resolve?
> Please let me know.
>
> Regards,
>
> Mark Evans
> Western Digital Corporation
> 5863 Rue Ferrari
> San Jose,  CA  95138
> Email: mark.evans at wdc.com
> Office: 408.363.5257
>
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
> plavarre at lexar.com
> Sent: Wednesday, January 02, 2008 1:15 PM
> To: T10 at t10.org
> Subject: RE: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
> maybe
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * <plavarre at lexar.com>
> *
> Here's one specific way we could correct the Spc4r11.pdf 6.4 Inquiry
> English:
>
>
> """The ALLOCATION LENGTH field is defined in 4.3.4.6. [+ The allocation
> length should be zero else at least four or five.] If EVPD is set to
> zero, the allocation length should be at least five, so that the
> ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is returned.
> If EVPD is set to one, the allocation length should be [- should be] at
> least four, so that the PAGE LENGTH field in the parameter data (see
> 7.6) is returned."""
>
>
> Like it?
>
>
> The [+] change notation indicates text I think we should add. The [-]
> change notation indicates text I think we should subtract. The
> """quotes""" enclose the wrong I see in our 14 May 2007 Spc4r11.
>
>
> Right way to move forward?
>
> *
> * 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
>
>
>
>   
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Black_David at emc.com  Thu Jan  3 06:19:22 2008
From: Black_David at emc.com (Black_David at emc.com)
Date: Thu, 3 Jan 2008 09:19:22 -0500
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.10.1441607334.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Black_David at emc.com
*
I'm still checking with our implementers, but my initial reaction
is that Gerry's 2-for-2:
(1) I strongly agree with Gerry's preference for a new RESERVATION
	type over a new REGISTRATION type.  PR code is already
	subtle in a number of ways, and a new reservation type is
	much easier to isolate from existing types in specification,
	coding, and testing.  It should also have better behavior
	when mixing implementations that don't all support the
	new functionality.  We probably need two new types, one
	for group write and one for group exclusive.
(2) Is there a reason why we can't use the existing reservation
	key as the entity that has to match for the new reservation
	type?  One would have to ensure that the reservation key
	can't be read from the device by PR IN, but we already
	have the precedent (and the specification text) to do
	that in the All Registrants reservation types.	Reuse of
	the reservation key is going to be easier to cope with
	than inventing a new group identifier.
What initiator implementations are likely to use this new
functionality for what purposes?
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953	      FAX: +1 (508) 293-7786
black_david at emc.com	   Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf 
> Of Gerry.Houlder at seagate.com
> Sent: Wednesday, January 02, 2008 4:40 PM
> To: t10 at t10.org
> Subject: RE: Persistent Reservation Proposal - Group Reservations
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gerry.Houlder at seagate.com
> *
> So this is Roger's preference:
> 
> >1) Define a new type of REGISTER that contains one (or more) GRIDs;
> >2) Extend RESERVE to include a single GRID, and only Initiators that
have
> registered (or will register) with a matching GRID get access under
the
> reservation;
> >3) Don't change PREEMPT, superseding reservations etc. at all - keep
the
> rules for handling the reservation keys completely orthogonal to the
GRID;
> >4) Don't allow GRIDs to be accessed via PR In.
> 
> If we don't add a new reservation type, it sounds like you are
describing a
> new registration type (existing one without GRID, new one with GRID).
This
> seems to complicate the rules for making an "all registrants"
reservation.
> If the initiator making the reservation specifies a GRID, only other
> initiators that registered with that GRID value inherit the
reservation and
> the others are excluded. This would be a very different result for
current
> initiators that expect to inherit any reservations just by
registering.
> 
> Further, the "unexpectedly excluded" registered initiator will get no
clue
> as to why it doesn't inherit the reservation. if it issues READ
RESERVATION
> it gets back a response that says an all registrants reservation is in
> force. The PR generation and reservation key values returned won't
help any
> either, and the GROUP ID value of course will not be returned.
Creating a
> new reservation type would help here, since the reservation type is
> returned by READ RESERVATION. This might be an advantage of creating a
new
> reservation type for GRID Registrants Only (or something like that).
The
> new reservation type would make it more obvious why you didn't inherit
a
> reservation you expected to inherit.
> 
> Also for backwards compatibility, will initiators be able to register
with
> existing method (i.e., not specifying a GROUP ID) as well as a new
method
> that specifies a GROUP ID? The standard will have to describe how
> registrants without a group ID, registrants with a non-matching group
ID,
> and registrants with a matching group ID will interact with the
current
> registrants only reservation and a "GRID registrants only"
reservation.
> 
> Do we really lose that much if we simply create a "matching
reservation
> key" reservation instead? That means only initiators that register
with a
> matching reservation key inherit the reservation. We lose a little bit
of
> security because the matching ID value is publicly reported and a
malicious
> initiator can still join, but a malicous initiator could probably get
> around the Group ID value match just by bute force retries anyway (how
many
> bytes of group ID is enough?), or just preempt the group ID
reservation and
> replace it with a regular registrants only reservation. This is a
simpler
> method of creating a Group ID reservation that probably works just
fine for
> co-operating initiators (as opposed to previously described malicious
> ones).
> 
> *
> * 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 wdc.com  Thu Jan  3 07:49:02 2008
From: Mark.Evans at wdc.com (Mark Evans)
Date: Thu, 3 Jan 2008 07:49:02 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.11.1441607334.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Mark Evans" <Mark.Evans at wdc.com>
*
Hi Ralph,
Now what I think Pat is trying to do is to highlight that setting ALLOCATION
LENGTH to zero in an INQUIRY command is allowed, and that this setting may
be used as, "...a way of asking to test Command Out and Status In without
asking to test Data...".  However, I think this is covered.  Why the value
in the ALLOCATION LENGTH should be set to five or four is already explained
by the cross references in 6.4.1 INQUIRY command introduction, albeit not as
clearly as my suggested wording, but definitely more succinctly.  Wow.
Three "ly" adverbs in one sentence -- ha!
The qualification for the five or four in the ALLOCATION LENGTH field in an
INQUIRY command as defined in 6.4.1 is only a "should".  Based on that text,
zero is allowed as a value in the field for whatever reason.  In addition,
the second paragraph in 4.3.4.6 Allocation length reads, "An allocation
length of zero specifies that no data shall be transferred.  This condition
shall not be considered as an error."  So, 6.4.1 implicitly permits zero as
an allowed value for an INQUIRY command, and 4.3.4.6 explicity allows a
value of zero in an ALLOCATION LENGTH field for any command.
I think that there are many words that could be added to further explain the
setting of the ALLOCATION LENGTH field in an INQUIRY command.  However, "the
standard [already] says so."
Pat, if you want some more words in SPC-4, I'd suggest submitting a proposal
to T10, but based on what is already in the standard, I think you may have
tough sledding.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose,  CA  95138
Email: mark.evans at wdc.com
Office: 408.363.5257
Fax: 408.363.5139
Cell: 408.391.7805
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph Weber
Sent: Wednesday, January 02, 2008 7:26 PM
To: T10 at t10.org
Subject: Re: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
maybe
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Mark,
> ... The only possible clarification I can see is to explain
> a touch more about the reason for the five and four. ...
This of course assumes that some *reason* other than
"because the standard says so" is needed. :-)
All the best,
.Ralph
Mark Evans wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Mark Evans" <Mark.Evans at wdc.com>
> *
> Hi Pat,
>
> I'm not sure what you're trying to fix.  The only possible clarification I
> can see is to explain a touch more about the reason for the five and four.
> This could be done by adding a few words the paragraph you mention in
6.4.1
> INQUIRY command introduction as follows:
>
> The ALLOCATION LENGTH field is defined in 4.3.4.6.  If EVPD is set to
zero,
> then the allocation length should be at least five so that the ADDITIONAL
> LENGTH field (i.e., byte 4 in the standard INQUIRY data) is returned
> providing the application client with the length of the data available
(see
> 6.4.2).  If EVPD is set to one, then the allocation length should be
should
> be at least four so that the PAGE LENGTH field (i.e., byte 3 or bytes 2
and
> 3 in a vital product data page) is returned providing the application
client
> with the length of the data in the specified VPD page (see 7.6).
>
> The cross references are already in the paragraph, but I guess a few more
> words wouldn't hurt.	Am I missing the issue that you're trying to
resolve?
> Please let me know.
>
> Regards,
>
> Mark Evans
> Western Digital Corporation
> 5863 Rue Ferrari
> San Jose,  CA  95138
> Email: mark.evans at wdc.com
> Office: 408.363.5257
>
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
> plavarre at lexar.com
> Sent: Wednesday, January 02, 2008 1:15 PM
> To: T10 at t10.org
> Subject: RE: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
> maybe
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * <plavarre at lexar.com>
> *
> Here's one specific way we could correct the Spc4r11.pdf 6.4 Inquiry
> English:
>
>
> """The ALLOCATION LENGTH field is defined in 4.3.4.6. [+ The allocation
> length should be zero else at least four or five.] If EVPD is set to
> zero, the allocation length should be at least five, so that the
> ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is returned.
> If EVPD is set to one, the allocation length should be [- should be] at
> least four, so that the PAGE LENGTH field in the parameter data (see
> 7.6) is returned."""
>
>
> Like it?
>
>
> The [+] change notation indicates text I think we should add. The [-]
> change notation indicates text I think we should subtract. The
> """quotes""" enclose the wrong I see in our 14 May 2007 Spc4r11.
>
>
> Right way to move forward?
>
> *
> * 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
>
>
>
>   
*
* 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 Frederick.Knight at netapp.com  Thu Jan  3 08:33:58 2008
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Thu, 3 Jan 2008 11:33:58 -0500
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.12.1441607334.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
I'm still mulling over some of these discussions, but
absolutely agree with #1 - a new reservation type is preferred.
As for #2, I disagree.	How would I remove a single initiators
registration (preempt a single initiator from the group) if they
all must have the same KEY to join the group?
More comments later.
	Fred Knight
-----Original Message-----
From: Black_David at emc.com [mailto:Black_David at emc.com] 
Sent: Thursday, January 03, 2008 9:19 AM
To: Gerry.Houlder at seagate.com; t10 at t10.org
Subject: RE: Persistent Reservation Proposal - Group Reservations
* From the T10 Reflector (t10 at t10.org), posted by:
* Black_David at emc.com
*
I'm still checking with our implementers, but my initial reaction is
that Gerry's 2-for-2:
(1) I strongly agree with Gerry's preference for a new RESERVATION
	type over a new REGISTRATION type.  PR code is already
	subtle in a number of ways, and a new reservation type is
	much easier to isolate from existing types in specification,
	coding, and testing.  It should also have better behavior
	when mixing implementations that don't all support the
	new functionality.  We probably need two new types, one
	for group write and one for group exclusive.
(2) Is there a reason why we can't use the existing reservation
	key as the entity that has to match for the new reservation
	type?  One would have to ensure that the reservation key
	can't be read from the device by PR IN, but we already
	have the precedent (and the specification text) to do
	that in the All Registrants reservation types.	Reuse of
	the reservation key is going to be easier to cope with
	than inventing a new group identifier.
What initiator implementations are likely to use this new functionality
for what purposes?
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953	      FAX: +1 (508) 293-7786
black_david at emc.com	   Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of 
> Gerry.Houlder at seagate.com
> Sent: Wednesday, January 02, 2008 4:40 PM
> To: t10 at t10.org
> Subject: RE: Persistent Reservation Proposal - Group Reservations
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gerry.Houlder at seagate.com
> *
> So this is Roger's preference:
> 
> >1) Define a new type of REGISTER that contains one (or more) GRIDs;
> >2) Extend RESERVE to include a single GRID, and only Initiators that
have
> registered (or will register) with a matching GRID get access under
the
> reservation;
> >3) Don't change PREEMPT, superseding reservations etc. at all - keep
the
> rules for handling the reservation keys completely orthogonal to the
GRID;
> >4) Don't allow GRIDs to be accessed via PR In.
> 
> If we don't add a new reservation type, it sounds like you are
describing a
> new registration type (existing one without GRID, new one with GRID).
This
> seems to complicate the rules for making an "all registrants"
reservation.
> If the initiator making the reservation specifies a GRID, only other 
> initiators that registered with that GRID value inherit the
reservation and
> the others are excluded. This would be a very different result for
current
> initiators that expect to inherit any reservations just by
registering.
> 
> Further, the "unexpectedly excluded" registered initiator will get no
clue
> as to why it doesn't inherit the reservation. if it issues READ
RESERVATION
> it gets back a response that says an all registrants reservation is in
> force. The PR generation and reservation key values returned won't
help any
> either, and the GROUP ID value of course will not be returned.
Creating a
> new reservation type would help here, since the reservation type is 
> returned by READ RESERVATION. This might be an advantage of creating a
new
> reservation type for GRID Registrants Only (or something like that).
The
> new reservation type would make it more obvious why you didn't inherit
a
> reservation you expected to inherit.
> 
> Also for backwards compatibility, will initiators be able to register
with
> existing method (i.e., not specifying a GROUP ID) as well as a new
method
> that specifies a GROUP ID? The standard will have to describe how 
> registrants without a group ID, registrants with a non-matching group
ID,
> and registrants with a matching group ID will interact with the
current
> registrants only reservation and a "GRID registrants only"
reservation.
> 
> Do we really lose that much if we simply create a "matching
reservation
> key" reservation instead? That means only initiators that register
with a
> matching reservation key inherit the reservation. We lose a little bit
of
> security because the matching ID value is publicly reported and a
malicious
> initiator can still join, but a malicous initiator could probably get 
> around the Group ID value match just by bute force retries anyway (how
many
> bytes of group ID is enough?), or just preempt the group ID
reservation and
> replace it with a regular registrants only reservation. This is a
simpler
> method of creating a Group ID reservation that probably works just
fine for
> co-operating initiators (as opposed to previously described malicious 
> ones).
> 
> *
> * 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
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From plavarre at lexar.com  Thu Jan  3 09:00:22 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Thu, 3 Jan 2008 09:00:22 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.13.1441607334.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
> Now what I think Pat is trying
Hi. Thought-provoking to see this small issue so persistently confused
in such a broad variety of ways offline and online.
I have now a reading kindly contributed offline that I think is the
intent of what we published, just not actually in technical agreement
with the words we have mistyped into Spcr411.pdf:
"""In order to get the information that tells you how many bytes of data
are available the allocation length must be at least this big. If you
don't care about retrieving the Page Length parameter or the Available
Length parameter then you don't have to follow this suggestion."""
Is this indeed what we were trying to say?
I think we have to agree over what we were trying to say before we have
a hope of saying it accurately.
I think that's what we actually meant to say.
> > > If the EVPD bit is ...
Looks like some reviewers get lost in the truth of the real dichotomy
that the host must choose zero or one as the EVPD bit of the CDB. That
dichotomy is very true, it is only one bit, it can only be zero or one,
yes yes yes. But the rest of the above is true also.
> highlight that setting ALLOCATION LENGTH to zero in an INQUIRY command
is allowed,
Several readers offline also appear to get lost in "shall" vs. "should".
I think here we published a false combination of should's, not a false
combination of shall's.
I think the text as it stands contains two nearly adjacent should's that
misleadingly combine to produce the false claim that the host "should
not" zero allocation length. I agree the two should's don't combine to
produce the false claim that the host "shall not".
> I think this is covered.
I'm failing to follow that logic of that assertion, somehow. I've seen
several people make it, online or offline. Always looks to me like
people mixing should's with shall's, as if shall's could cover should's.
> Why the value in the ALLOCATION LENGTH should be set to five or four
> is already explained by the cross references in 6.4.1 INQUIRY command
introduction,
> albeit not as clearly as my suggested wording, but definitely more
succinctly.
Yes.
> Wow. Three "ly" adverbs in one sentence -- ha!
:-)
> The qualification for the five or four in the ALLOCATION LENGTH field
> in an INQUIRY command as defined in 6.4.1 is only a "should".
Yes.
> Based on that text, zero is allowed as a value in the field for
whatever reason.
Sure, by Spc4r11 the host may choose allocation lengths between 0 and
65,535.
Another confusion offline appeared between transfer length and
allocation length. The field in Inquiry is allocation length, where the
code zero means a count of zero bytes, never a transfer length such as
the code zero in op 08h Read(6) that can mean a count of
two-hundred-fifty-six blocks.
> In addition, the second paragraph in 4.3.4.6 Allocation length reads,
> "An allocation length of zero specifies that no data shall be
transferred.
>  This condition shall not be considered as an error."
> So, 6.4.1 implicitly permits zero as an allowed value for an INQUIRY
command,
> and 4.3.4.6 explicity allows a value of zero in an ALLOCATION LENGTH
field for any command.
Yes. Our "shall"s are not broken, only our "should"s are at issue.
> I think that there are many words that could be added
> to further explain the setting of the ALLOCATION LENGTH field
> in an INQUIRY command.  However, "the standard [already] says so."
This slang is new to me.
I think this means we should not add words to the standard when the
standard already says what it means?
I'm ok with that principle.
Here's I'm confident that the standard doesn't yet say what we mean. It
includes a false host should not.
> Pat, if you want some more words in SPC-4,
> I'd suggest submitting a proposal to T10,
Ok.
> based on what is already in the standard, I think you may have tough
sledding.
Ok.
I'm curious to know if I'm wrong. Left to myself I'd be certain I'm
obviously right, but meeting together like this we've at least proved
that I'm not obviously right, even if I am right, and we still hold open
the idea I might be wrong, which might interest me a lot more than
anyone else.
> ...
I popped up online yesterday and offline immediately received the
following suggestion. I posted it once but I haven't seen anyone quote
it, kind of like it got lost because it arrived online under my same
>From tag so soon?
Kindly offline we have an alternative preferred there:
"""The ALLOCATION LENGTH field is defined in 4.3.4.6. If EVPD is set to
zero, the allocation length should be [+ zero else] at least five, so
that the ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is
returned. If EVPD is set to one, the allocation length should be [-
should be] [+ zero else] at least four, so that the PAGE LENGTH field in
the parameter data (see 7.6) is returned."""
I think that proposed change text actually says what we mean, i.e.:
"""In order to get the information that tells you how many bytes of data
are available the allocation length must be at least this big. If you
don't care about retrieving the Page Length parameter or the Available
Length parameter then you don't have to follow this suggestion."""
I can volunteer me to format some Word doc if that would help, sure.
None of these words are originally mine, thanks again to everyone
involved,
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From jgeldman at lexar.com  Thu Jan  3 09:20:34 2008
From: jgeldman at lexar.com (jgeldman)
Date: Thu, 3 Jan 2008 09:20:34 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.14.1441607334.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "jgeldman" <jgeldman at lexar.com>
*
I believe there are two issues. The gramatical issue is the repeated  "should
be" phrase. 
The technical issue is that current sentences are misleading or
contradictory. The structure provides "at least" language for allocation
length if the EVPD bit is set or clear. However, zero is also a valid
allocation length as stated in the allocaton length
definition. While no useful INQUIRY information passes with a zero allocation
length, some USB systems use this to test if the command path is functional. 
So, one part of of the fix is to remove a repeated phrase and the other parts
explicitly document the possibility of zero for allocation length.
John Geldman
-----Original Message-----
From: "Ralph Weber" <roweber at IEEE.org>
To: "T10 at t10.org" <T10 at t10.org>
Sent: 1/2/2008 7:51 PM
Subject: Re: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
maybe
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Mark,
> ... The only possible clarification I can see is to explain
> a touch more about the reason for the five and four. ...
This of course assumes that some *reason* other than
"because the standard says so" is needed. :-)
All the best,
.Ralph
Mark Evans wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Mark Evans" <Mark.Evans at wdc.com>
> *
> Hi Pat,
>
> I'm not sure what you're trying to fix.  The only possible clarification I
> can see is to explain a touch more about the reason for the five and four.
> This could be done by adding a few words the paragraph you mention in 6.4.1
> INQUIRY command introduction as follows:
>
> The ALLOCATION LENGTH field is defined in 4.3.4.6.  If EVPD is set to zero,
> then the allocation length should be at least five so that the ADDITIONAL
> LENGTH field (i.e., byte 4 in the standard INQUIRY data) is returned
> providing the application client with the length of the data available (see
> 6.4.2).  If EVPD is set to one, then the allocation length should be should
> be at least four so that the PAGE LENGTH field (i.e., byte 3 or bytes 2 and
> 3 in a vital product data page) is returned providing the application
client
> with the length of the data in the specified VPD page (see 7.6).
>
> The cross references are already in the paragraph, but I guess a few more
> words wouldn't hurt.	Am I missing the issue that you're trying to resolve?
> Please let me know.
>
> Regards,
>
> Mark Evans
> Western Digital Corporation
> 5863 Rue Ferrari
> San Jose,  CA  95138
> Email: mark.evans at wdc.com
> Office: 408.363.5257
>
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
> plavarre at lexar.com
> Sent: Wednesday, January 02, 2008 1:15 PM
> To: T10 at t10.org
> Subject: RE: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
> maybe
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * <plavarre at lexar.com>
> *
> Here's one specific way we could correct the Spc4r11.pdf 6.4 Inquiry
> English:
>
>
> """The ALLOCATION LENGTH field is defined in 4.3.4.6. [+ The allocation
> length should be zero else at least four or five.] If EVPD is set to
> zero, the allocation length should be at least five, so that the
> ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is returned.
> If EVPD is set to one, the allocation length should be [- should be] at
> least four, so that the PAGE LENGTH field in the parameter data (see
> 7.6) is returned."""
>
>
> Like it?
>
>
> The [+] change notation indicates text I think we should add. The [-]
> change notation indicates text I think we should subtract. The
> """quotes""" enclose the wrong I see in our 14 May 2007 Spc4r11.
>
>
> Right way to move forward?
>
> *
> * 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
>
>
>
>   
*
* 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 jgeldman at lexar.com  Thu Jan  3 09:36:33 2008
From: jgeldman at lexar.com (jgeldman)
Date: Thu, 3 Jan 2008 09:36:33 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.15.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "jgeldman" <jgeldman at lexar.com>
*
For what it is worth, I think:
Ralph will think the repeated phrase is within editorial license.
I agree the proposed "zero" adds are a clarification and not a contradiction.
Requiring a proposal for adding "zero or" seems like overkill, but I don't
have an a strong opinion. 
But if a proposal is requested, I will dust off my copy of Word. (Ralph?)
John
-----Original Message-----
From: "Mark Evans" <Mark.Evans at wdc.com>
To: "Ralph Weber" <roweber at IEEE.org>
Cc: "plavarre at lexar.com" <plavarre at lexar.com>; "T10 at t10.org" <T10 at t10.org>
Sent: 1/3/2008 9:12 AM
Subject: RE: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
maybe
* From the T10 Reflector (t10 at t10.org), posted by:
* "Mark Evans" <Mark.Evans at wdc.com>
*
Hi Ralph,
Now what I think Pat is trying to do is to highlight that setting ALLOCATION
LENGTH to zero in an INQUIRY command is allowed, and that this setting may
be used as, "...a way of asking to test Command Out and Status In without
asking to test Data...".  However, I think this is covered.  Why the value
in the ALLOCATION LENGTH should be set to five or four is already explained
by the cross references in 6.4.1 INQUIRY command introduction, albeit not as
clearly as my suggested wording, but definitely more succinctly.  Wow.
Three "ly" adverbs in one sentence -- ha!
The qualification for the five or four in the ALLOCATION LENGTH field in an
INQUIRY command as defined in 6.4.1 is only a "should".  Based on that text,
zero is allowed as a value in the field for whatever reason.  In addition,
the second paragraph in 4.3.4.6 Allocation length reads, "An allocation
length of zero specifies that no data shall be transferred.  This condition
shall not be considered as an error."  So, 6.4.1 implicitly permits zero as
an allowed value for an INQUIRY command, and 4.3.4.6 explicity allows a
value of zero in an ALLOCATION LENGTH field for any command.
I think that there are many words that could be added to further explain the
setting of the ALLOCATION LENGTH field in an INQUIRY command.  However, "the
standard [already] says so."
Pat, if you want some more words in SPC-4, I'd suggest submitting a proposal
to T10, but based on what is already in the standard, I think you may have
tough sledding.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose,  CA  95138
Email: mark.evans at wdc.com
Office: 408.363.5257
Fax: 408.363.5139
Cell: 408.391.7805
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph Weber
Sent: Wednesday, January 02, 2008 7:26 PM
To: T10 at t10.org
Subject: Re: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
maybe
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Mark,
> ... The only possible clarification I can see is to explain
> a touch more about the reason for the five and four. ...
This of course assumes that some *reason* other than
"because the standard says so" is needed. :-)
All the best,
.Ralph
Mark Evans wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Mark Evans" <Mark.Evans at wdc.com>
> *
> Hi Pat,
>
> I'm not sure what you're trying to fix.  The only possible clarification I
> can see is to explain a touch more about the reason for the five and four.
> This could be done by adding a few words the paragraph you mention in
6.4.1
> INQUIRY command introduction as follows:
>
> The ALLOCATION LENGTH field is defined in 4.3.4.6.  If EVPD is set to
zero,
> then the allocation length should be at least five so that the ADDITIONAL
> LENGTH field (i.e., byte 4 in the standard INQUIRY data) is returned
> providing the application client with the length of the data available
(see
> 6.4.2).  If EVPD is set to one, then the allocation length should be
should
> be at least four so that the PAGE LENGTH field (i.e., byte 3 or bytes 2
and
> 3 in a vital product data page) is returned providing the application
client
> with the length of the data in the specified VPD page (see 7.6).
>
> The cross references are already in the paragraph, but I guess a few more
> words wouldn't hurt.	Am I missing the issue that you're trying to
resolve?
> Please let me know.
>
> Regards,
>
> Mark Evans
> Western Digital Corporation
> 5863 Rue Ferrari
> San Jose,  CA  95138
> Email: mark.evans at wdc.com
> Office: 408.363.5257
>
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
> plavarre at lexar.com
> Sent: Wednesday, January 02, 2008 1:15 PM
> To: T10 at t10.org
> Subject: RE: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
> maybe
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * <plavarre at lexar.com>
> *
> Here's one specific way we could correct the Spc4r11.pdf 6.4 Inquiry
> English:
>
>
> """The ALLOCATION LENGTH field is defined in 4.3.4.6. [+ The allocation
> length should be zero else at least four or five.] If EVPD is set to
> zero, the allocation length should be at least five, so that the
> ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is returned.
> If EVPD is set to one, the allocation length should be [- should be] at
> least four, so that the PAGE LENGTH field in the parameter data (see
> 7.6) is returned."""
>
>
> Like it?
>
>
> The [+] change notation indicates text I think we should add. The [-]
> change notation indicates text I think we should subtract. The
> """quotes""" enclose the wrong I see in our 14 May 2007 Spc4r11.
>
>
> Right way to move forward?
>
> *
> * 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
>
>
>
>   
*
* 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
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From raymond_gilson at symantec.com  Thu Jan  3 10:24:11 2008
From: raymond_gilson at symantec.com (Raymond Gilson)
Date: Thu, 3 Jan 2008 11:24:11 -0700
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.16.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Raymond Gilson" <raymond_gilson at symantec.com>
*
The problem with a new type is that you will need FOUR new types (5 - 8
are current shared access types of different flavors).	We have seven
available types left, so using four of them seems to be a bad idea (if
it can be avoided).
What if we added a bit to the "report capabilities", and "read
reservation" pages to report the support for or existence of the GRID
reservation.  Add a bit to the "PERSISENT RESERVE OUT" CDB to indicate
that the parameter list will fill in the GRID field.  The GRID will be
valid on a RESERVE service action and on a new "Join" service action.
Perhaps we can reclaim some of the currently "Obsolete" fields in the
parameter list for the GRID field?
An initiator would register, and reserve the device with the new GRID
field and CDB bit.  Other initiators can come along and read that the
reservation is a shared type but with GRID control.  They can then issue
the "Join" service action with the GRID field filled in.  If the correct
GRID value is sent, the target will accept the command, and allow the
new initiator to join the shared reservation.  If the GRID value is
incorrect, the target will fail the command.
Hopefully, the remainder of the functionality (preempt/abort etc) will
remain intact (and they must remain intact).
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Knight,
Frederick
Sent: Thursday, January 03, 2008 10:34 AM
To: Black_David at emc.com; Gerry.Houlder at seagate.com; t10 at t10.org
Subject: RE: Persistent Reservation Proposal - Group Reservations
* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
I'm still mulling over some of these discussions, but absolutely agree
with #1 - a new reservation type is preferred.
As for #2, I disagree.	How would I remove a single initiators
registration (preempt a single initiator from the group) if they all
must have the same KEY to join the group?
More comments later.
	Fred Knight
-----Original Message-----
From: Black_David at emc.com [mailto:Black_David at emc.com]
Sent: Thursday, January 03, 2008 9:19 AM
To: Gerry.Houlder at seagate.com; t10 at t10.org
Subject: RE: Persistent Reservation Proposal - Group Reservations
* From the T10 Reflector (t10 at t10.org), posted by:
* Black_David at emc.com
*
I'm still checking with our implementers, but my initial reaction is
that Gerry's 2-for-2:
(1) I strongly agree with Gerry's preference for a new RESERVATION
	type over a new REGISTRATION type.  PR code is already
	subtle in a number of ways, and a new reservation type is
	much easier to isolate from existing types in specification,
	coding, and testing.  It should also have better behavior
	when mixing implementations that don't all support the
	new functionality.  We probably need two new types, one
	for group write and one for group exclusive.
(2) Is there a reason why we can't use the existing reservation
	key as the entity that has to match for the new reservation
	type?  One would have to ensure that the reservation key
	can't be read from the device by PR IN, but we already
	have the precedent (and the specification text) to do
	that in the All Registrants reservation types.	Reuse of
	the reservation key is going to be easier to cope with
	than inventing a new group identifier.
What initiator implementations are likely to use this new functionality
for what purposes?
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953	      FAX: +1 (508) 293-7786
black_david at emc.com	   Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of 
> Gerry.Houlder at seagate.com
> Sent: Wednesday, January 02, 2008 4:40 PM
> To: t10 at t10.org
> Subject: RE: Persistent Reservation Proposal - Group Reservations
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gerry.Houlder at seagate.com
> *
> So this is Roger's preference:
> 
> >1) Define a new type of REGISTER that contains one (or more) GRIDs;
> >2) Extend RESERVE to include a single GRID, and only Initiators that
have
> registered (or will register) with a matching GRID get access under
the
> reservation;
> >3) Don't change PREEMPT, superseding reservations etc. at all - keep
the
> rules for handling the reservation keys completely orthogonal to the
GRID;
> >4) Don't allow GRIDs to be accessed via PR In.
> 
> If we don't add a new reservation type, it sounds like you are
describing a
> new registration type (existing one without GRID, new one with GRID).
This
> seems to complicate the rules for making an "all registrants"
reservation.
> If the initiator making the reservation specifies a GRID, only other 
> initiators that registered with that GRID value inherit the
reservation and
> the others are excluded. This would be a very different result for
current
> initiators that expect to inherit any reservations just by
registering.
> 
> Further, the "unexpectedly excluded" registered initiator will get no
clue
> as to why it doesn't inherit the reservation. if it issues READ
RESERVATION
> it gets back a response that says an all registrants reservation is in
> force. The PR generation and reservation key values returned won't
help any
> either, and the GROUP ID value of course will not be returned.
Creating a
> new reservation type would help here, since the reservation type is 
> returned by READ RESERVATION. This might be an advantage of creating a
new
> reservation type for GRID Registrants Only (or something like that).
The
> new reservation type would make it more obvious why you didn't inherit
a
> reservation you expected to inherit.
> 
> Also for backwards compatibility, will initiators be able to register
with
> existing method (i.e., not specifying a GROUP ID) as well as a new
method
> that specifies a GROUP ID? The standard will have to describe how 
> registrants without a group ID, registrants with a non-matching group
ID,
> and registrants with a matching group ID will interact with the
current
> registrants only reservation and a "GRID registrants only"
reservation.
> 
> Do we really lose that much if we simply create a "matching
reservation
> key" reservation instead? That means only initiators that register
with a
> matching reservation key inherit the reservation. We lose a little bit
of
> security because the matching ID value is publicly reported and a
malicious
> initiator can still join, but a malicous initiator could probably get 
> around the Group ID value match just by bute force retries anyway (how
many
> bytes of group ID is enough?), or just preempt the group ID
reservation and
> replace it with a regular registrants only reservation. This is a
simpler
> method of creating a Group ID reservation that probably works just
fine for
> co-operating initiators (as opposed to previously described malicious 
> ones).
> 
> *
> * 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
*
* 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  Thu Jan  3 10:15:50 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 3 Jan 2008 11:15:50 -0700
Subject: Group Reservations Phone Conference
Message-ID: <mailman.17.1441607335.22514.t10@sandbox.t10.org>

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

I posted a proposal for an addition to Persistent Reservations.  The 
proposal is 08-025r0 with an accompanying presentation to introduce the 
proposal which is 08-024r0.
http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
http://www.t10.org/ftp/t10/document.08/08-024r0.pdf
These generated much traffic and discussion of modifying the proposal to 
cover additional requirements.	These discussion included a request to 
have a phone conference to help people understand the problem(s) that are 
needed to be solved.  To that end I will be hosting a Group Reservations 
phone conference next week.  There will be no web conference utilities 
just audio. 
If you are interested in attending please let me know which of the 
following times is best for you.  I will select the time from the 
responses.
Monday, January 7, 9:00 - 10:00 AM MST
Monday, January 7, 1:00 - 2:00 PM MST
Tuesday, January 8, 9:00 - 10:00 AM MST
Tuesday, January 8, 1:00 - 2:00 PM MST
Wednesday, January 9, 9:00 - 10:00 AM MST
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


From roger_cummings at symantec.com  Thu Jan  3 10:39:45 2008
From: roger_cummings at symantec.com (Roger Cummings)
Date: Thu, 3 Jan 2008 11:39:45 -0700
Subject: Group Reservations Phone Conference
Message-ID: <mailman.18.1441607335.22514.t10@sandbox.t10.org>

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

Kevin,
Thanks for posting the new documents, and for offering to organize the
call. Any time that you propose OTHER than 1pm on Tuesday will work for
me. I also have a reservationless conference scheme that we can use if
that would help.
What I'm intending to do for this call next week is to try and take a
step back and document very simply what the problem is that we're trying
to solve (on which I think we have a good level of consensus), and then
try and list the specific requirements that need to be met by the
solution. I'm hoping that you think that would be useful.
My interpretation of the thread up until today is that we have three or
four different approaches to the solution, all of which will work at
some level, and that to be able to evaluate those approaches effectively
we'll need to agree what the requirements are and assign a weighting.
Also, for those who've just started to participate in this thread, I'd
like to reiterate something that Kevin said in his first message
responding to my comments on his original posting. He said:
"I would prefer that we work together to shape a mutually beneficial
proposal as opposed to have "competing" proposals.  I am willing to
modify my proposal where it can be made easier and such.  I am not sold
that my proposed method is the only way or even the best - it's just the
way I thought of doing it."
I think these are admirable sentiments: I agree with them 110% and I
hope that everybody else does too. We MUST end up with something here
that we can all live with - we MUST NOT end up with two different ways
of doing this, one will be complicated enough!
Regards,
Roger Cummings
SYMANTEC
roger_cummings at symantec.com
________________________________
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Thursday, January 03, 2008 1:16 PM
To: t10 at t10.org
Cc: Black_David at emc.com; Gerry.Houlder at seagate.com; Knight, Frederick;
Raymond Gilson; Roger Cummings; Keith Bello; Christine R Knibloe; Andrew
Hisgen; roweber at ieee.org; John Lohmeyer
Subject: Group Reservations Phone Conference
	I posted a proposal for an addition to Persistent Reservations.
The proposal is 08-025r0 with an accompanying presentation to introduce
the proposal which is 08-024r0. 
	http://www.t10.org/ftp/t10/document.08/08-025r0.pdf 
	http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
	These generated much traffic and discussion of modifying the
proposal to cover additional requirements.  These discussion included a
request to have a phone conference to help people understand the
problem(s) that are needed to be solved.  To that end I will be hosting
a Group Reservations phone conference next week.  There will be no web
conference utilities just audio.   
	If you are interested in attending please let me know which of
the following times is best for you.  I will select the time from the
responses. 
	Monday, January 7, 9:00 - 10:00 AM MST 
	Monday, January 7, 1:00 - 2:00 PM MST 
	Tuesday, January 8, 9:00 - 10:00 AM MST 
	Tuesday, January 8, 1:00 - 2:00 PM MST 
	Wednesday, January 9, 9:00 - 10:00 AM MST 
	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/ 


From roweber at ieee.org  Thu Jan  3 09:32:08 2008
From: roweber at ieee.org (Ralph Weber)
Date: Thu, 03 Jan 2008 11:32:08 -0600
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.19.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Mark,
What is wrong with TEST UNIT READY as a way to validate Command Out
and Status In processing?
Curious in Dallas,
.Ralph
Mark Evans wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Mark Evans" <Mark.Evans at wdc.com>
> *
> Hi Ralph,
>
> Now what I think Pat is trying to do is to highlight that setting
ALLOCATION
> LENGTH to zero in an INQUIRY command is allowed, and that this setting may
> be used as, "...a way of asking to test Command Out and Status In without
> asking to test Data...".  However, I think this is covered.  Why the value
> in the ALLOCATION LENGTH should be set to five or four is already explained
> by the cross references in 6.4.1 INQUIRY command introduction, albeit not
as
> clearly as my suggested wording, but definitely more succinctly.  Wow.
> Three "ly" adverbs in one sentence -- ha!
>
> The qualification for the five or four in the ALLOCATION LENGTH field in an
> INQUIRY command as defined in 6.4.1 is only a "should".  Based on that
text,
> zero is allowed as a value in the field for whatever reason.	In addition,
> the second paragraph in 4.3.4.6 Allocation length reads, "An allocation
> length of zero specifies that no data shall be transferred.  This condition
> shall not be considered as an error."  So, 6.4.1 implicitly permits zero as
> an allowed value for an INQUIRY command, and 4.3.4.6 explicity allows a
> value of zero in an ALLOCATION LENGTH field for any command.
>
> I think that there are many words that could be added to further explain
the
> setting of the ALLOCATION LENGTH field in an INQUIRY command.  However,
"the
> standard [already] says so."
>
> Pat, if you want some more words in SPC-4, I'd suggest submitting a
proposal
> to T10, but based on what is already in the standard, I think you may have
> tough sledding.
>
> Regards,
>
> Mark Evans
> Western Digital Corporation
> 5863 Rue Ferrari
> San Jose,  CA  95138
> Email: mark.evans at wdc.com
> Office: 408.363.5257
> Fax: 408.363.5139
> Cell: 408.391.780
*
* 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  Thu Jan  3 10:58:57 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 3 Jan 2008 11:58:57 -0700
Subject: Group Reservations Phone Conference
Message-ID: <mailman.20.1441607335.22514.t10@sandbox.t10.org>

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

Roger,
Thanks.
First, I have lost the ability to attend the Wednesday time.  Since you 
are also key in determining the problem(s) we are trying to solve we are 
left with the following potential times:
Monday, January 7, 9:00 - 10:00 AM MST 
Monday, January 7, 1:00 - 2:00 PM MST 
Tuesday, January 8, 9:00 - 10:00 AM MST 
Also, I agree with your statement <<What I'm intending to do for this call 
next week is to try and take a step back and document very simply what the 
problem is that we're trying to solve (on which I think we have a good 
level of consensus), and then try and list the specific requirements that 
need to be met by the solution. I'm hoping that you think that would be 
useful.>> and the intent of the call is to focus on what you have 
succinctly stated here.
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/ 
"Roger Cummings" <roger_cummings at symantec.com> 
01/03/2008 11:39 AM
To
Kevin D Butt/Tucson/IBM at IBMUS, <t10 at t10.org>
cc
<Black_David at emc.com>, <Gerry.Houlder at seagate.com>, "Knight, Frederick" 
<Frederick.Knight at netapp.com>, "Raymond Gilson" 
<raymond_gilson at symantec.com>, Keith Bello/Tucson/IBM at IBMUS, Christine R 
Knibloe/Tucson/IBM at IBMUS, "Andrew Hisgen" <Andrew.Hisgen at Sun.COM>, 
<roweber at ieee.org>, "John Lohmeyer" <lohmeyer at t10.org>
Subject
RE: Group Reservations Phone Conference
Kevin,
Thanks for posting the new documents, and for offering to organize the 
call. Any time that you propose OTHER than 1pm on Tuesday will work for 
me. I also have a reservationless conference scheme that we can use if 
that would help.
What I'm intending to do for this call next week is to try and take a step 
back and document very simply what the problem is that we're trying to 
solve (on which I think we have a good level of consensus), and then try 
and list the specific requirements that need to be met by the solution. 
I'm hoping that you think that would be useful.
My interpretation of the thread up until today is that we have three or 
four different approaches to the solution, all of which will work at some 
level, and that to be able to evaluate those approaches effectively we'll 
need to agree what the requirements are and assign a weighting.
Also, for those who've just started to participate in this thread, I'd 
like to reiterate something that Kevin said in his first message 
responding to my comments on his original posting. He said:
"I would prefer that we work together to shape a mutually beneficial 
proposal as opposed to have "competing" proposals.  I am willing to modify 
my proposal where it can be made easier and such.  I am not sold that my 
proposed method is the only way or even the best - it's just the way I 
thought of doing it."
I think these are admirable sentiments: I agree with them 110% and I hope 
that everybody else does too. We MUST end up with something here that we 
can all live with - we MUST NOT end up with two different ways of doing 
this, one will be complicated enough!
Regards,
Roger Cummings
SYMANTEC
roger_cummings at symantec.com
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Thursday, January 03, 2008 1:16 PM
To: t10 at t10.org
Cc: Black_David at emc.com; Gerry.Houlder at seagate.com; Knight, Frederick; 
Raymond Gilson; Roger Cummings; Keith Bello; Christine R Knibloe; Andrew 
Hisgen; roweber at ieee.org; John Lohmeyer
Subject: Group Reservations Phone Conference
I posted a proposal for an addition to Persistent Reservations.  The 
proposal is 08-025r0 with an accompanying presentation to introduce the 
proposal which is 08-024r0. 
http://www.t10.org/ftp/t10/document.08/08-025r0.pdf 
http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
These generated much traffic and discussion of modifying the proposal to 
cover additional requirements.	These discussion included a request to 
have a phone conference to help people understand the problem(s) that are 
needed to be solved.  To that end I will be hosting a Group Reservations 
phone conference next week.  There will be no web conference utilities 
just audio.   
If you are interested in attending please let me know which of the 
following times is best for you.  I will select the time from the 
responses. 
Monday, January 7, 9:00 - 10:00 AM MST 
Monday, January 7, 1:00 - 2:00 PM MST 
Tuesday, January 8, 9:00 - 10:00 AM MST 
Tuesday, January 8, 1:00 - 2:00 PM MST 
Wednesday, January 9, 9:00 - 10:00 AM MST 
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/ 


From kdbutt at us.ibm.com  Thu Jan  3 10:51:06 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 3 Jan 2008 11:51:06 -0700
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.21.1441607335.22514.t10@sandbox.t10.org>

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

We looked at using the existing reservation key but could not make it work 
because, among other things, it is returned in PR In and it's behavior is 
assumed to be non unique by existing applications.  For these reasons we 
did not spend too much time looking at it.
IBM has one intent, but I found that there are at least two others, Roger 
Cummings and Fred Knight, that have different intents.	Roger was thinking 
of bringing something similar in himself - though it is subtly different. 
I am not sure I understand all those subtleties.
The basic intent I was aiming for is for use in the tape drives (making 
sure it is also good for disks).  There is a need to have any reservation 
solidly exclusive to a given host.  However, it is desirable to allow 
multiple HBA's on the same host to have that exclusive access.	This 
allows for load balancing and failover internal to the same host.  Add to 
that the need to allow for failover to a second host - also with multiple 
HBA's but guaranteeing that if whatever out of band communication is 
occurring between he two hosts fails that the two hosts will be protected 
|from each other.  That is, if somehow each host thinks it should have the 
access, the tape drive is still protected such that only one host at a 
time can have permission to access the drive.  If host A thinks host B 
went away and steals the reservation (a la PREEMPT) host B will no longer 
have permission and will get a UA next time it tries access.  Add to this 
the ability for the tape drive to be shared in an open system and still 
have this work.
In reality, this is nothing more than each HBA on a single host being able 
to share an exclusive reservation and no other initiator port can join in 
without the owner telling it how to.
I sent another note planning a phone conference so we can clearly lay out 
the desired intent.  Please respond to that note.
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/ 
Black_David at emc.com 
Sent by: owner-t10 at t10.org
01/03/2008 07:19 AM
To
<Gerry.Houlder at seagate.com>, <t10 at t10.org>
cc
Subject
RE: Persistent Reservation Proposal - Group Reservations
* From the T10 Reflector (t10 at t10.org), posted by:
* Black_David at emc.com
*
I'm still checking with our implementers, but my initial reaction
is that Gerry's 2-for-2:
(1) I strongly agree with Gerry's preference for a new RESERVATION
		 type over a new REGISTRATION type.  PR code is already
		 subtle in a number of ways, and a new reservation type is
		 much easier to isolate from existing types in 
specification,
		 coding, and testing.  It should also have better behavior
		 when mixing implementations that don't all support the
		 new functionality.  We probably need two new types, one
		 for group write and one for group exclusive.
(2) Is there a reason why we can't use the existing reservation
		 key as the entity that has to match for the new 
reservation
		 type?	One would have to ensure that the reservation key
		 can't be read from the device by PR IN, but we already
		 have the precedent (and the specification text) to do
		 that in the All Registrants reservation types.  Reuse of
		 the reservation key is going to be easier to cope with
		 than inventing a new group identifier.
What initiator implementations are likely to use this new
functionality for what purposes?
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953	      FAX: +1 (508) 293-7786
black_david at emc.com	   Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf 
> Of Gerry.Houlder at seagate.com
> Sent: Wednesday, January 02, 2008 4:40 PM
> To: t10 at t10.org
> Subject: RE: Persistent Reservation Proposal - Group Reservations
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gerry.Houlder at seagate.com
> *
> So this is Roger's preference:
> 
> >1) Define a new type of REGISTER that contains one (or more) GRIDs;
> >2) Extend RESERVE to include a single GRID, and only Initiators that
have
> registered (or will register) with a matching GRID get access under
the
> reservation;
> >3) Don't change PREEMPT, superseding reservations etc. at all - keep
the
> rules for handling the reservation keys completely orthogonal to the
GRID;
> >4) Don't allow GRIDs to be accessed via PR In.
> 
> If we don't add a new reservation type, it sounds like you are
describing a
> new registration type (existing one without GRID, new one with GRID).
This
> seems to complicate the rules for making an "all registrants"
reservation.
> If the initiator making the reservation specifies a GRID, only other
> initiators that registered with that GRID value inherit the
reservation and
> the others are excluded. This would be a very different result for
current
> initiators that expect to inherit any reservations just by
registering.
> 
> Further, the "unexpectedly excluded" registered initiator will get no
clue
> as to why it doesn't inherit the reservation. if it issues READ
RESERVATION
> it gets back a response that says an all registrants reservation is in
> force. The PR generation and reservation key values returned won't
help any
> either, and the GROUP ID value of course will not be returned.
Creating a
> new reservation type would help here, since the reservation type is
> returned by READ RESERVATION. This might be an advantage of creating a
new
> reservation type for GRID Registrants Only (or something like that).
The
> new reservation type would make it more obvious why you didn't inherit
a
> reservation you expected to inherit.
> 
> Also for backwards compatibility, will initiators be able to register
with
> existing method (i.e., not specifying a GROUP ID) as well as a new
method
> that specifies a GROUP ID? The standard will have to describe how
> registrants without a group ID, registrants with a non-matching group
ID,
> and registrants with a matching group ID will interact with the
current
> registrants only reservation and a "GRID registrants only"
reservation.
> 
> Do we really lose that much if we simply create a "matching
reservation
> key" reservation instead? That means only initiators that register
with a
> matching reservation key inherit the reservation. We lose a little bit
of
> security because the matching ID value is publicly reported and a
malicious
> initiator can still join, but a malicous initiator could probably get
> around the Group ID value match just by bute force retries anyway (how
many
> bytes of group ID is enough?), or just preempt the group ID
reservation and
> replace it with a regular registrants only reservation. This is a
simpler
> method of creating a Group ID reservation that probably works just
fine for
> co-operating initiators (as opposed to previously described malicious
> ones).
> 
> *
> * 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 mikeb at bustrace.com  Thu Jan  3 11:05:54 2008
From: mikeb at bustrace.com (Mike Berhan)
Date: Thu, 3 Jan 2008 11:05:54 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.22.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
> What is wrong with TEST UNIT READY as a way to validate Command Out
> and Status In processing?
Two reasons come to mind:
1.)  Some pseudo devices do not support TUR.  Only Inquiry and their vendor
unique CDBs.
2.)  Perhaps the software making the call doesn't want to clear out any
pending Unit Attention.
Mike
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From plavarre at lexar.com  Thu Jan  3 11:31:58 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Thu, 3 Jan 2008 11:31:58 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.23.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
Ralph,
> Mark,
I take the liberty of adding my answer in parallel ...
> What is wrong with TEST UNIT READY as a way to validate Command Out
and Status In processing?
Yes much of the time TEST UNIT READY exercises Command Out and Status In
without Data.
Specifically this works any time media happens to be present in the
logical unit and happens to be readable and happens to have no unit
attentions pending for it.
TEST UNIT READY disrupts the bus violently otherwise -- the first
trouble is CHECK CONDITION, and then all the consequences that may
follow, e.g., some SCSI transports that follow up CHECK CONDITION with
REQUEST SENSE, such as USB and FireWire and ATAPI. The REQUEST SENSE
requires Data processing to move the sense data, which implies arcane
complexities like negotiated data rates and recovering from
non-quad-aligned REQUEST SENSE allocation lengths like the 12h (18)
popular in Windows bus traces.
All the same, INQUIRY for zero is less common than TEST UNIT READY. So
arguably the host should use TEST UNIT READY to exercise Command Out and
Status In, except when the device may be exercising the option of
removable media.
*
* 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 wdc.com  Thu Jan  3 12:10:56 2008
From: Mark.Evans at wdc.com (Mark Evans)
Date: Thu, 3 Jan 2008 12:10:56 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.24.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Mark Evans" <Mark.Evans at wdc.com>
*
Hi Ralph,
Don't ask me.  I was just trying to put in words where I thought Pat was
going.	Upon further review, I think that the play stands as called in the
standard.
Please feel free to call or send an email to me if you have any questions or
comments about this stuff.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at wdc.com
Office: 408.363.5257
Fax: 408.363.5139
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph Weber
Sent: Thursday, January 03, 2008 9:32 AM
To: T10 at t10.org
Subject: Re: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
maybe
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Mark,
What is wrong with TEST UNIT READY as a way to validate Command Out and
Status In processing?
Curious in Dallas,
.Ralph
Mark Evans wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Mark Evans" <Mark.Evans at wdc.com>
> *
> Hi Ralph,
>
> Now what I think Pat is trying to do is to highlight that setting 
> ALLOCATION LENGTH to zero in an INQUIRY command is allowed, and that 
> this setting may be used as, "...a way of asking to test Command Out 
> and Status In without asking to test Data...".  However, I think this 
> is covered.  Why the value in the ALLOCATION LENGTH should be set to 
> five or four is already explained by the cross references in 6.4.1 
> INQUIRY command introduction, albeit not as clearly as my suggested
wording, but definitely more succinctly.  Wow.
> Three "ly" adverbs in one sentence -- ha!
>
> The qualification for the five or four in the ALLOCATION LENGTH field 
> in an INQUIRY command as defined in 6.4.1 is only a "should".  Based 
> on that text, zero is allowed as a value in the field for whatever 
> reason.  In addition, the second paragraph in 4.3.4.6 Allocation 
> length reads, "An allocation length of zero specifies that no data 
> shall be transferred.  This condition shall not be considered as an 
> error."  So, 6.4.1 implicitly permits zero as an allowed value for an 
> INQUIRY command, and 4.3.4.6 explicity allows a value of zero in an
ALLOCATION LENGTH field for any command.
>
> I think that there are many words that could be added to further 
> explain the setting of the ALLOCATION LENGTH field in an INQUIRY 
> command.  However, "the standard [already] says so."
>
> Pat, if you want some more words in SPC-4, I'd suggest submitting a 
> proposal to T10, but based on what is already in the standard, I think 
> you may have tough sledding.
>
> Regards,
>
> Mark Evans
> Western Digital Corporation
> 5863 Rue Ferrari
> San Jose,  CA  95138
> Email: mark.evans at wdc.com
> Office: 408.363.5257
> Fax: 408.363.5139
> Cell: 408.391.780
*
* 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 Gerry.Houlder at seagate.com  Thu Jan  3 14:24:10 2008
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Thu, 3 Jan 2008 16:24:10 -0600
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.25.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
The primary concern expressed by Pat Lavarre and Mr. Geldman seems to be
making sure an Inquiry command with zero for allocation length is always
allowed. Would adding the sentences enclosed in [[... ]] solve those
concerns?
"The ALLOCATION LENGTH field is defined in 4.3.4.6. [[An allocation length
of zero specifies that no data shall be transferred. This condition shall
not be considered as an error.]] If EVPD is set to zero, the allocation
length should be at least five, so that the ADDITIONAL LENGTH field in the
parameter data (see 6.4.2) is returned. If EVPD is set to one, the
allocation length should be should be at least four, so that the PAGE
LENGTH field in the parameter data (see 7.6) is returned."
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Gerry.Houlder at seagate.com  Thu Jan  3 15:10:23 2008
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Thu, 3 Jan 2008 17:10:23 -0600
Subject: Two Persistent Reservation questions
Message-ID: <mailman.26.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
In the course of reviewing SPC-4 rev. 11, I encountered this wording
defining who is a reservation holder:
5.6.9 Persistent reservation holder
The persistent reservation holder is determined by the type of the
persistent reservation as follows:
a) For a persistent reservation of the type Write Exclusive - All
Registrants or Exclusive Access - All Registrants,
the persistent reservation holder is any registered I_T nexus; or
b) For all other persistent reservation types, the persistent reservation
holder is the I_T nexus:
    A) For which the reservation was established with a PERSISTENT RESERVE
OUT command with
    REGISTER service action, REGISTER AND IGNORE EXISTING KEY service
action, PREEMPT
    service action, or PREEMPT AND ABORT service action; or
    B) To which the reservation was moved by a PERSISTENT RESERVE OUT
command with REGISTER
    AND MOVE service action.
(1) For item b), why isn't an I_T nexus that established a reservation
using PR OUT command with RESERVE service action listed as the reservation
holder?
(2) Also for item b), how does an I_T nexus become the reservation holder
using a REGISTER or REGISTER AND IGNORE EXISTING KEY service action? I can
understand these cases for an All Registrants type [covered in item a) ]
but not for Exclusive Access type.
Any explanation of this would be appreciated.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From plavarre at lexar.com  Thu Jan  3 15:44:23 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Thu, 3 Jan 2008 15:44:23 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.27.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
Gerry,
I see you proposing this change:
"""The ALLOCATION LENGTH field is defined in 4.3.4.6. [+ An allocation
length of zero specifies that no data shall be transferred. This
condition shall not be considered as an error.] If EVPD is set to zero,
the allocation length should be at least five, so that the ADDITIONAL
LENGTH field in the parameter data (see 6.4.2) is returned. If EVPD is
set to one, the allocation length should be should be at least four, so
that the PAGE LENGTH field in the parameter data (see 7.6) is
returned."""
I agree inserting those shall redundancies at that point would improve
the clarity of our problematic shall text ... but I think that specific
proposal affects only the unclear shall's without actually correcting
our broken should's.
I think the change that's more worthwhile is fixing the broken should's.
Personally I don't mind if we ever bother clarifying the problematic
shall's or not.
The broken should's I see are like this:
i) """If EVPD is set to zero, the allocation length should be at least
five, ..."""
ii) """If EVPD is set to one, the allocation length should be ... at
least four, ..."""
Get it?
My reading of that pair of should's comes out of the context that I
remember that we always set the EVPD bit of the CDB to zero or to one,
because the EVPD is a single real bit of the CDB, and of course all real
bits are only zero or one in any actual instance. Thus any pair of
claims deciding EVPD zero and then also deciding EVPD one implicitly
presents a claim for always.
I therefore see us saying the allocation length should always be at
least four.
That claim is false by overstatement. We actually mean to say the
allocation length should always be at least four when the allocation
length is not zero. For example, we could say:
"""In order to get the information that tells you how many bytes of data
are available the allocation length must be at least this big. If you
don't care about retrieving the Page Length parameter or the Available
Length parameter then you don't have to follow this suggestion."""
All the same, I guess changing over to plain English like that would be
too big of a change. So instead I suggest the small corrections:
"""The ALLOCATION LENGTH field is defined in 4.3.4.6. If EVPD is set to
zero, the allocation length should be [+ zero else should be] at least
five, so that the ADDITIONAL LENGTH field in the parameter data (see
6.4.2) is returned. If EVPD is set to one, the allocation length should
be [+ zero else] should be at least four, so that the PAGE LENGTH field
in the parameter data (see 7.6) is returned."""
That newest change proposal lets us keep all three of the original
should's, but adds a fourth should and a few words to make the whole
thing actually say what we mean.
Like it?
Hope this helps, curiously yours, Pat LaVarre
*
* 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  Thu Jan  3 16:48:18 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 3 Jan 2008 17:48:18 -0700
Subject: SMC-3 Action Item Reminder
Message-ID: <mailman.28.1441607335.22514.t10@sandbox.t10.org>

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

All SMC-3 Action Item holders.	Here is a reminder of action items 
generated during the November SMC-3 Working Group.
06-020	[Robert Payne] Define a philosophy for Write Exclusive Persistent 
Reservations in SMC.
06-044	[Roger Cummings] Solicit additional vendor-specific sense codes 
|from library vendors per June discussion item 4.4.
06-063	[Noud Snelder] Investigate use of LOGICAL UNIT NOT READY, 
INITIALIZING COMMAND REQUIRED error code.
07-003	[Curtis Ballard] Create a proposal to define the usage of the 
?Cleaning Requested? and ?Cleaning Failure? error codes.
07-006	[Rod Wideman] Define a new ASC/ASCQ for ?Logical Unit Not Ready ? 
Robotics Disabled?.
07-017	[Group] Make sure the all the functionality of Read Element Status 
is covered by the Report Element Information command (06-272) and the 
Report Volume Information command and examine if an informative annex to 
map the RES command onto these is appropriate. [Reminder to do as final 
step]
07-027	[Rod Wideman] Revise and post SMC-3 New Additional Sense Codes 
Usage (07-018r0) as 07-018r1.
07-042	[Paul Entzel] Write a proposal for the commands which the cached 
ready state in ADC may be used.
07-058	[Kevin Butt] Revise SMC-3: Medium Magazine Error Codes (07-372r0) 
and post.
07-059	[Noud Snelder] Noud Snelder Revise SMC-3 Additional sense code for 
in?compatible destination element (07-222r1) and post.
05Nov07-01	[Kevin Butt]: Determine what actions set TapeAlert flag 
19h (illegal operation) and when the flag is cleared. Also what actions 
does it generate?
05Nov07-02	[Curtis Ballard]: Determine what actions set TapeAlert 
flag 19h (illegal operation) and when the flag is cleared. Also what 
actions does it generate?
05Nov07-03	[Erich Oetting]: Determine what actions set TapeAlert flag 
19h (illegal operation) and when the flag is cleared. Also what actions 
does it generate?
05Nov07-04	[Rod Wideman]: Determine what actions set TapeAlert flag 
19h (illegal operation) and when the flag is cleared. Also what actions 
does it generate?
05Nov07-05	[Halvard Eriksen]: Determine what actions set TapeAlert 
flag 19h (illegal operation) and when the flag is cleared. Also what 
actions does it generate?
05Nov07-06	[Noud Snelder]: Determine what actions set TapeAlert flag 
19h (illegal operation) and when the flag is cleared. Also what actions 
does it generate?
05Nov07-07	[Nould Snelder] to incorporate SMC-3 Additional sense code 
for incompatible destination element (07-222r1) as revised.
05Nov07-08	[Group] review SMC-3 for changing SPC-3 references to 
SPC-4.
05Nov07-09	[Noud Snelder] to revise and post SMC-3, READ ATTRIBUTE 
and WRITE ATTRIBUTE command clarification (07-244r2).
05Nov07-10	[Noud Snelder] to incorporate SMC-3, READ ATTRIBUTE and 
WRITE AT?TRIBUTE command clarification (07-244r2) as revised into SMC-3.
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 kdbutt at us.ibm.com  Thu Jan  3 16:55:24 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 3 Jan 2008 17:55:24 -0700
Subject: SSC-3 Action Item Reminder
Message-ID: <mailman.29.1441607335.22514.t10@sandbox.t10.org>

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

This is a reminder of the Action Items still outstanding in the SSC-3 
Working Group.
Dave Peterson: Bring in a White Paper on the value added with Explicit 
Command Set.
Dave Peterson incorporate TapeAlert Delineation (06-138r6) into SSC-3
Dave Peterson to incorporate Requested Recovery log page (07-046r3)
Paul Suhler will provide his companies definition of medium as a selection 
|from Section 5.1.2
Kevin Butt will provide his companies definition of medium as a selection 
|from Section 5.1.2
Erich Oetting will provide his companies definition of medium as a 
selection from Section 5.1.2
Paul Suhler to provide his companies answer to ?Should a device server 
allow host write access to MAM on a write protected volume??
Erich Oetting to provide his companies answer to ?Should a device server 
allow host write access to MAM on a write protected volume??
Fred Knight to invistigate if the version byte and the format byte from 
the LABEL field from Table 123 in SSC-3r03e can be removed.
Dave Peterson to incorporate Protecting a partially encrypted volume 
(07-290r3) into SSC-3.
Paul Suhler assign an owner from the ADI group for item 2.7 of 05-351r1 
which is to provide a means for the library Serial Number to be reported 
by the Tape Drive.
Curtis Ballard to revise and post SSC-3: Out of Band Encryption Key 
Management (07-361r4)
Dave Peterson to incorporate SSC-3: Out of Band Encryption Key Management 
(07-361r5) into SSC-3.
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 kdbutt at us.ibm.com  Thu Jan  3 17:59:26 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 3 Jan 2008 18:59:26 -0700
Subject: Group Reservations Phone Conference Time
Message-ID: <mailman.30.1441607335.22514.t10@sandbox.t10.org>

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

There will be a phone conference to discuss very simply what the problem 
is that we're trying to solve with the Group Reservations, and then try 
and list the specific requirements that need to be met by the solution. 
TIME: 9:00 AM to 10:00 AM MST
TOLL FREE: 1-877-421-0017
TOLL:		1-770-615-1378
ID: 986327
Unfortunately, there was a conflict returned with every time slot listed. 
However, for those that have been involved in the conversation and 
contributing comments to date it looks like they can all make the Monday 
9:00 - 10:00 AM MST time slot.	Sorry to those who can't make Monday.
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


From roweber at ieee.org  Thu Jan  3 18:35:29 2008
From: roweber at ieee.org (Ralph Weber)
Date: Thu, 03 Jan 2008 20:35:29 -0600
Subject: DS_SAI length conflict between 07-437r4 and 07-169 & SPC-4
Message-ID: <mailman.31.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
David,
I am having the dickens of a time comprehending why a device server
needs as many SAIs as an OSD has partitions. What am I missing?
All the best,
.Ralph
Black_David at emc.com wrote:
> Kevin,
> We need to make a decision on this one because there is no obvious
> right answer. IETF uses separate SPIs (what T10 calls SAIs) for
> IKEv2 and ESP - 8 bytes SPIs are used for IKEv2, but ESP uses 4 byte
> SPIs. SCSI is using the same SPI for both purposes, and hence needs
> to pick one length - I agree with your suggestion that 8 bytes (as
> used in IKEv2-SCSI) is preferable. >From an implementation standpoint
> this would reduce the impact on reuse of the more complex IKEv2
> implementations (more complex is by comparison to ESP).
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA 01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> black_david at emc.com Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
>
>    
------------------------------------------------------------------------
>     *From:* Kevin D Butt [mailto:kdbutt at us.ibm.com]
>     *Sent:* Friday, December 21, 2007 11:24 AM
>     *To:* roweber at ieee.org; Black, David; matt.ball at ieee.org
>     *Cc:* t10 at t10.org
>     *Subject:* DS_SAI length conflict between 07-437r4 and 07-169 & SPC-4
>
>
>     Ralph, David, and Matt,
>
>     All the DS_SAI values in the ESP-SCSI (07-169r5) (e.g., Table x3 ?
>     ESP-SCSI data-out buffer parameter list descriptor without
>     initialization vector) are shown as 4-byte values as they are in
>     SPC-4 Table 44 ? Minimum SA parameters. However 07-437r4 shows
>     them as 8-byte values. I think 07-437r4 is correct and SPC-4 and
>     07-169 need to be modified to match.
>
>     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/ 
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Frederick.Knight at netapp.com  Fri Jan  4 07:50:22 2008
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Fri, 4 Jan 2008 10:50:22 -0500
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.32.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
I think that sentence is what Ralph pointed out is already
there in the section referenced (so no need to duplicate).
Here's another suggestion of what I understand their after:
"The ALLOCATION LENGTH field is defined in 4.3.4.6. If EVPD is set to
zero, the allocation length should be [[either zero, or]] at least five,
so that the ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is
returned. If EVPD is set to one, the allocation length should be should
be at least four, so that the PAGE LENGTH field in the parameter data
(see 7.6) is returned." 
	Fred Knight
-----Original Message-----
From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com] 
Sent: Thursday, January 03, 2008 5:24 PM
To: t10 at t10.org
Subject: RE: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
maybe
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
The primary concern expressed by Pat Lavarre and Mr. Geldman seems to be
making sure an Inquiry command with zero for allocation length is always
allowed. Would adding the sentences enclosed in [[... ]] solve those
concerns?
"The ALLOCATION LENGTH field is defined in 4.3.4.6. [[An allocation
length of zero specifies that no data shall be transferred. This
condition shall not be considered as an error.]] If EVPD is set to zero,
the allocation length should be at least five, so that the ADDITIONAL
LENGTH field in the parameter data (see 6.4.2) is returned. If EVPD is
set to one, the allocation length should be should be at least four, so
that the PAGE LENGTH field in the parameter data (see 7.6) is returned."
*
* 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 plavarre at lexar.com  Fri Jan  4 09:06:16 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Fri, 4 Jan 2008 09:06:16 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.33.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
Ah wonderful.
Yes I agree this newly suggested phrase of "either zero, or" says what
we always have meant slightly better than the earlier suggestion of the
phrase "zero, else".
I also notice this last retyping of the paragraph didn't bother to
correct the famous "should be should be" tupo.
Thus I think Frederick meant to suggest:
"""The ALLOCATION LENGTH field is defined in 4.3.4.6. If EVPD is set to
zero, the allocation length should be [+ either zero, or] at least five,
so that the ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is
returned. If EVPD is set to one, the allocation length should be [-
should be] at least four, so that the PAGE LENGTH field in the parameter
data (see 7.6) is returned."""
I think that form includes a new claim. I'm ok with new claims so long
as we agree the new claims are new and true.
The new claim here is that the allocation length should be nonzero when
EVPD is set to one.
I think that should is false. I think we're ok with a host trying to
discover the lack of EVPD support by setting EVPD to one without setting
allocation length nonzero. Consequently I guess the best correction
found so far would be two insertions and one deletion:
"""The ALLOCATION LENGTH field is defined in 4.3.4.6. If EVPD is set to
zero, the allocation length should be [+ either zero, or] at least five,
so that the ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is
returned. If EVPD is set to one, the allocation length should be [-
should be] [+ either zero, or] at least four, so that the PAGE LENGTH
field in the parameter data (see 7.6) is returned."""
Is that right? And good enough?
Curiously yours, hope this helps, thanks in advance, Pat LaVarre
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Frederick.Knight at netapp.com  Fri Jan  4 09:11:34 2008
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Fri, 4 Jan 2008 12:11:34 -0500
Subject: Two Persistent Reservation questions
Message-ID: <mailman.34.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
This changed between spc3r21a (11/2004) and spc3r22 (3/2005).
Also interesting that spc3r21a mentions the RESERVE, RESERVE AND IGNORE
EXISTING KEY (interesting typo), and some other service actions.
HP letter ballot comment 102/103 change 3 references in 5.6.9 from
"RESERVED" to "REGISTER" - see
http://www.t10.org/ftp/t10/document.04/04-355r9.pdf; maybe that is where
it changed.
	Fred
-----Original Message-----
From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com] 
Sent: Thursday, January 03, 2008 6:10 PM
To: t10 at t10.org
Subject: Two Persistent Reservation questions
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
In the course of reviewing SPC-4 rev. 11, I encountered this wording
defining who is a reservation holder:
5.6.9 Persistent reservation holder
The persistent reservation holder is determined by the type of the
persistent reservation as follows:
a) For a persistent reservation of the type Write Exclusive - All
Registrants or Exclusive Access - All Registrants, the persistent
reservation holder is any registered I_T nexus; or
b) For all other persistent reservation types, the persistent
reservation holder is the I_T nexus:
    A) For which the reservation was established with a PERSISTENT
RESERVE OUT command with
    REGISTER service action, REGISTER AND IGNORE EXISTING KEY service
action, PREEMPT
    service action, or PREEMPT AND ABORT service action; or
    B) To which the reservation was moved by a PERSISTENT RESERVE OUT
command with REGISTER
    AND MOVE service action.
(1) For item b), why isn't an I_T nexus that established a reservation
using PR OUT command with RESERVE service action listed as the
reservation holder?
(2) Also for item b), how does an I_T nexus become the reservation
holder using a REGISTER or REGISTER AND IGNORE EXISTING KEY service
action? I can understand these cases for an All Registrants type
[covered in item a) ] but not for Exclusive Access type.
Any explanation of this would be appreciated.
*
* 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  Fri Jan  4 10:03:07 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Fri, 4 Jan 2008 11:03:07 -0700
Subject: SSC-3 Action Item Reminder
Message-ID: <mailman.35.1441607335.22514.t10@sandbox.t10.org>

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

Fred,
I think you left off T10 from the distribution accidentally.  I have 
included the reflector.
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/ 
"Knight, Frederick" <Frederick.Knight at netapp.com> 
01/04/2008 09:20 AM
To
Kevin D Butt/Tucson/IBM at IBMUS
cc
Subject
RE: SSC-3 Action Item Reminder
My action below re: table 123 in SSC-3r03e.  I have no issue with removing 
the version byte, and the format byte.
The question about those fields had to do their layout and intended use:
 byte 2-3 - specifies the length of the label field (upto 64k)
 byte 4 - version byte or format byte - not specified which
 byte 5 - version byte or format byte - not specified which
 byte 6-n - contains wrapped key descriptors (defined in 8.5.4.7)
    which contains descriptor type, reserved, and wrapped key descriptor 
length and wrapped key descriptor
 byte n+1-m - contains wrapped key length
 byte m+1-x - contains the wrapped keys
We should either specify which goes where, and what they are for; or if we 
don't know yet, but think we may need something later, then just create 2 
reserved bytes; or totally remove them.  Does anyone remember what 
structure this version/format were referring to (and why it's not part of 
that structure itself)?
Right now, they both shall be set to 00h, so it's no big deal (which also 
means we could just mark them as reserved - or it means we don't really 
need it).  If someone else knows why they are there, then the 
justification for keeping them will need to come from that someone else.
    Fred Knight
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Thursday, January 03, 2008 7:55 PM
To: t10 at t10.org
Subject: SSC-3 Action Item Reminder
This is a reminder of the Action Items still outstanding in the SSC-3 
Working Group. 
Dave Peterson: Bring in a White Paper on the value added with Explicit 
Command Set. 
Dave Peterson incorporate TapeAlert Delineation (06-138r6) into SSC-3 
Dave Peterson to incorporate Requested Recovery log page (07-046r3) 
Paul Suhler will provide his companies definition of medium as a selection 
|from Section 5.1.2 
Kevin Butt will provide his companies definition of medium as a selection 
|from Section 5.1.2 
Erich Oetting will provide his companies definition of medium as a 
selection from Section 5.1.2 
Paul Suhler to provide his companies answer to ?Should a device server 
allow host write access to MAM on a write protected volume?? 
Erich Oetting to provide his companies answer to ?Should a device server 
allow host write access to MAM on a write protected volume?? 
Fred Knight to invistigate if the version byte and the format byte from 
the LABEL field from Table 123 in SSC-3r03e can be removed. 
Dave Peterson to incorporate Protecting a partially encrypted volume 
(07-290r3) into SSC-3. 
Paul Suhler assign an owner from the ADI group for item 2.7 of 05-351r1 
which is to provide a means for the library Serial Number to be reported 
by the Tape Drive. 
Curtis Ballard to revise and post SSC-3: Out of Band Encryption Key 
Management (07-361r4) 
Dave Peterson to incorporate SSC-3: Out of Band Encryption Key Management 
(07-361r5) into SSC-3. 
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/ 


From Frederick.Knight at netapp.com  Fri Jan  4 10:30:46 2008
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Fri, 4 Jan 2008 13:30:46 -0500
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.36.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
Actually, I was corrected offline.  This wording can be taken to imply
that "either a value of zero, or a value of at least file will return
the ADDITIONAL LENGTH field in the parameter data".  That is obviously
incorrect.  So, here's another suggestion:
 "The ALLOCATION LENGTH field is defined in 4.3.4.6. If EVPD is set to
zero, the allocation length [[may be zero]]; or it should be at least
five, so that the ADDITIONAL LENGTH field in the parameter data (see
6.4.2) is returned. If EVPD is set to one, the allocation length [[may
be zero]]; or it should be [[-should be]] at least four, so that the
PAGE LENGTH field in the parameter data (see 7.6) is returned."
or
"The ALLOCATION LENGTH field is defined in 4.3.4.6.  To return the
ADDITIONAL LENGTH field in the parameter data (see 6.4.2) if EVPD is set
to zero, the allocation length should be at least five.  To return the
PAGE LENGTH field in the parameter data (see 7.6) if EVPD is set to one,
the allocation length should be should be at least four.  To return no
parameter data, the allocation length may be set to zero."
	Fred Knight
-----Original Message-----
From: plavarre at lexar.com [mailto:plavarre at lexar.com] 
Sent: Friday, January 04, 2008 12:06 PM
To: Knight, Frederick; t10 at t10.org
Cc: Gerry.Houlder at seagate.com; jgeldman at lexar.com; Mark.Evans at wdc.com;
mikeb at bustrace.com; roweber at IEEE.org
Subject: RE: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
maybe
Ah wonderful.
Yes I agree this newly suggested phrase of "either zero, or" says what
we always have meant slightly better than the earlier suggestion of the
phrase "zero, else".
I also notice this last retyping of the paragraph didn't bother to
correct the famous "should be should be" tupo.
Thus I think Frederick meant to suggest:
"""The ALLOCATION LENGTH field is defined in 4.3.4.6. If EVPD is set to
zero, the allocation length should be [+ either zero, or] at least five,
so that the ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is
returned. If EVPD is set to one, the allocation length should be [-
should be] at least four, so that the PAGE LENGTH field in the parameter
data (see 7.6) is returned."""
I think that form includes a new claim. I'm ok with new claims so long
as we agree the new claims are new and true.
The new claim here is that the allocation length should be nonzero when
EVPD is set to one.
I think that should is false. I think we're ok with a host trying to
discover the lack of EVPD support by setting EVPD to one without setting
allocation length nonzero. Consequently I guess the best correction
found so far would be two insertions and one deletion:
"""The ALLOCATION LENGTH field is defined in 4.3.4.6. If EVPD is set to
zero, the allocation length should be [+ either zero, or] at least five,
so that the ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is
returned. If EVPD is set to one, the allocation length should be [-
should be] [+ either zero, or] at least four, so that the PAGE LENGTH
field in the parameter data (see 7.6) is returned."""
Is that right? And good enough?
Curiously yours, hope this helps, thanks in advance, Pat LaVarre
*
* 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  Fri Jan  4 11:59:34 2008
From: roweber at ieee.org (Ralph Weber)
Date: Fri, 04 Jan 2008 13:59:34 -0600
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.37.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Fred,
I am totally flummoxed here. Why do you need a 'may' and a 'should'
in the same set of requirements when 'should' can always be read
as 'may be any value, but should be x'?
Please look carefully at the definition of the 'should' keyword
before carrying this too much farther.
All the best,
.Ralph
Knight, Frederick wrote:
> Actually, I was corrected offline.  This wording can be taken to imply
> that "either a value of zero, or a value of at least file will return
> the ADDITIONAL LENGTH field in the parameter data".  That is obviously
> incorrect.  So, here's another suggestion:
>
>  "The ALLOCATION LENGTH field is defined in 4.3.4.6. If EVPD is set to
> zero, the allocation length [[may be zero]]; or it should be at least
> five, so that the ADDITIONAL LENGTH field in the parameter data (see
> 6.4.2) is returned. If EVPD is set to one, the allocation length [[may
> be zero]]; or it should be [[-should be]] at least four, so that the
> PAGE LENGTH field in the parameter data (see 7.6) is returned."
>
> or
>
> "The ALLOCATION LENGTH field is defined in 4.3.4.6.  To return the
> ADDITIONAL LENGTH field in the parameter data (see 6.4.2) if EVPD is set
> to zero, the allocation length should be at least five.  To return the
> PAGE LENGTH field in the parameter data (see 7.6) if EVPD is set to one,
> the allocation length should be should be at least four.  To return no
> parameter data, the allocation length may be set to zero."
>
>	Fred Knight
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Frederick.Knight at netapp.com  Fri Jan  4 13:34:01 2008
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Fri, 4 Jan 2008 16:34:01 -0500
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.38.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
Yes, you're right.
Should =  "it is strongly recommended".
Should does not necessarily mean that there is also a "should not",
unless in fact, it is really there (and there are several "should not"
places in SPC; but this is NOT one of them).
I'm content with the text as is (other than the editorial change of the
double "should be"), and will leave any changes to those with an issue.
	Fred
-----Original Message-----
From: Ralph Weber [mailto:roweber at ieee.org] 
Sent: Friday, January 04, 2008 3:00 PM
To: t10 at t10.org
Subject: Re: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
maybe
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Fred,
I am totally flummoxed here. Why do you need a 'may' and a 'should'
in the same set of requirements when 'should' can always be read as 'may
be any value, but should be x'?
Please look carefully at the definition of the 'should' keyword before
carrying this too much farther.
All the best,
.Ralph
Knight, Frederick wrote:
> Actually, I was corrected offline.  This wording can be taken to imply
> that "either a value of zero, or a value of at least file will return 
> the ADDITIONAL LENGTH field in the parameter data".  That is obviously
> incorrect.  So, here's another suggestion:
>
>  "The ALLOCATION LENGTH field is defined in 4.3.4.6. If EVPD is set to
> zero, the allocation length [[may be zero]]; or it should be at least 
> five, so that the ADDITIONAL LENGTH field in the parameter data (see
> 6.4.2) is returned. If EVPD is set to one, the allocation length [[may
> be zero]]; or it should be [[-should be]] at least four, so that the 
> PAGE LENGTH field in the parameter data (see 7.6) is returned."
>
> or
>
> "The ALLOCATION LENGTH field is defined in 4.3.4.6.  To return the 
> ADDITIONAL LENGTH field in the parameter data (see 6.4.2) if EVPD is 
> set to zero, the allocation length should be at least five.  To return
> the PAGE LENGTH field in the parameter data (see 7.6) if EVPD is set 
> to one, the allocation length should be should be at least four.  To 
> return no parameter data, the allocation length may be set to zero."
>
>	Fred Knight
*
* 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 roweber at IEEE.org  Fri Jan  4 15:34:17 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Fri, 04 Jan 2008 17:34:17 -0600
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.39.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
The double "should be" is fixed in the draft r12, which I might get a
chance to finish someday.
All the best,
.Ralph
Knight, Frederick wrote:
> Yes, you're right.
>
> Should =  "it is strongly recommended".
>
> Should does not necessarily mean that there is also a "should not",
> unless in fact, it is really there (and there are several "should not"
> places in SPC; but this is NOT one of them).
>
> I'm content with the text as is (other than the editorial change of the
> double "should be"), and will leave any changes to those with an issue.
>
>	Fred
*
* 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  Fri Jan  4 16:13:45 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Fri, 4 Jan 2008 17:13:45 -0700
Subject: Updated slides for group reservation call Monday
Message-ID: <mailman.40.1441607335.22514.t10@sandbox.t10.org>

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

I have updated my slides by adding some backup slides starting at slide 
13.  If there is any confusion about what we (IBM) are attempting to 
cover, these slides will hopefully help.
   http://www.t10.org/ftp/t10/document.08/08-024r1.pdf
Also, Roger Cummings has posted slides as 08-048 for Monday's call.
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


From Black_David at emc.com  Fri Jan  4 16:34:53 2008
From: Black_David at emc.com (Black_David at emc.com)
Date: Fri, 4 Jan 2008 19:34:53 -0500
Subject: DS_SAI length conflict between 07-437r4 and 07-169 & SPC-4
Message-ID: <mailman.41.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Black_David at emc.com
*
Ralph,
SAI space may be sparse.  For a 64-bit firmware implementation,
putting all 64 bits of the pointer to the internal data
structure in the SAI may be convenient (NB: with careful
verification to prevent use of invalid pointers by an attacker).
The flip side argument is that for reuse of ESP hardware, the
SAI probably needs to be 32 bits, and IKEv2-SCSI requires
enough changes to existing IKEv2 code that preserving IKEv2's
64 bit SAI (SPI) size may not be of much help to an implementer.
Thanks,
--David
> -----Original Message-----
> From: roweber at sempai.org [mailto:roweber at sempai.org] On 
> Behalf Of Ralph Weber
> Sent: Thursday, January 03, 2008 9:35 PM
> To: Black, David
> Cc: kdbutt at us.ibm.com; matt.ball at ieee.org; t10 at t10.org
> Subject: Re: DS_SAI length conflict between 07-437r4 and 
> 07-169 & SPC-4
> 
> David,
> 
> I am having the dickens of a time comprehending why a device server
> needs as many SAIs as an OSD has partitions. What am I missing?
> 
> All the best,
> 
> .Ralph
> 
> Black_David at emc.com wrote:
> > Kevin,
> > We need to make a decision on this one because there is no obvious
> > right answer. IETF uses separate SPIs (what T10 calls SAIs) for
> > IKEv2 and ESP - 8 bytes SPIs are used for IKEv2, but ESP uses 4 byte
> > SPIs. SCSI is using the same SPI for both purposes, and hence needs
> > to pick one length - I agree with your suggestion that 8 bytes (as
> > used in IKEv2-SCSI) is preferable. >From an implementation
standpoint
> > this would reduce the impact on reuse of the more complex IKEv2
> > implementations (more complex is by comparison to ESP).
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > EMC Corporation, 176 South St., Hopkinton, MA 01748
> > +1 (508) 293-7953 FAX: +1 (508) 293-7786
> > black_david at emc.com Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> >
> >	
> --------------------------------------------------------------
> ----------
> >	*From:* Kevin D Butt [mailto:kdbutt at us.ibm.com]
> >	*Sent:* Friday, December 21, 2007 11:24 AM
> >	*To:* roweber at ieee.org; Black, David; matt.ball at ieee.org
> >	*Cc:* t10 at t10.org
> >	*Subject:* DS_SAI length conflict between 07-437r4 and 
> 07-169 & SPC-4
> >
> >
> >	Ralph, David, and Matt,
> >
> >	All the DS_SAI values in the ESP-SCSI (07-169r5) (e.g., 
> Table x3 -
> >	ESP-SCSI data-out buffer parameter list descriptor without
> >	initialization vector) are shown as 4-byte values as they are in
> >	SPC-4 Table 44 - Minimum SA parameters. However 07-437r4 shows
> >	them as 8-byte values. I think 07-437r4 is correct and SPC-4 and
> >	07-169 need to be modified to match.
> >
> >	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/ 
> >
> 
> 
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From plavarre at lexar.com  Fri Jan  4 17:28:00 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Fri, 4 Jan 2008 17:28:00 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.42.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
> > I think unsigned may or shall or should be "at least"
> > means should not be less, which is wrong in this instance.
Ouch I typed that instead when I actually meant to type:
I think unsigned may or shall or should be "at least" means may or shall
or should not be less, respectively, and the should not is wrong in this
instance.
Slippery stuff.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From plavarre at lexar.com  Fri Jan  4 17:25:48 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Fri, 4 Jan 2008 17:25:48 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.43.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
> Should does not necessarily mean that there
> is also a "should not", unless in fact, it is really there
Yep.
> I'm content with the text as is
Eh?
The Spc4r11.pdf text as is includes such fragments as: """If EVPD is set
to zero, the allocation length should be at least five, so that the
ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is
returned."""
I think that fragment includes a false should not.
I think the phrase "should be at least five" means "should not be zero,
nor one, nor two, nor three, nor four" which I think is a claim false by
overstatement, because I think zero is fine as the allocation length,
even when EVPD is set to zero.
Where have I gone wrong in my reading with this logic?
Doesn't unsigned byte pair "should be at least five" always mean "should
not be zero, nor one, nor two, nor three, nor four"?
I think we should stop misleading by claiming should not be zero.
> > > the definition of the 'should' keyword
I think the applicable Spcr411.pdf definitions for 'may', 'should',
'shall' are:
"""3.3.5 may: A keyword that indicates flexibility of choice with no
implied preference (equivalent to "may or may
not")."""
"""3.3.6 may not: A keyword that indicates flexibility of choice with no
implied preference (equivalent to "may or may
not")."""
"""3.3.12 should: A keyword indicating flexibility of choice with a
strongly preferred alternative; equivalent to the phrase "it is strongly
recommended"."""
"""3.3.11 shall: A keyword indicating a mandatory requirement. Designers
are required to implement all such
mandatory requirements to ensure interoperability with other products
that conform to this standard."""
I don't yet understand which details of these definitions should be
directing my logic elsewhere.
I think unsigned may or shall or should be "at least" means should not
be less, which is wrong in this instance.
I'm most curious to understand where I've gone wrong. I don't see how
I've gone wrong. This looks like plain obvious logic to me -- a clear
matter of technical speaking. Somehow no?
Curiously yours, happy Friday,
*
* 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  Fri Jan  4 18:12:06 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Fri, 04 Jan 2008 20:12:06 -0600
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.44.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Pat,
The only reason I am responding to this is to ensure that other
readers of this reflector do not get the impression that you have
a semblance of a clue.
The only thing you stated that is correct is:
 "[should be at least] ... means should not be less".
***BUT***
"should not be less" means "this standard recommends that the
value not be less". "should not be less" DOES NOT MEAN "this
standard prohibits the value from being less".
Please take your whimsical rewrites of SPC-4 r11 subclause 3.3
to some less rigorous reflector.
Regards,
.Ralph
P.S. You should have heeded the private warnings about the
pearls of pursuing this path.
plavarre at lexar.com wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * <plavarre at lexar.com>
> *
>   
>>> I think unsigned may or shall or should be "at least"
>>> means should not be less, which is wrong in this instance.
>>>	  
>
> Ouch I typed that instead when I actually meant to type:
>
> I think unsigned may or shall or should be "at least" means may or shall
> or should not be less, respectively, and the should not is wrong in this
> instance.
>
> Slippery stuff.
>
> *
> * 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 roweber at IEEE.org  Fri Jan  4 19:08:32 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Fri, 04 Jan 2008 21:08:32 -0600
Subject: [Fwd: Re: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
 maybe]
Message-ID: <mailman.45.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
One final point gentle reflector readers ...
Pat's general record for bug finding is vastly better than
the current incident would suggest. Somebody must have spiked
he Wheaties with Should Sauce. Nothing else can explain what
such a far out misreading of a tried-and-true SCSI keyword.
All the best,
.Ralph
-------- Original Message --------
Subject:	Re: SPC Inquiry for Quad-Aligned Zero -- deprecated since 
SPC-4 maybe
Date:	Fri, 04 Jan 2008 20:12:06 -0600
From:	Ralph Weber <roweber at ieee.org>
To:	t10 at t10.org
References:	<477E9026.1070302 at ieee.org> 
<F412CA727D22E141A18A28D1358225E301865F54 at RTPEXMV01.hq.netapp.com> 
<369B58E68719B54483BCD7514948EE90017D253B at ntxfrembx01.micron.com>
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Pat,
The only reason I am responding to this is to ensure that other
readers of this reflector do not get the impression that you have
a semblance of a clue.
The only thing you stated that is correct is:
"[should be at least] ... means should not be less".
***BUT***
"should not be less" means "this standard recommends that the
value not be less". "should not be less" DOES NOT MEAN "this
standard prohibits the value from being less".
Please take your whimsical rewrites of SPC-4 r11 subclause 3.3
to some less rigorous reflector.
Regards,
.Ralph
P.S. You should have heeded the private warnings about the
pearls of pursuing this path.
plavarre at lexar.com wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * <plavarre at lexar.com>
> *
>   
>>> I think unsigned may or shall or should be "at least"
>>> means should not be less, which is wrong in this instance.
>>>	  
>
> Ouch I typed that instead when I actually meant to type:
>
> I think unsigned may or shall or should be "at least" means may or shall
> or should not be less, respectively, and the should not is wrong in this
> instance.
>
> Slippery stuff.
*
* 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  Sat Jan  5 16:52:40 2008
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Sun, 6 Jan 2008 00:52:40 +0000
Subject: SES-2 revision 19a now available
Message-ID: <mailman.46.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
SCSI Enclosure Services - 2 (SAS-2) revision 19a (sas2r19a) is now available
on http://www.t10.org/drafts.htm and http://www.t10.org/new.htm,
reflecting the first pass of letter ballot comment resolution.
ses2r19a.pdf is the new working draft incorporating the changes.
	     Change bars reflect changes since ses2r19.
07-512r0.pdf contains the original letter ballot comments.
08-049r0.pdf contains ses2r19 side-by-side with the comments
	     (including resolution status).
	     On some of the pages, Acrobat messed up the pagination such
	     that the comments are on the left and the arrows don't
	     line up, but it's decipherable.
08-049r0.fdf contains just the comments (including resolution status)
	     and can be imported into ses2r19.pdf using full Acrobat.
Thanks to George Penokie (IBM at the time) and Roger Cummings (Symantec)
for submitting comments.
Issues needing CAP working group feedback:
1. May we convert decimal separators from the ISO convention (commas) to the
   American convention (periods)?
2. Should CHECK CONDITION/HARDWARE ERROR/ENCLOSURE FAILURE be allowed on
   INQUIRY, REPORT LUNS, and NOTIFY DATA TRANSFER DEVICE commands?
   (see editor's note on page 18)
3. Should the REPORT bit be allowed to be set to one in overall status
   elements, or is it only applicable to individual status elements?
   (see editor's note on page 74)
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
*
* 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 Jan  5 23:00:40 2008
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 6 Jan 2008 00:00:40 -0700
Subject: Recent T10 documents uploaded since 2007/12/30
Message-ID: <mailman.47.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SMC-3 New Additional Sense Codes Usage
(by: Rod Wideman)
T10/07-018r1   Uploaded: 2008/01/02   112825 bytes
ftp://ftp.t10.org/t10/document.07/07-018r1.pdf
SAS-2: Indeterminate response length to a SMP REPORT GENERAL function
(by: George O. Penokie)
T10/07-397r2   Uploaded: 2008/01/03   189964 bytes
ftp://ftp.t10.org/t10/document.07/07-397r2.pdf
SAS-2 Add SMP Report General Open Response While Configuring
(by: Brad Besmer)
T10/07-403r1   Uploaded: 2008/01/03   97161 bytes
ftp://ftp.t10.org/t10/document.07/07-403r1.pdf
Capability based Command Security
(by: George O. Penokie)
T10/07-454r4   Uploaded: 2007/12/31   388658 bytes
ftp://ftp.t10.org/t10/document.07/07-454r4.pdf
SAS-2: Remove restrictions for SSC
(by: Gerald Houlder, Alvin Cox)
T10/08-014r3   Uploaded: 2008/01/03   39001 bytes
ftp://ftp.t10.org/t10/document.08/08-014r3.pdf
SPC-4: Group Persistent Reservations - Presentation
(by: Kevin Butt)
T10/08-024r1   Uploaded: 2008/01/04   150156 bytes
ftp://ftp.t10.org/t10/document.08/08-024r1.pdf
SMC-3 Use of LOGICAL UNIT NOT READY, INITIALIZING COMMAND REQUIRED
error code
(by: Noud Snelder)
T10/08-038r0   Uploaded: 2007/12/31   22918 bytes
ftp://ftp.t10.org/t10/document.08/08-038r0.pdf
SMC-3 New ASC/ASCQs List
(by: Rod Wideman)
T10/08-039r0   Uploaded: 2007/12/31   75530 bytes
ftp://ftp.t10.org/t10/document.08/08-039r0.pdf
SAS-2 SMP DISCOVER Self-Configuration Levels Completed
(by: Brad Besmer)
T10/08-040r0   Uploaded: 2008/01/01   131457 bytes
ftp://ftp.t10.org/t10/document.08/08-040r0.pdf
SAS-2 Use American numbering convention
(by: Rob Elliott)
T10/08-041r0   Uploaded: 2008/01/02   16206 bytes
ftp://ftp.t10.org/t10/document.08/08-041r0.pdf
Minutes of SAS PHY Working Group conference call January 3, 2008
(by: Alvin Cox)
T10/08-043r0   Uploaded: 2008/01/03   24522 bytes
ftp://ftp.t10.org/t10/document.08/08-043r0.pdf
SBC-3 DIF Granularity
(by: Robert Sheffield)
T10/08-044r0   Uploaded: 2008/01/03   215856 bytes
ftp://ftp.t10.org/t10/document.08/08-044r0.pdf
Perssistent Reservation Problem & Enhancement Requirements
(by: Roger Cummings)
T10/08-048r0   Uploaded: 2008/01/04   40100 bytes
ftp://ftp.t10.org/t10/document.08/08-048r0.pdf
SES-2 revision 19 letter ballot comment resolution as of ses2r19a
(by: Rob Elliott)
T10/08-049r0   Uploaded: 2008/01/05   1527768 bytes
ftp://ftp.t10.org/t10/document.08/08-049r0.fdf
SES-2 revision 19 letter ballot comment resolution as of ses2r19a
(by: Rob Elliott)
T10/08-049r0   Uploaded: 2008/01/05   2823772 bytes
ftp://ftp.t10.org/t10/document.08/08-049r0.pdf
Working Drafts
--------------
SCSI Architecture Model - 4 (SAM-4)
(Editor: George Penokie)
 Rev: 13c      Uploaded: 2007/12/30   1829891 bytes
ftp://ftp.t10.org/t10/drafts/sam4/sam4r13c.pdf
SCSI Enclosure Services - 2 (SES-2)
(Editor: Rob Elliott)
 Rev: 19a      Uploaded: 2008/01/05   802966 bytes
ftp://ftp.t10.org/t10/drafts/ses2/ses2r19a.pdf
SCSI Media Changer Command Set - 3 (SMC-3)
(Editor: Noud Snelder)
 Rev: 10       Uploaded: 2008/01/04   2143300 bytes
ftp://ftp.t10.org/t10/drafts/smc3/smc3r10.pdf
(Report generated on 2008/01/06 at 00:00:40)
*
* 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  Sun Jan  6 18:30:31 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Mon, 7 Jan 2008 11:30:31 +0900
Subject: Reminder: 1/9 SWG meeting announcement at Kawasaki
Message-ID: <mailman.48.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Happy New Year!
Please send your participation information if you need free lunch.
Now I received from following people.
Due to SPAM filter, I may miss your email.
If you are not listed below please send your information again.
Norichika Mine
Akio Yamazaki
Takaharu Ai
Eijiro Tazawa
Hideki Takahashi
Shunsuke Kimura
Best regards,
Keiji Katata
PIONEER CORP.
keiji_katata at post.pioneer.co.jp@avc-pioneer.com on 2007/12/20 17:10:06
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 Reflector <t10 at t10.org>
bcc:
$B7oL>(B:  1/9 SWG meeting announcement at Kawasaki
Hello all,
Pioneer prepares a meeting room for the SWG at 1/9.
Agenda: Real-time streaming playback model
Date: 2008/1/9
Time: 10:00AM - 5:00PM
Place: 1-1, SHIN-OGURA, SAIWAI-KU, KAWASAKI-SHI KANAGAWA 212-0031, JAPAN
TEL: 81-44-580-3211
Map:
http://pioneer.jp/corp/profile/map/kawasaki/index-e.html
Registration by 2008/1/7 is required.
13 people of the beginning will have free lunch in the building.
Best regards,
Keiji Katata
PIONEER CORP.
TEL +81-49-279-2387
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Gerry.Houlder at seagate.com  Mon Jan  7 06:57:20 2008
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Mon, 7 Jan 2008 08:57:20 -0600
Subject: Interpretation of SPEC_I_PT (Persistent Reservations)
Message-ID: <mailman.49.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
In SPC-4 rev. 11, I am reading the rules for use of the SPEC_I_PT bit. The
rules clearly specify its intended use with REGISTER service action and
specify it is illegal for use with REGISTER AND IGNORE EXISTING KEY service
action. It is silent on what to do with this bit for the other service
actions, but the description of the action seems to imply that it is only
legal with REGISTER service action and illegal for all others. Is this
interpretation correct?
*
* 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  Mon Jan  7 09:34:25 2008
From: mikeb at bustrace.com (Mike Berhan)
Date: Mon, 7 Jan 2008 09:34:25 -0800
Subject: SMC-3r10 - Request Data Transfer Element Inquiry
Message-ID: <mailman.50.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
There seems to be an opcode conflict in SMC-3 going back several years.
This is probably something that has been covered before or perhaps it's just
a simple typo.
Table 5 of SMC-3 shows the "Commands for media changer devices."  For the
MAINTENANCE IN commands, it shows the following operation codes:
A3h/00h-04h
A3h/06h-09h
These operation codes are defined in SCC-2.  Turning to SCC-2, we find that
A3h/06h is defined as the "REPORT STATES" service action.
Turning back to SMC-3, we see in Table 30 that A3h/06h is defined as
"REQUEST DATA TRANSFER ELEMENT INQUIRY."
This appears to be a conflict with A3h/06h unless I missed something.  Can
someone clarify this for me?  Thank you.
-------
Mike Berhan
busTRACE Technologies
9700 Village Center Drive
Suite 50-F
Granite Bay, CA  95746
916.773.4554 phone
916.218.6283 fax
http://www.bustrace.com
*
* 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  Mon Jan  7 11:16:55 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 7 Jan 2008 12:16:55 -0700
Subject: SMC-3r10 - Request Data Transfer Element Inquiry
Message-ID: <mailman.51.1441607335.22514.t10@sandbox.t10.org>

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

Mike,
SPC-4r11 Annex C.3.3 lists the Maintenance IN op codes.  Values 
A3h/00h-04h and A3/06h-09h are listed as "Restricted".	This means that 
each command set is free to assign these values as it sees fit.  Stated 
differently, when PERIPHERAL DEVICE TYPE in standard inquiry reports SCC 
device, then A3h/06h is interpreted as "REPORT STATES".  When  PERIPHERAL 
DEVICE TYPE in standard inquiry reports SMC device, then A3h/06h is 
interpreted as "REQUEST DATA TRANSFER ELEMENT INQUIRY".
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/ 
"Mike Berhan" <mikeb at bustrace.com> 
Sent by: owner-t10 at t10.org
01/07/2008 10:34 AM
To
<t10 at t10.org>
cc
Subject
SMC-3r10 - Request Data Transfer Element Inquiry
* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
There seems to be an opcode conflict in SMC-3 going back several years.
This is probably something that has been covered before or perhaps it's 
just
a simple typo.
Table 5 of SMC-3 shows the "Commands for media changer devices."  For the
MAINTENANCE IN commands, it shows the following operation codes:
A3h/00h-04h
A3h/06h-09h
These operation codes are defined in SCC-2.  Turning to SCC-2, we find 
that
A3h/06h is defined as the "REPORT STATES" service action.
Turning back to SMC-3, we see in Table 30 that A3h/06h is defined as
"REQUEST DATA TRANSFER ELEMENT INQUIRY."
This appears to be a conflict with A3h/06h unless I missed something.  Can
someone clarify this for me?  Thank you.
-------
Mike Berhan
busTRACE Technologies
9700 Village Center Drive
Suite 50-F
Granite Bay, CA  95746
916.773.4554 phone
916.218.6283 fax
http://www.bustrace.com
*
* 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  Mon Jan  7 11:17:08 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 7 Jan 2008 12:17:08 -0700
Subject: Minutes posted for Group Reservations call
Message-ID: <mailman.52.1441607335.22514.t10@sandbox.t10.org>

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

2008/01/07 11:36:14 
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.08/08-051r0.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 tjmac at tolisgroup.com  Mon Jan  7 11:36:36 2008
From: tjmac at tolisgroup.com (Tim Jones)
Date: Mon, 7 Jan 2008 12:36:36 -0700
Subject: SMC-3r10 - Request Data Transfer Element Inquiry
Message-ID: <mailman.53.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Tim Jones <tjmac at tolisgroup.com>
*
On Jan 7, 2008, at 10:34 AM, Mike Berhan wrote:
> These operation codes are defined in SCC-2.  Turning to SCC-2, we  
> find that
> A3h/06h is defined as the "REPORT STATES" service action.
>
> Turning back to SMC-3, we see in Table 30 that A3h/06h is defined as
> "REQUEST DATA TRANSFER ELEMENT INQUIRY."
I believe that they are both correct in that "REQUEST DATA TRANSFER  
ELEMENT INQUIRY" is a library's equivalent of "REPORT STATES" since  
you are asking the device to "report the state" of the requested DTEs.
> This appears to be a conflict with A3h/06h unless I missed  
> something.  Can
> someone clarify this for me?	Thank you.
I think it's just a wording difference between the generic and the  
specific.  Others?
Tim
*
* 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  Mon Jan  7 17:42:59 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 7 Jan 2008 18:42:59 -0700
Subject: Team Reservations Proposals updated
Message-ID: <mailman.54.1441607335.22514.t10@sandbox.t10.org>

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

I have uploaded 08-024r2 and 08-025r1 that contain updates per our Group 
Reservations phone call this morning.  Please allow a few minutes for them 
to show up.
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


From daviburg at windows.microsoft.com  Mon Jan  7 19:17:52 2008
From: daviburg at windows.microsoft.com (David Burg)
Date: Mon, 7 Jan 2008 19:17:52 -0800
Subject: Posted: Pioneer counter proposal
Message-ID: <mailman.55.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* David Burg <daviburg at windows.microsoft.com>
*
Dear Katata-san,
This proposal is highly different from Microsoft-Toshiba proposal and you
mention "Pioneer and its partner companies do not receive any request of the
above items from PC manufactures."
I believe however that David Walp already shared with the committee at the
previous meeting the following from Dell in a response to a similar comment
you made at the Las Vegas meeting. It case it slipped through, let me repeat
it here:
" From: Lee, Kah Soon
Sent: Saturday, December 15, 2007 3:04 AM
To: David Walp
Cc: David Burg; Lo, James; Sellers, Sabrina
Importance: High
Hi, David.
James and I have reviewed the new Mt. Fuji proposal on speed detection and
control commands update.
We have no concern on the proposal and this is aligned with our goal in
acoustic noise issue. We agreed with the proposed solution.
[...]
Regards, Kah Soon"
This person from Dell later added:
"Thanks for sharing with us on the status of this proposal.
Please let us know whether you need any help from us to work together with
our optical drives suppliers, especially the prototype drives/firmware.
Just keep us posted on the progress."
I observe that there is here a disconnect between Pioneer's statement and
what Dell communicated to Microsoft (and allowed to share as their
statement).
I further cannot concur with Pioneer's claims with regard to "A minimum
average data rate for HD content on DVD is guaranteed already. So new scheme
is not necessary." As a matter of fact Microsoft and partners have prototyped
HD DVD Video content on Red laser DVD and due to insufficient average data
rate the playback is badly jittered. Work is required!
Multiple other host software companies already joined Microsoft in the
request for reporting logical unit performance capabilities to the end user
and few even sent representatives to the committee meeting. I am amazed that
Pioneer still denies the existence of this request!
Pioneer claims that reporting precise execution time for an I/O operation
does not have any relationship with Real Time Streaming issue. However it is
exactly the misunderstandings around the existing Real Time Streaming feature
and fabrication of inaccurate respond data to performance command associated
with this feature that cause execution time for an I/O operation to be
reported imprecisely (the device performing actually at different speed than
it was instructed and different than it is reporting)!
I just returned yesterday to US and I am not able to attend the 1/9 SWG
meeting in Japan. I ask however that you consider the feedback we have
provided.
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, December 26, 2007 10:06 PM
To: mtfuji5 at avc-pioneer.com
Cc: T10 Reflector
Subject: Posted: Pioneer counter proposal
Hello all,
I posted a counter proposal for 1/9 SWG.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Jan08/SWG/Pioneer Stream Model.doc
Best regards,
Keiji Katata
PIONEER CORP.
TEL +81-49-279-2387
*
* 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  Mon Jan  7 21:42:45 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 8 Jan 2008 14:42:45 +0900
Subject: Posted: Pioneer counter proposal
Message-ID: <mailman.56.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello Daivd,
I'm sorry that I do not have a connection with manager of high rank. I work
for
end users/ordinary PC users side. So I may have communication with
people/engineer such as sales side, Quality Control side, Customer support
side
and retail shop side.
"due to insufficient average data rate"
Specification allows much possibility than the possibility that may be
possible
in the market. DVD 2X transfer rate is OK for HD content on DVD. Most of DVD
slim drive have this speed now.
In addition, to support DVD+R/+RW, 3.3X is supported on DVD writer drive.
Currently HD ready system (ex. Vista premium model) has new good performance
ODD
drive. What I want to say is that already PC manufactures have released HD
ready
system to the market. Of course old drive or low performance drive may be
bad.
"Real Time Streaming feature"
This feature does not have capability for "execution time for an I/O
operation".
A series of commands will be executed appropriately for Streaming. This is
basic
function of ODD drive.
I understood a problem that HD not-ready drive does not have good performance
for HD content playback. Pioneer simple proposal has the solution for this
problem.
I do not understand the root cause of your "execution time for an I/O
operation"
problem. You may inform us about what is problem (and root cause) of
"execution
time for an I/O operation".
Best regards,
Keiji Katata
PIONEER CORP.
David Burg <daviburg at windows.microsoft.com>@avc-pioneer.com on 2008/01/08
12:17: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" <mtfuji5 at avc-pioneer.com>
cc:    T10 Reflector <t10 at t10.org>
bcc:
$B7oL>(B:  RE: Posted: Pioneer counter proposal
Dear Katata-san,
This proposal is highly different from Microsoft-Toshiba proposal and you
mention "Pioneer and its partner companies do not receive any request of the
above items from PC manufactures."
I believe however that David Walp already shared with the committee at the
previous meeting the following from Dell in a response to a similar comment
you
made at the Las Vegas meeting. It case it slipped through, let me repeat it
here:
" From: Lee, Kah Soon
Sent: Saturday, December 15, 2007 3:04 AM
To: David Walp
Cc: David Burg; Lo, James; Sellers, Sabrina
Importance: High
Hi, David.
James and I have reviewed the new Mt. Fuji proposal on speed detection and
control commands update.
We have no concern on the proposal and this is aligned with our goal in
acoustic
noise issue. We agreed with the proposed solution.
[...]
Regards, Kah Soon"
This person from Dell later added:
"Thanks for sharing with us on the status of this proposal.
Please let us know whether you need any help from us to work together with
our
optical drives suppliers, especially the prototype drives/firmware.
Just keep us posted on the progress."
I observe that there is here a disconnect between Pioneer's statement and
what
Dell communicated to Microsoft (and allowed to share as their statement).
I further cannot concur with Pioneer's claims with regard to "A minimum
average
data rate for HD content on DVD is guaranteed already. So new scheme is not
necessary." As a matter of fact Microsoft and partners have prototyped HD DVD
Video content on Red laser DVD and due to insufficient average data rate the
playback is badly jittered. Work is required!
Multiple other host software companies already joined Microsoft in the
request
for reporting logical unit performance capabilities to the end user and few
even
sent representatives to the committee meeting. I am amazed that Pioneer still
denies the existence of this request!
Pioneer claims that reporting precise execution time for an I/O operation
does
not have any relationship with Real Time Streaming issue. However it is
exactly
the misunderstandings around the existing Real Time Streaming feature and
fabrication of inaccurate respond data to performance command associated with
this feature that cause execution time for an I/O operation to be reported
imprecisely (the device performing actually at different speed than it was
instructed and different than it is reporting)!
I just returned yesterday to US and I am not able to attend the 1/9 SWG
meeting
in Japan. I ask however that you consider the feedback we have provided.
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, December 26, 2007 10:06 PM
To: mtfuji5 at avc-pioneer.com
Cc: T10 Reflector
Subject: Posted: Pioneer counter proposal
Hello all,
I posted a counter proposal for 1/9 SWG.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Jan08/SWG/Pioneer Stream Model.doc
Best regards,
Keiji Katata
PIONEER CORP.
TEL +81-49-279-2387
*
* 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  Mon Jan  7 22:53:25 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 8 Jan 2008 15:53:25 +0900
Subject: Mt.Fuji meeting minutes
Message-ID: <mailman.57.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hi,
9.1 Adjustment of Interface Power Management parameter of DraftMinDec18.pdf
"Is SATA specification confidential (NDA base)? It is requested to be
checked."
I think it is under the NDA. But you may be able to buy the spec. And about
Power Management information, you may find on several WEB site. (When you
search
WEB by "SATA slumber 10")
http://www.t13.org/Documents/UploadedDocuments/docs2004/e04149r0 - DIPM
Proposal.pdf
http://sata-io.org/documents/Interop_UnifiedTest_Rev1_2_v10_091707_000.pdf
http://eng.auburn.edu/~xugefu1/D&TSeminar/files/Serial ATA
Technology_Final_9_27_06.ppt
You may find that Pioneer proposal is not new.
Best regards,
Keiji Katata
PIONEER CORP.
Takaharu Ai <ai.takaharu at jp.panasonic.com>@avc-pioneer.com on 2007/12/19
12:57:23
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B:  "Mt.Fuji" <mtfuji5 at avc-pioneer.com>
cc:    T10 <T10 at t10.org>
bcc:
$B7oL>(B:  Mt.Fuji meeting minutes
Hello Mt.Fuji people,
Enclosed please find the revised draft November meeting minutes and the
draft December meeting minutes of Mt.Fuji plenary.
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 Alvin.Cox at seagate.com  Tue Jan  8 07:40:57 2008
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Tue, 8 Jan 2008 09:40:57 -0600
Subject: Reminder, SAS PHY WG call, Jan 10, 10:00am CST
Message-ID: <mailman.58.1441607335.22514.t10@sandbox.t10.org>

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

Conference calls on Thursday at 10:00 am Central time.
Next conference call: 1/10/08
Toll Free Dial in Number: (877)810-9442 
International Access/Caller Paid Dial In Number: (636)651-3190 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate 
Topic: SAS-2 PHY WG 
Date: Thursday 
Time: 10:00 am, Central Standard Time
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS 
Agenda (Items 1, 2, and 3 are very critical items to cover): 
1. Proposed Cable Tables for SAS2 6Gbs Phy [McSorley] 
http://www.t10.org/ftp/t10/document.07/07-471r0.pdf 
Change to frequency domain rather than time domain and specify separately. 
Waiting for revision to be posted. Greg will work with Michael Fogg and 
Galen Fromm on the new revision.
2. SAS-2 Interconnect Signal-to-Noise Ratio Study [Olawsky] 
http://www.t10.org/ftp/t10/document.07/07-484r0.pdf 
3. SAS-2 Receiver Device Physical Testing [Witt, Bari] 
http://www.t10.org/ftp/t10/document.07/07-486r1.pdf 
4. Description of SSC profile allowed discontinuities. [Hernandez, Fortin] 
http://www.t10.org/ftp/t10/document.08/08-032r0.pdf
Status of editorial update.
5. Provide status of simulation technology. [Jenkins, Newman]
6. SAS-2 6Gbps PHY specification [Cox] 
http://www.t10.org/ftp/t10/document.07/07-339r8.pdf 
Please provide additional comments.
Alvin Cox
Seagate Technology, LLC
Cell 405-206-4809


From plavarre at lexar.com  Tue Jan  8 09:09:48 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Tue, 8 Jan 2008 09:09:48 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.59.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
> correct is: "[should be at least] ... means should not be less".
Agreed!
> Please take your whimsical rewrites of SPC-4 r11 subclause 3.3 to some
less rigorous reflector.
Ok will do.
The Spcr411.pdf paragraph at issue was """The ALLOCATION LENGTH field is
defined in 4.3.4.6. If EVPD is set to zero, the allocation length should
be at least five, so that the ADDITIONAL LENGTH field in the parameter
data (see 6.4.2) is returned. If EVPD is set to one, the allocation
length should be should be at least four, so that the PAGE LENGTH field
in the parameter data (see 7.6) is returned."""
If ever offline I do learn more of what this means, I'll run it by
somebody official like you for permission to give back here.
E-mail suffers from the evil of interrupting everyone to reach the
interested minority. Remember the long inconclusive talk of what it
means when hosts and devices disagree over how many data bytes to copy
each way?
Wiki doesn't suffer from that evil. Someday we'll have a wiki too, I
think,
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From rkopf at nero.com  Tue Jan  8 09:20:46 2008
From: rkopf at nero.com (Reiner Kopf)
Date: Tue, 08 Jan 2008 18:20:46 +0100
Subject: Posted: Pioneer counter proposal
Message-ID: <mailman.60.1441607335.22514.t10@sandbox.t10.org>

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

Dear Katata-san,
just a comment from Nero's side to the statement in Pioneer's proposal:
----------------------------------------------------------------------
2.3. Reporting logical unit performance capabilities to the end user;
   Providing the user the choice of a given performance profile within
   the list of available performance profiles
   No end user requests such capability and the chance of the choice.
   This will cause end user confusion and careless mistake.
----------------------------------------------------------------------
 From host side I can confirm that end users have a demand on selecting
a read/write speed out of a given set of speeds the drive supports.
Of course the host software will offer only speeds to the end user which
makes sense depending on the intended media type to be read/written.
E.g if no media is loaded, with the current specification the host
software cannot offer the correct read/write speeds to the end user and
thus not guarantee that reading/writing will be performed at the selected
speed.
So in order to increase the "user friendliness" there is indeed a need
to report the logical unit performance capabilities for the drive.
Best regards,
Reiner Kopf
Nero AG
At 15:06 27.12.2007 +0900, keiji_katata at post.pioneer.co.jp wrote:
>Hello all,
>
>I posted a counter proposal for 1/9 SWG.
>
>ftp.avc-pioneer.com/Mtfuji_7/Proposal/Jan08/SWG/Pioneer Stream Model.doc
>
>Best regards,
>
>Keiji Katata
>PIONEER CORP.
>TEL +81-49-279-2387
--
*********************************************************
Reiner Kopf
E-Mail rkopf at nero.com
<http://www.nero.com">http://www.nero.com>http://www.nero.com
NERO - BECAUSE TECHNOLOGY COUNTS
*********************************************************
Nero AG
Im Stoeckmaedle 13-15
76307 Karlsbad
Germany
Vorstand/CEO: Richard Lesser
Aufsichtsratvorsitzender/Chairman of the supervisory board: Jim Corbett
Amtsgericht Mannheim HRB 362519
*********************************************************
This e-mail may contain confidential and/or privileged
information. If you are not the intended recipient (or
have received this e-mail in error) please notify the
sender immediately and destroy this e-mail.
Any unauthorised copying, disclosure or distribution of
the material in this e-mail is strictly forbidden.
*********************************************************


From plavarre at lexar.com  Tue Jan  8 09:55:18 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Tue, 8 Jan 2008 09:55:18 -0800
Subject: T10.wikidot.com
Message-ID: <mailman.61.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
Everybody here ok if I go launch T10.wikidot.com?
Wikidot.com hosts for free, but I could choose some less meaningful name
instead if anyone here feels I'm poaching on official T10 territory ...
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From James.C.Hatfield at seagate.com  Tue Jan  8 11:13:54 2008
From: James.C.Hatfield at seagate.com (James.C.Hatfield at seagate.com)
Date: Tue, 8 Jan 2008 12:13:54 -0700
Subject: T10.wikidot.com
Message-ID: <mailman.62.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* James.C.Hatfield at seagate.com
*
What would be the purpose/charter of T10.wikidot.com ?
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....:  720-684-2711
==========================================
	     <plavarre at lexar.c						   
	     om>							   
	     Sent by:							To 
	     owner-t10 at t10.org	       <t10 at t10.org>			   
	     No Phone Info						cc 
	     Available							   
								   Subject 
				       T10.wikidot.com			   
	     01/08/2008 10:55						   
	     AM 							   
* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
Everybody here ok if I go launch T10.wikidot.com?
Wikidot.com hosts for free, but I could choose some less meaningful name
instead if anyone here feels I'm poaching on official T10 territory ...
*
* 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 Paul.Suhler at Quantum.Com  Tue Jan  8 11:23:38 2008
From: Paul.Suhler at Quantum.Com (Paul Suhler)
Date: Tue, 8 Jan 2008 11:23:38 -0800
Subject: Quantum SSC-3 Action Item Response
Message-ID: <mailman.63.1441607335.22514.t10@sandbox.t10.org>

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

Paul Suhler to provide his company's answer to "Should a device server
allow host write access to MAM on a write protected volume?" 
Quantum's answer is that, yes, this should be allowed.	This is
necessary for compatibility with our installed base.
Thanks,
Paul Suhler
Paul A. Suhler | Firmware Engineer - Removable Storage Solutions |
Quantum Corp. | 949.856.7748 | paul.suhler at quantum.com
 
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.
Permission is hereby explicitly granted to disclose, copy, and further
distribute to any individual(s) or organization(s), without restriction.
-----------------------------------------------------------
The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.


From plavarre at lexar.com  Tue Jan  8 11:40:11 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Tue, 8 Jan 2008 11:40:11 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.64.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
> I'm sorry, I don't see any problem with the text in SPC-4 at present.
> ...
> What is unclear about that?
Yes, I'm delighted always to find another person on Earth fascinated by
such obscure details.
No, I don't think we're allowed to discuss this Subject further here.
I look forward to the launch of T10.wikidot.com.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From rsnively at brocade.com  Tue Jan  8 11:38:44 2008
From: rsnively at brocade.com (Robert Snively)
Date: Tue, 8 Jan 2008 11:38:44 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.65.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Robert Snively" <rsnively at Brocade.COM>
*
I'm sorry, I don't see any problem with the text in SPC-4
at present.
The text says pretty clearly and means pretty unambiguously:
If EVPD is set to zero, you can set the allocation length
to any value you want.	However, if you are foolish enough
to set it to less than five, you won't know how much data
you are not receiving.
Similarly, if EVPD is set to one, you can set the allocation
length to any value you want.  However, if you are foolish
enough to set it to less than four, you won't know how much 
data you are not receiving.
What is unclear about that?
Bob
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
plavarre at lexar.com
Sent: Tuesday, January 08, 2008 9:10 AM
To: t10 at t10.org
Subject: RE: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
maybe
* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
> correct is: "[should be at least] ... means should not be less".
Agreed!
> Please take your whimsical rewrites of SPC-4 r11 subclause 3.3 to some
less rigorous reflector.
Ok will do.
The Spcr411.pdf paragraph at issue was """The ALLOCATION LENGTH field is
defined in 4.3.4.6. If EVPD is set to zero, the allocation length should
be at least five, so that the ADDITIONAL LENGTH field in the parameter
data (see 6.4.2) is returned. If EVPD is set to one, the allocation
length should be should be at least four, so that the PAGE LENGTH field
in the parameter data (see 7.6) is returned."""
If ever offline I do learn more of what this means, I'll run it by
somebody official like you for permission to give back here.
E-mail suffers from the evil of interrupting everyone to reach the
interested minority. Remember the long inconclusive talk of what it
means when hosts and devices disagree over how many data bytes to copy
each way?
Wiki doesn't suffer from that evil. Someday we'll have a wiki too, I
think,
*
* 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 plavarre at lexar.com  Tue Jan  8 11:56:27 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Tue, 8 Jan 2008 11:56:27 -0800
Subject: T10.wikidot.com
Message-ID: <mailman.66.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
> > > What would be the purpose/charter of T10.wikidot.com ?
As follows?
> In particular, what information do you expect to show up there
> that should not show up also in both the T10 e-mail archive and the
T10 web-site?
Deeper discussion!
Exactly all the info that now falls between the cracks -- too deep and
narrow for e-mail, with that narrowness also keeping the info from being
officially interesting enough for a page of the T10 web-site. That is to
say, content produced in a "bazaar" by the community, rather than in a
"cathedral" by the officials, if you know that metaphor already?
Off the top of my head, I can easily imagine ...
Seven examples:
-- Example 1
Copies of the Unix man pages for Scsi development tools owned by my
employer, works that resemble the previously self-published gccscsi pldd
plscsi.
Last month I got permission to publish the man pages, but I haven't yet
found a good home for them. I am myself especially delighted with the
expressiveness of fragments like:
>>> mse = Spc.ModeSense6()
>>> hexes(mse.commandOutBytes())
'1A 08 3F 00 04 00'
>>> bytes = mse.readAvailable(scsi)
>>> mse.sbcWriteable()
True
>>> print Sbc.HcsModePage(mse)
1017741312 = ~1.02 G = ~971 Mi bytes in 1987776 blocks of 512 bytes
(3CA98000h bytes in 07B4h * 10h * 3Fh = 1E54C0h blocks of 200h bytes)
5000 Kb/s
>>>
-- Example 2
A list of how many duplicate conflicting definitions exist at
http://t10.org/lists/op-num.htm and an explanation of them, e.g., the
example I understand:
23  V	V V    V
23	 O	    READ FORMAT CAPACITIES
and the examples that I do not understand such as:
1B  O	OOO O MO O  START STOP UNIT
1B   O		M   LOAD UNLOAD
1B		    SCAN
1B    O 	    STOP PRINT
1B	   O	    OPEN/CLOSE IMPORT/EXPORT ELEMENT
Etc.
-- Example 3
Talk of well-known vendor-specific extensions to Scsi: e.g., the
Microsoft Windows uses of op 23h Read Format Capacities results to
reclassify an 00h Peripheral Device Type as a Disk Sys or Sfloppy Sys
device; e.g., the Apple Mac OS ways of deciding if Eject is meaningful
for a 00h device.
-- Example 4
Concise talk of how completely intentional is the implicit "should not
ever be less" than four are the should rules for allocation length in
Spc Inquiry.
-- Example 5
Concise talk of what a Scsi command means when differing interpretations
of the relevant standards leave the host and device disagreeing over how
many data bytes to copy which way.
-- Example 6
Links to valuable well-known Scsi community resources like:
http://www.bswd.com/cornucop.htm
http://www.google.com/search?q=related:www.usb.org/developers/devclass_d
ocs/usbmassbulk_10.pdf
-- Example 7
Etc.
Get it?
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Harry.Mason at lsi.com  Tue Jan  8 12:29:39 2008
From: Harry.Mason at lsi.com (Mason, Harry)
Date: Tue, 8 Jan 2008 13:29:39 -0700
Subject: [STA Members] STA Reception January 14th,
	CALL FOR PRESENTATIONS : Beyond SAS-2
Message-ID: <mailman.67.1441607335.22514.t10@sandbox.t10.org>

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

With the enthusiastic response to our call for presentations, it looks
like we'll have a full evening on Monday.
Once again the idea is to share with others, our thoughts about moving
the SAS standards ahead.
There will be very limited time available for interaction, and
presentations will need to be limited to 15 minutes each.
We plan to have subsequent meetings that will outline the STA marketing
requirements and to wrestle with more of the implementation details.
The presentations for Monday are listed below in no specific order.
I'll send out a final agenda before the end of the week.
Looking forward to a lively kick-off to the New Year!
Thanks
Harry
719-331-0994
- "An idea of 6G implementation" (Dynamic line Length Compensation
[DLC]) - Masakazu Kawamoto, Fujitsu Japan
- "Considerations for Active Cables for SAS-2 and Beyond" - Quellan
- "Beyond SAS-2" - Rob Elliot, HP
- "Improving SAS for future generations" - LSI
- New Internal and External Interconnects - Jay Neer, Molex
- QSFP for SAS - Tom Palkert, Luxtera
________________________________
From: Mason, Harry 
Sent: Wednesday, December 12, 2007 3:31 PM
To: 'T10 Reflector'
Cc: 'board at scsita.org'; 'Chris Lyon'; 'members at scsita.org'
Subject: STA Reception January 14th, CALL FOR PRESENTATIONS : Beyond
SAS-2
CALL FOR PRESENTATIONS
Being in the final stages of buttoning down the SAS-2, the SCSI Trade
Association would like to take the opportunity in Santa Ana, to discuss,
what comes next.  
Some are suggesting an interim specification to clean up SAS-2 and
possibly include additional cabling options.  Others are suggesting we
split the physical interface work from the SAS-3 standard development
effort.  I'm sure there are many other ideas on how to proceed and what
technologies should be considered in future SAS instantiations. 
All T10 and current STA members are invited to an open discussion on
this subject.
The reception will begin at 6:30pm on Monday January 14th at the Embassy
Suites in Santa Ana. .	Food and beverages will be provided. 
STA will make available up to six, 15 minute presentation slots, and the
topics are open to most anything we should be considering in future SAS
generations.
Please respond directly to clyon at scsita.org  with your presentation
topic and we'll add you to the agenda!
Looking forward to an informative and lively discussion
Thanks, 
Harry Mason
STA President
719-331-0994


From plavarre at lexar.com  Tue Jan  8 11:58:56 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Tue, 8 Jan 2008 11:58:56 -0800
Subject: T10.wikidot.com
Message-ID: <mailman.68.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
> > > What would be the purpose/charter of T10.wikidot.com ?
Also I think the netiquette pushed by the charter should include the
theory that a neutral point of view exists, a la
http://en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_view
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From matthew at wil.cx  Tue Jan  8 11:12:29 2008
From: matthew at wil.cx (Matthew Wilcox)
Date: Tue, 8 Jan 2008 12:12:29 -0700
Subject: Omission of RBC READ CAPACITY command in SPC4r11
Message-ID: <mailman.69.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Matthew Wilcox <matthew at wil.cx>
*
In table C.2 (part 2 of 6) on page 475, the READ CAPACITY command
(opcode 25h) is not listed as being mandatory for RBC devices.
I believe this to be an omission based on section 5.3 of the rbc-r10a
PDF.  Could this be corrected?
-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From plavarre at lexar.com  Tue Jan  8 12:13:07 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Tue, 8 Jan 2008 12:13:07 -0800
Subject: T10.wikidot.com
Message-ID: <mailman.70.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
P.S.
http://members.aol.com/ppaatt/#%5B%5BWork%20In%20Progress%5D%5D
is one concrete example of a mostly technical wiki that I created over
the past year or so. (Sorry to say, to see the text you may have to page
down if you visit with Microsoft Internet Explorer rather than Apple
Safari or Mozilla Firefox).
That TiddlyWiki tech works well enough when you only have one person
contributing like a blog. But TiddlyWiki tech doesn't let us all
contribute like Wikidot.com would.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From plavarre at lexar.com  Tue Jan  8 12:30:16 2008
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Tue, 8 Jan 2008 12:30:16 -0800
Subject: T10.wikidot.com
Message-ID: <mailman.71.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
> > > What would be the purpose/charter of T10.wikidot.com ?
And of course the shorter answer is ...
Yes the purpose/charter should be the first article posted, a la
http://en.wikipedia.org/wiki/Wikipedia:Policies_and_guidelines
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Harry.Mason at lsi.com  Tue Jan  8 12:29:39 2008
From: Harry.Mason at lsi.com (Mason, Harry)
Date: Tue, 8 Jan 2008 13:29:39 -0700
Subject: STA Reception January 14th, CALL FOR PRESENTATIONS : Beyond SAS-2
Message-ID: <mailman.72.1441607335.22514.t10@sandbox.t10.org>

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

With the enthusiastic response to our call for presentations, it looks
like we'll have a full evening on Monday.
Once again the idea is to share with others, our thoughts about moving
the SAS standards ahead.
There will be very limited time available for interaction, and
presentations will need to be limited to 15 minutes each.
We plan to have subsequent meetings that will outline the STA marketing
requirements and to wrestle with more of the implementation details.
The presentations for Monday are listed below in no specific order.
I'll send out a final agenda before the end of the week.
Looking forward to a lively kick-off to the New Year!
Thanks
Harry
719-331-0994
- "An idea of 6G implementation" (Dynamic line Length Compensation
[DLC]) - Masakazu Kawamoto, Fujitsu Japan
- "Considerations for Active Cables for SAS-2 and Beyond" - Quellan
- "Beyond SAS-2" - Rob Elliot, HP
- "Improving SAS for future generations" - LSI
- New Internal and External Interconnects - Jay Neer, Molex
- QSFP for SAS - Tom Palkert, Luxtera
________________________________
From: Mason, Harry 
Sent: Wednesday, December 12, 2007 3:31 PM
To: 'T10 Reflector'
Cc: 'board at scsita.org'; 'Chris Lyon'; 'members at scsita.org'
Subject: STA Reception January 14th, CALL FOR PRESENTATIONS : Beyond
SAS-2
CALL FOR PRESENTATIONS
Being in the final stages of buttoning down the SAS-2, the SCSI Trade
Association would like to take the opportunity in Santa Ana, to discuss,
what comes next.  
Some are suggesting an interim specification to clean up SAS-2 and
possibly include additional cabling options.  Others are suggesting we
split the physical interface work from the SAS-3 standard development
effort.  I'm sure there are many other ideas on how to proceed and what
technologies should be considered in future SAS instantiations. 
All T10 and current STA members are invited to an open discussion on
this subject.
The reception will begin at 6:30pm on Monday January 14th at the Embassy
Suites in Santa Ana. .	Food and beverages will be provided. 
STA will make available up to six, 15 minute presentation slots, and the
topics are open to most anything we should be considering in future SAS
generations.
Please respond directly to clyon at scsita.org  with your presentation
topic and we'll add you to the agenda!
Looking forward to an informative and lively discussion
Thanks, 
Harry Mason
STA President
719-331-0994


From roweber at IEEE.org  Tue Jan  8 12:38:48 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Tue, 08 Jan 2008 14:38:48 -0600
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.73.1441607335.22514.t10@sandbox.t10.org>

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

Pat,
"We" (including you) are allowed to discuss any SCSI subject you like
here. However, some (dare I say many) of us think this particular
subject amounts to flogging a dead horse.
For example, my best guess is that you have zero change of seeing
a single work of SPC-4 changed as a result of any past or future
discussions of this topic.
We are hoping the root canal will end soon, but that is almost
entirely your call.
As for creating a reflector devoted to the question: "How many
ways can I misinterpret an American National Standard?" ...
I find the prospect repugnant in the extreme.
Regards,
.Ralph
plavarre at lexar.com wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * <plavarre at lexar.com>
> *
>   
>> I'm sorry, I don't see any problem with the text in SPC-4 at present.
>> ...
>> What is unclear about that?
>>     
>
> Yes, I'm delighted always to find another person on Earth fascinated by
> such obscure details.
>
> No, I don't think we're allowed to discuss this Subject further here.
>
> I look forward to the launch of T10.wikidot.com.
>
> *
> * 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  Tue Jan  8 12:45:53 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 08 Jan 2008 13:45:53 -0700
Subject: T10.wikidot.com
Message-ID: <mailman.74.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
Pat,
I am getting overwhelmed by the shear number of emails that are popping up in
my inbox about this thread and under-whelmed by the actual content.
The idea of creating an T10.wikidot.com site sounds like the latest round in
a food fight that needs to stop now. 
I believe that Ralph proclaimed your topic inappropriate for the T10
reflector in a fit of frustration over not being able to communicate clearly
with you. I am sure Ralph regrets his email.
For the record, product commercials and job solicitation emails are banned
|from the T10 reflector. All other SCSI topics are fair game no matter how
tedious they might appear to be.
I stayed quiet until now hoping the issue would blow over, but it appears to
be getting out of hand. I think it is time to end this squabble.
John
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI 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 agrawehr at quix.ch  Tue Jan  8 13:43:08 2008
From: agrawehr at quix.ch (Andy Grawehr)
Date: Tue, 8 Jan 2008 22:43:08 +0100
Subject: T10.wikidot.com
Message-ID: <mailman.75.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Andy Grawehr <agrawehr at quix.ch>
*
pat, with all respect, please reduce the frequency of postings. this was the
5th post within one hour. 
your technical expertise is better than having to rant. there *are* people on
the reflector who read your postings.
about a wiki being more concise than the reflector... well, that ends up
being well possible if you continue to post 2-line emails to the reflector at
that frequency.
otherwise i prefer the T10 way. the language *is* concise. 
andy grawehr
quix computerware ag
zug, switzerland 
*
* 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  Tue Jan  8 14:00:39 2008
From: Larry_Chen at pmc-sierra.com (Larry Chen)
Date: Tue, 8 Jan 2008 14:00:39 -0800
Subject: SAS2 - OPEN TIMEOUT
Message-ID: <mailman.76.1441607335.22514.t10@sandbox.t10.org>

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

Is there any mechanism in place to _exclude_ OPEN TIMEOUT from being
retried (see
RED font below for details). I think there is a danger of masking out
errors if OPEN TIMEOUT
Is blindly retried.
---
4.5 I_T nexus loss
When a SAS port receives OPEN_REJECT (NO DESTINATION), OPEN_REJECT
(PATHWAY BLOCKED),
OPEN_REJECT (RESERVED INITIALIZE 0), OPEN_REJECT (RESERVED INITIALIZE
1), OPEN_REJECT
(RESERVED STOP 0), OPEN_REJECT (RESERVED STOP 1), or an open connection
timeout occurs in
response to a connection request, it shall retry the connection request
until:
a) the connection is established;
b) for SSP target ports, the time indicated by the I_T NEXUS LOSS TIME
field in the Protocol-Specific Port
mode page (see 10.2.7.4) expires; or
c) the I_T nexus loss timer, if any, expires (see 4.7.1, 8.2.2.1,
10.2.7.4, and 10.4.3.17).


From endlcom at acm.org  Tue Jan  8 12:40:24 2008
From: endlcom at acm.org (Dal Allan)
Date: Tue, 08 Jan 2008 12:40:24 -0800
Subject: T10.wikidot.com
Message-ID: <mailman.77.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Dal Allan <endlcom at acm.org>
*
Pat,
     Pick up the phone!
Use it to have a discussion with Ralph and whoever else you feel needs to
understand the point you are trying to make.
The internet has lots of virtues but settling confrontations by email or
wikis is not one of them.
If you want/need a wider audience, schedule a telecon.
Just about everyone involved with standards becomes a PITA at some time on
some particular point of passion. The best solution has always been to have
the primary combatants go to  lunch/dinner/drinks together and work it out.
John Geldman attends the standards meetings for Lexar. If you think there is
something elementally missing/broken with the T10 process, work with him to
propose a solution.
Dal
*
* 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  Tue Jan  8 18:31:51 2008
From: daviburg at windows.microsoft.com (David Burg)
Date: Tue, 8 Jan 2008 18:31:51 -0800
Subject: Posted: Pioneer counter proposal
Message-ID: <mailman.78.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* David Burg <daviburg at windows.microsoft.com>
*
Hello Katata-san,
Thank you for the clarification of the source of your customer data.
Hopefully now that we provided Dell's statement there is no confusion
anymore.
It should be 3x DVD speed required for HD content on DVD. Actually, this is
even the name of the 3X DVD-ROM specification that was created for HD content
on red laser. At 2x DVD speed, the bandwidth is too low at inner ring for
pike bit rate of HD video (30 Mbps). In tests it results in nearly constant
stutters.
> "Real Time Streaming feature"
> This feature does not have capability for "execution time for an I/O
operation".
This feature has Get Performance command that describes the I/O performance
of the device, i.e. throughput. As throughput are expressed in kB/s, simple
mathematics allow from the I/O operation size in kB to compute the execution
time in seconds. Accordingly, this feature does describe execution times.
> I understood a problem that HD not-ready drive does not have good
performance
for HD content playback. Pioneer simple proposal has the solution for this
problem.
Pioneer's proposal does not address the problem of identifying the device's
performance capabilities, identification required to distinguish drives with
sufficient performance and drives without. This is a requirement given by
Toshiba in the middle of 2007 when the topic of HD on red laser was first
brought to the committee. Microsoft at the time had commented that the
problem is generic to high bandwidth content and not specific to HD video
only, thus joined the specification effort proposal which after a long design
and collaboration effort resulted in the detailed comprehensive proposal made
in Las Vegas in November.
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: Monday, January 07, 2008 9:43 PM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: RE: Posted: Pioneer counter proposal
Hello Daivd,
I'm sorry that I do not have a connection with manager of high rank. I work
for
end users/ordinary PC users side. So I may have communication with
people/engineer such as sales side, Quality Control side, Customer support
side
and retail shop side.
"due to insufficient average data rate"
Specification allows much possibility than the possibility that may be
possible
in the market. DVD 2X transfer rate is OK for HD content on DVD. Most of DVD
slim drive have this speed now.
In addition, to support DVD+R/+RW, 3.3X is supported on DVD writer drive.
Currently HD ready system (ex. Vista premium model) has new good performance
ODD
drive. What I want to say is that already PC manufactures have released HD
ready
system to the market. Of course old drive or low performance drive may be
bad.
"Real Time Streaming feature"
This feature does not have capability for "execution time for an I/O
operation".
A series of commands will be executed appropriately for Streaming. This is
basic
function of ODD drive.
I understood a problem that HD not-ready drive does not have good performance
for HD content playback. Pioneer simple proposal has the solution for this
problem.
I do not understand the root cause of your "execution time for an I/O
operation"
problem. You may inform us about what is problem (and root cause) of
"execution
time for an I/O operation".
Best regards,
Keiji Katata
PIONEER CORP.
David Burg <daviburg at windows.microsoft.com>@avc-pioneer.com on 2008/01/08
12:17: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" <mtfuji5 at avc-pioneer.com>
cc:    T10 Reflector <t10 at t10.org>
bcc:
$B7oL>(B:  RE: Posted: Pioneer counter proposal
Dear Katata-san,
This proposal is highly different from Microsoft-Toshiba proposal and you
mention "Pioneer and its partner companies do not receive any request of the
above items from PC manufactures."
I believe however that David Walp already shared with the committee at the
previous meeting the following from Dell in a response to a similar comment
you
made at the Las Vegas meeting. It case it slipped through, let me repeat it
here:
" From: Lee, Kah Soon
Sent: Saturday, December 15, 2007 3:04 AM
To: David Walp
Cc: David Burg; Lo, James; Sellers, Sabrina
Importance: High
Hi, David.
James and I have reviewed the new Mt. Fuji proposal on speed detection and
control commands update.
We have no concern on the proposal and this is aligned with our goal in
acoustic
noise issue. We agreed with the proposed solution.
[...]
Regards, Kah Soon"
This person from Dell later added:
"Thanks for sharing with us on the status of this proposal.
Please let us know whether you need any help from us to work together with
our
optical drives suppliers, especially the prototype drives/firmware.
Just keep us posted on the progress."
I observe that there is here a disconnect between Pioneer's statement and
what
Dell communicated to Microsoft (and allowed to share as their statement).
I further cannot concur with Pioneer's claims with regard to "A minimum
average
data rate for HD content on DVD is guaranteed already. So new scheme is not
necessary." As a matter of fact Microsoft and partners have prototyped HD DVD
Video content on Red laser DVD and due to insufficient average data rate the
playback is badly jittered. Work is required!
Multiple other host software companies already joined Microsoft in the
request
for reporting logical unit performance capabilities to the end user and few
even
sent representatives to the committee meeting. I am amazed that Pioneer still
denies the existence of this request!
Pioneer claims that reporting precise execution time for an I/O operation
does
not have any relationship with Real Time Streaming issue. However it is
exactly
the misunderstandings around the existing Real Time Streaming feature and
fabrication of inaccurate respond data to performance command associated with
this feature that cause execution time for an I/O operation to be reported
imprecisely (the device performing actually at different speed than it was
instructed and different than it is reporting)!
I just returned yesterday to US and I am not able to attend the 1/9 SWG
meeting
in Japan. I ask however that you consider the feedback we have provided.
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, December 26, 2007 10:06 PM
To: mtfuji5 at avc-pioneer.com
Cc: T10 Reflector
Subject: Posted: Pioneer counter proposal
Hello all,
I posted a counter proposal for 1/9 SWG.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Jan08/SWG/Pioneer Stream Model.doc
Best regards,
Keiji Katata
PIONEER CORP.
TEL +81-49-279-2387
*
* 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 Jan  9 08:14:47 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 9 Jan 2008 09:14:47 -0700
Subject: SAS2 - OPEN TIMEOUT
Message-ID: <mailman.79.1441607335.22514.t10@sandbox.t10.org>

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

 I do not see a reason to distinguish an open timeout from the other 
errors.  Unless there is a very good reason, I would prefer to leave the 
text as is.  It seems to me that we should retry open timeouts, since it 
may work the next time.  Also, the point of doing recovery operations is 
to mask errors (so that the job can continue), so that does not seem like 
a good reason to stop attempting the recovery. 
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/ 
"Larry Chen" <Larry_Chen at pmc-sierra.com> 
Sent by: owner-t10 at t10.org
01/08/2008 03:00 PM
To
<t10 at t10.org>
cc
Subject
SAS2 - OPEN TIMEOUT
Is there any mechanism in place to _exclude_ OPEN TIMEOUT from being 
retried (see
RED font below for details). I think there is a danger of masking out 
errors if OPEN TIMEOUT
Is blindly retried.
---
4.5 I_T nexus loss
When a SAS port receives OPEN_REJECT (NO DESTINATION), OPEN_REJECT 
(PATHWAY BLOCKED),
OPEN_REJECT (RESERVED INITIALIZE 0), OPEN_REJECT (RESERVED INITIALIZE 1), 
OPEN_REJECT
(RESERVED STOP 0), OPEN_REJECT (RESERVED STOP 1), or an open connection 
timeout occurs in
response to a connection request, it shall retry the connection request 
until:
a) the connection is established;
b) for SSP target ports, the time indicated by the I_T NEXUS LOSS TIME 
field in the Protocol-Specific Port
mode page (see 10.2.7.4) expires; or
c) the I_T nexus loss timer, if any, expires (see 4.7.1, 8.2.2.1, 
10.2.7.4, and 10.4.3.17).


From Paul.Suhler at Quantum.com  Wed Jan  9 10:03:37 2008
From: Paul.Suhler at Quantum.com (Paul Suhler)
Date: Wed, 9 Jan 2008 10:03:37 -0800
Subject: ADT-3 Project Proposal Uploaded
Message-ID: <mailman.80.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Paul Suhler" <Paul.Suhler at Quantum.Com>
*
I have posted a project proposal for the third-generation of the
Automation/Drive Interface Transport Protocol (ADT-3).	The major
addition will be iADT, transport of ADT over networking protocols.
The proposal is now available at:
   http://www.t10.org/ftp/t10/document.08/08-054r0.pdf
Because this missed the two-week deadline, it will not be voted on next
week.
Thanks,
Paul Suhler
Paul A. Suhler | Firmware Engineer - Removable Storage Solutions |
Quantum Corp. | 949.856.7748 | paul.suhler at quantum.com
++++++++++++++++++++++++++++++++++++
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.
Permission is hereby explicitly granted to disclose, copy, and further
distribute to any individual(s) or organization(s), without restriction.
-----------------------------------------------------------
The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.
------------------------------------------------------------
*
* 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  Wed Jan  9 13:35:21 2008
From: Larry_Chen at pmc-sierra.com (Larry Chen)
Date: Wed, 9 Jan 2008 13:35:21 -0800
Subject: SAS2 - OPEN TIMEOUT
Message-ID: <mailman.81.1441607335.22514.t10@sandbox.t10.org>

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

IMO, Timeouts are more serious than OPEN_REJECTs (and NAK, SCSI Busy and
Full Queue) Responses.
If Timeouts are _not_ reported to the host driver and/or the diagnostic
monitoring code then the problem can not
be detected and rectified Via a FRU swap.
________________________________
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Wednesday, January 09, 2008 8:15 AM
To: Larry Chen
Cc: t10 at t10.org
Subject: Re: SAS2 - OPEN TIMEOUT
 I do not see a reason to distinguish an open timeout from the other
errors.  Unless there is a very good reason, I would prefer to leave the
text as is.  It seems to me that we should retry open timeouts, since it
may work the next time.  Also, the point of doing recovery operations is
to mask errors (so that the job can continue), so that does not seem
like a good reason to stop attempting the recovery.   
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/ 
"Larry Chen" <Larry_Chen at pmc-sierra.com> 
Sent by: owner-t10 at t10.org 
01/08/2008 03:00 PM 
To
<t10 at t10.org> 
cc
Subject
SAS2 - OPEN TIMEOUT
Is there any mechanism in place to _exclude_ OPEN TIMEOUT from being
retried (see 
RED font below for details). I think there is a danger of masking out
errors if OPEN TIMEOUT 
Is blindly retried. 
--- 
4.5 I_T nexus loss 
When a SAS port receives OPEN_REJECT (NO DESTINATION), OPEN_REJECT
(PATHWAY BLOCKED), 
OPEN_REJECT (RESERVED INITIALIZE 0), OPEN_REJECT (RESERVED INITIALIZE
1), OPEN_REJECT 
(RESERVED STOP 0), OPEN_REJECT (RESERVED STOP 1), or an open connection
timeout occurs in 
response to a connection request, it shall retry the connection request
until: 
a) the connection is established; 
b) for SSP target ports, the time indicated by the I_T NEXUS LOSS TIME
field in the Protocol-Specific Port 
mode page (see 10.2.7.4) expires; or 
c) the I_T nexus loss timer, if any, expires (see 4.7.1, 8.2.2.1,
10.2.7.4, and 10.4.3.17). 


From Elliott at hp.com  Wed Jan  9 14:58:47 2008
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Wed, 9 Jan 2008 22:58:47 +0000
Subject: SAS2 - OPEN TIMEOUT
Message-ID: <mailman.82.1441607335.22514.t10@sandbox.t10.org>

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

The OPEN is not blindly retried - it's retried only until the I_T Nexus Loss
Time timer expires (normally 2 seconds).
The most likely reason for Open Timeout timer expiration is that the OPEN
address frame suffered a single-bit error.  Since there is no ACK/NAK for
address frames, the only indication of a problem is the lack of an AIP,
OPEN_ACCEPT, or OPEN_REJECT.  The originator times out after 1 ms and retries
(so a single-bit error doesn't cause a major error).
If the bit error keeps occuring, though, the I_T Nexus Loss Time will kick in
and a major error will be reported (the destination is unreachable).
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Larry Chen
Sent: Wednesday, January 09, 2008 3:35 PM
To: Kevin D Butt
Cc: t10 at t10.org
Subject: RE: SAS2 - OPEN TIMEOUT
IMO, Timeouts are more serious than OPEN_REJECTs (and NAK, SCSI Busy and Full
Queue) Responses.
If Timeouts are _not_ reported to the host driver and/or the diagnostic
monitoring code then the problem can not
be detected and rectified Via a FRU swap.
________________________________
From: Kevin D Butt [mailto:kdbutt at us.ibm.com]
Sent: Wednesday, January 09, 2008 8:15 AM
To: Larry Chen
Cc: t10 at t10.org
Subject: Re: SAS2 - OPEN TIMEOUT
 I do not see a reason to distinguish an open timeout from the other errors. 
Unless there is a very good reason, I would prefer to leave the text as is. 
It seems to me that we should retry open timeouts, since it may work the next
time.  Also, the point of doing recovery operations is to mask errors (so
that the job can continue), so that does not seem like a good reason to stop
attempting the recovery.
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/
"Larry Chen" <Larry_Chen at pmc-sierra.com>
Sent by: owner-t10 at t10.org
01/08/2008 03:00 PM
To
<t10 at t10.org>
cc
Subject
SAS2 - OPEN TIMEOUT
Is there any mechanism in place to _exclude_ OPEN TIMEOUT from being retried
(see
RED font below for details). I think there is a danger of masking out errors
if OPEN TIMEOUT
Is blindly retried.
---
4.5 I_T nexus loss
When a SAS port receives OPEN_REJECT (NO DESTINATION), OPEN_REJECT (PATHWAY
BLOCKED),
OPEN_REJECT (RESERVED INITIALIZE 0), OPEN_REJECT (RESERVED INITIALIZE 1),
OPEN_REJECT
(RESERVED STOP 0), OPEN_REJECT (RESERVED STOP 1), or an open connection
timeout occurs in
response to a connection request, it shall retry the connection request
until:
a) the connection is established;
b) for SSP target ports, the time indicated by the I_T NEXUS LOSS TIME field
in the Protocol-Specific Port
mode page (see 10.2.7.4) expires; or
c) the I_T nexus loss timer, if any, expires (see 4.7.1, 8.2.2.1, 10.2.7.4,
and 10.4.3.17).


From Gerry.Houlder at seagate.com  Wed Jan  9 15:08:32 2008
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Wed, 9 Jan 2008 17:08:32 -0600
Subject: SAS2 - OPEN TIMEOUT
Message-ID: <mailman.83.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
SAS is set up so that repeated open timeouts will eventually result in I_T
nexus timeout, which will bring attention to the issue. The intent is that
a couple of open timeouts (which is only 1 Msec) might not be a serious
issue (e.g., device might be waking up from a low power mode and is still a
bit slow) but repeated timeouts are serious.
	     "Larry Chen"						   
	     <Larry_Chen at pmc-s						   
	     ierra.com> 						To 
	     Sent by:		       "Kevin D Butt" <kdbutt at us.ibm.com>  
	     owner-t10 at t10.org						cc 
	     No Phone Info	       <t10 at t10.org>			   
	     Available						   Subject 
				       RE: SAS2 - OPEN TIMEOUT		   
	     01/09/2008 03:35						   
	     PM 							   
IMO, Timeouts are more serious than OPEN_REJECTs (and NAK, SCSI Busy and
Full Queue) Responses.
If Timeouts are _not_ reported to the host driver and/or the diagnostic
monitoring code then the problem can not
be detected and rectified Via a FRU swap.
From: Kevin D Butt [mailto:kdbutt at us.ibm.com]
Sent: Wednesday, January 09, 2008 8:15 AM
To: Larry Chen
Cc: t10 at t10.org
Subject: Re: SAS2 - OPEN TIMEOUT
 I do not see a reason to distinguish an open timeout from the other
errors.  Unless there is a very good reason, I would prefer to leave the
text as is.  It seems to me that we should retry open timeouts, since it
may work the next time.  Also, the point of doing recovery operations is to
mask errors (so that the job can continue), so that does not seem like a
good reason to stop attempting the recovery.
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/
 "Larry Chen" <Larry_Chen at pmc-sierra.com>				   
 Sent by: owner-t10 at t10.org						   
									To 
 01/08/2008 03:00 PM					    <t10 at t10.org>  
									cc 
								   Subject 
							    SAS2 - OPEN    
							    TIMEOUT	   
Is there any mechanism in place to _exclude_ OPEN TIMEOUT from being
retried (see
RED font below for details). I think there is a danger of masking out
errors if OPEN TIMEOUT
Is blindly retried.
---
4.5 I_T nexus loss
When a SAS port receives OPEN_REJECT (NO DESTINATION), OPEN_REJECT (PATHWAY
BLOCKED),
OPEN_REJECT (RESERVED INITIALIZE 0), OPEN_REJECT (RESERVED INITIALIZE 1),
OPEN_REJECT
(RESERVED STOP 0), OPEN_REJECT (RESERVED STOP 1), or an open connection
timeout occurs in
response to a connection request, it shall retry the connection request
until:
a) the connection is established;
b) for SSP target ports, the time indicated by the I_T NEXUS LOSS TIME
field in the Protocol-Specific Port
mode page (see 10.2.7.4) expires; or
c) the I_T nexus loss timer, if any, expires (see 4.7.1, 8.2.2.1, 10.2.7.4,
and 10.4.3.17).
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Bob.Sheffield at lsi.com  Wed Jan  9 15:35:22 2008
From: Bob.Sheffield at lsi.com (Sheffield, Bob)
Date: Wed, 9 Jan 2008 16:35:22 -0700
Subject: SAS2 - OPEN TIMEOUT
Message-ID: <mailman.84.1441607335.22514.t10@sandbox.t10.org>

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

This discussion raises a more basic question for me: does the term,
"open connection timeout" mean the same thing as "Connection Timeout
Timer expires"? The term, "open connection timeout" occurs only once in
the entire standard (in subclause 4.5), whereas the term "Open Timeout
Timer expires" occurs 7 times in the text. The latter is what happens
when the attached phy doesn't send an ARB for 1ms. There is a
corresponding confirmation from the link layer to the port layer, "Open
Timeout Occurred", which sounds a lot like "open connection timeout",
but is not explicitly equivalent.
Subclause 8.2.2.3.2 PL_OC2:Overall_Control state establishing
connections states:
	If this state receives a Retry Open (No Destination) or a Retry
Open (Open
	Timeout Occurred) message and an I_T Nexus Loss timer has not
been created for
	the destination SAS address (e.g., an SSP target port does not
support the I_T
	NEXUS LOSS TIME field in the Protocol-Specific Port mode page or
the field is
	set to 0000h), then this state shall process the Retry Open
message as either a
	Retry Open message or an Unable To Connect message. This
selection is
	vendor-specific.
Indicating it may be optional whether to retry or not. This behavior is
at the port level, so it applies not only to initiator ports, but also
to target ports and expander ports. I could see different port types
needing to handle this differently.
Incidently, a self-configuring expander has a way to report this
condition to a management application, "Connection request failed: Open
Timeout timer expired" (see table 235 in subclause 10.4.3.5.4
Self-configuration status descriptor).
Bob Sheffield
LSI Corporation
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Larry
Chen
Sent: Wednesday, January 09, 2008 2:35 PM
To: Kevin D Butt
Cc: t10 at t10.org
Subject: RE: SAS2 - OPEN TIMEOUT
IMO, Timeouts are more serious than OPEN_REJECTs (and NAK, SCSI Busy and
Full Queue) Responses.
If Timeouts are _not_ reported to the host driver and/or the diagnostic
monitoring code then the problem can not
be detected and rectified Via a FRU swap.
________________________________
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Wednesday, January 09, 2008 8:15 AM
To: Larry Chen
Cc: t10 at t10.org
Subject: Re: SAS2 - OPEN TIMEOUT
 I do not see a reason to distinguish an open timeout from the other
errors.  Unless there is a very good reason, I would prefer to leave the
text as is.  It seems to me that we should retry open timeouts, since it
may work the next time.  Also, the point of doing recovery operations is
to mask errors (so that the job can continue), so that does not seem
like a good reason to stop attempting the recovery.   
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/ 
"Larry Chen" <Larry_Chen at pmc-sierra.com> 
Sent by: owner-t10 at t10.org 
01/08/2008 03:00 PM 
To
<t10 at t10.org> 
cc
Subject
SAS2 - OPEN TIMEOUT
Is there any mechanism in place to _exclude_ OPEN TIMEOUT from being
retried (see 
RED font below for details). I think there is a danger of masking out
errors if OPEN TIMEOUT 
Is blindly retried. 
--- 
4.5 I_T nexus loss 
When a SAS port receives OPEN_REJECT (NO DESTINATION), OPEN_REJECT
(PATHWAY BLOCKED), 
OPEN_REJECT (RESERVED INITIALIZE 0), OPEN_REJECT (RESERVED INITIALIZE
1), OPEN_REJECT 
(RESERVED STOP 0), OPEN_REJECT (RESERVED STOP 1), or an open connection
timeout occurs in 
response to a connection request, it shall retry the connection request
until: 
a) the connection is established; 
b) for SSP target ports, the time indicated by the I_T NEXUS LOSS TIME
field in the Protocol-Specific Port 
mode page (see 10.2.7.4) expires; or 
c) the I_T nexus loss timer, if any, expires (see 4.7.1, 8.2.2.1,
10.2.7.4, and 10.4.3.17). 


From Elliott at hp.com  Wed Jan  9 17:18:10 2008
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Thu, 10 Jan 2008 01:18:10 +0000
Subject: SAS2 - OPEN TIMEOUT
Message-ID: <mailman.85.1441607335.22514.t10@sandbox.t10.org>

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

1. The name in 4.5 is incorrect.  "open connection timeout occurs" should be
"Open Timeout timer expires (see 7.12.2)".  I'll mark that for sas2r14.
2. The rule in the port layer is only optional if there is no I_T Nexus Loss
timer.	If there is one, then Retry Open is processed as a Retry Open.	Mode
pages are optional in targets, so the target might not implement the timer. 
In initiators, there are no mode pages, so it's just a "should" that the
initiator implement an I_T Nexus Loss timer using the same value as the
target to which it is talking (see 8.2.2.3.1 and table 151 in 8.2.2.1).
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Sheffield,
Bob
Sent: Wednesday, January 09, 2008 5:35 PM
To: Larry Chen; Kevin D Butt
Cc: t10 at t10.org
Subject: RE: SAS2 - OPEN TIMEOUT
This discussion raises a more basic question for me: does the term, "open
connection timeout" mean the same thing as "Connection Timeout Timer
expires"? The term, "open connection timeout" occurs only once in the entire
standard (in subclause 4.5), whereas the term "Open Timeout Timer expires"
occurs 7 times in the text. The latter is what happens when the attached phy
doesn't send an ARB for 1ms. There is a corresponding confirmation from the
link layer to the port layer, "Open Timeout Occurred", which sounds a lot
like "open connection timeout", but is not explicitly equivalent.
Subclause 8.2.2.3.2 PL_OC2:Overall_Control state establishing connections
states:
If this state receives a Retry Open (No Destination) or a Retry Open (Open
Timeout Occurred) message and an I_T Nexus Loss timer has not been created
for
the destination SAS address (e.g., an SSP target port does not support the
I_T
NEXUS LOSS TIME field in the Protocol-Specific Port mode page or the field is
set to 0000h), then this state shall process the Retry Open message as either
a
Retry Open message or an Unable To Connect message. This selection is
vendor-specific.
Indicating it may be optional whether to retry or not. This behavior is at
the port level, so it applies not only to initiator ports, but also to target
ports and expander ports. I could see different port types needing to handle
this differently.
Incidently, a self-configuring expander has a way to report this condition to
a management application, "Connection request failed: Open Timeout timer
expired" (see table 235 in subclause 10.4.3.5.4 Self-configuration status
descriptor).
Bob Sheffield
LSI Corporation
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Larry Chen
Sent: Wednesday, January 09, 2008 2:35 PM
To: Kevin D Butt
Cc: t10 at t10.org
Subject: RE: SAS2 - OPEN TIMEOUT
IMO, Timeouts are more serious than OPEN_REJECTs (and NAK, SCSI Busy and Full
Queue) Responses.
If Timeouts are _not_ reported to the host driver and/or the diagnostic
monitoring code then the problem can not
be detected and rectified Via a FRU swap.
________________________________
From: Kevin D Butt [mailto:kdbutt at us.ibm.com]
Sent: Wednesday, January 09, 2008 8:15 AM
To: Larry Chen
Cc: t10 at t10.org
Subject: Re: SAS2 - OPEN TIMEOUT
 I do not see a reason to distinguish an open timeout from the other errors. 
Unless there is a very good reason, I would prefer to leave the text as is. 
It seems to me that we should retry open timeouts, since it may work the next
time.  Also, the point of doing recovery operations is to mask errors (so
that the job can continue), so that does not seem like a good reason to stop
attempting the recovery.
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/
"Larry Chen" <Larry_Chen at pmc-sierra.com>
Sent by: owner-t10 at t10.org
01/08/2008 03:00 PM
To
<t10 at t10.org>
cc
Subject
SAS2 - OPEN TIMEOUT
Is there any mechanism in place to _exclude_ OPEN TIMEOUT from being retried
(see
RED font below for details). I think there is a danger of masking out errors
if OPEN TIMEOUT
Is blindly retried.
---
4.5 I_T nexus loss
When a SAS port receives OPEN_REJECT (NO DESTINATION), OPEN_REJECT (PATHWAY
BLOCKED),
OPEN_REJECT (RESERVED INITIALIZE 0), OPEN_REJECT (RESERVED INITIALIZE 1),
OPEN_REJECT
(RESERVED STOP 0), OPEN_REJECT (RESERVED STOP 1), or an open connection
timeout occurs in
response to a connection request, it shall retry the connection request
until:
a) the connection is established;
b) for SSP target ports, the time indicated by the I_T NEXUS LOSS TIME field
in the Protocol-Specific Port
mode page (see 10.2.7.4) expires; or
c) the I_T nexus loss timer, if any, expires (see 4.7.1, 8.2.2.1, 10.2.7.4,
and 10.4.3.17).


From Larry_Chen at pmc-sierra.com  Wed Jan  9 17:40:41 2008
From: Larry_Chen at pmc-sierra.com (Larry Chen)
Date: Wed, 9 Jan 2008 17:40:41 -0800
Subject: SAS2 - OPEN TIMEOUT
Message-ID: <mailman.86.1441607335.22514.t10@sandbox.t10.org>

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

See comments inline.
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Elliott,
Robert (Server Storage)
Sent: Wednesday, January 09, 2008 2:59 PM
To: t10 at t10.org
Subject: RE: SAS2 - OPEN TIMEOUT
The OPEN is not blindly retried - it's retried only until the I_T Nexus
Loss Time timer expires (normally 2 seconds).
[Larry Chen] I meant auto-retry is enabled w/o allowing any host SW/FW
intervention.
The most likely reason for Open Timeout timer expiration is that the
OPEN address frame suffered a single-bit error.  Since there is no
ACK/NAK for address frames, the only indication of a problem is the lack
of an AIP, OPEN_ACCEPT, or OPEN_REJECT.  The originator times out after
1 ms and retries (so a single-bit error doesn't cause a major error).
[Larry Chen] I agree i.e., there isn't a NAK sent for a bad CRC in the
OPEN address frame.
If the bit error keeps occuring, though, the I_T Nexus Loss Time will
kick in and a major error will be reported (the destination is
unreachable).
[Larry Chen] The problem is that there isn't any history maintained via
error counters i.e., accumulative. In theory, each open
Connection request could go thru lengthy auto-retries and the host would
never be notified since the errors didn't occur consecutively.
-- 
Rob Elliott, elliott at hp.com 
Hewlett-Packard Industry Standard Server Storage Advanced Technology 
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Larry Chen
	Sent: Wednesday, January 09, 2008 3:35 PM
	To: Kevin D Butt
	Cc: t10 at t10.org
	Subject: RE: SAS2 - OPEN TIMEOUT
	IMO, Timeouts are more serious than OPEN_REJECTs (and NAK, SCSI
Busy and Full Queue) Responses.
	If Timeouts are _not_ reported to the host driver and/or the
diagnostic monitoring code then the problem can not
	be detected and rectified Via a FRU swap.
________________________________
	From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
	Sent: Wednesday, January 09, 2008 8:15 AM
	To: Larry Chen
	Cc: t10 at t10.org
	Subject: Re: SAS2 - OPEN TIMEOUT
	 I do not see a reason to distinguish an open timeout from the
other errors.  Unless there is a very good reason, I would prefer to
leave the text as is.  It seems to me that we should retry open
timeouts, since it may work the next time.  Also, the point of doing
recovery operations is to mask errors (so that the job can continue), so
that does not seem like a good reason to stop attempting the recovery.
	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/ 
"Larry Chen" <Larry_Chen at pmc-sierra.com> 
Sent by: owner-t10 at t10.org 
01/08/2008 03:00 PM 
To
<t10 at t10.org> 
cc
Subject
SAS2 - OPEN TIMEOUT
	Is there any mechanism in place to _exclude_ OPEN TIMEOUT from
being retried (see 
	RED font below for details). I think there is a danger of
masking out errors if OPEN TIMEOUT 
	Is blindly retried. 
	--- 
	4.5 I_T nexus loss 
	When a SAS port receives OPEN_REJECT (NO DESTINATION),
OPEN_REJECT (PATHWAY BLOCKED), 
	OPEN_REJECT (RESERVED INITIALIZE 0), OPEN_REJECT (RESERVED
INITIALIZE 1), OPEN_REJECT 
	(RESERVED STOP 0), OPEN_REJECT (RESERVED STOP 1), or an open
connection timeout occurs in 
	response to a connection request, it shall retry the connection
request until: 
	a) the connection is established; 
	b) for SSP target ports, the time indicated by the I_T NEXUS
LOSS TIME field in the Protocol-Specific Port 
	mode page (see 10.2.7.4) expires; or 
	c) the I_T nexus loss timer, if any, expires (see 4.7.1,
8.2.2.1, 10.2.7.4, and 10.4.3.17). 


From keiji_katata at post.pioneer.co.jp  Wed Jan  9 22:49:00 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 10 Jan 2008 15:49:00 +0900
Subject: Posted: 1/9 SWG Meeting Minutes
Message-ID: <mailman.87.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted Meeting Minutes and delivered documents on ftp.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Jan08/SWG
 1-9memo Japanese.doc
 1-9RealTimeStreamSWGminutes.doc
 Pioneer Stream Model-2.doc
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 keiji_katata at post.pioneer.co.jp  Thu Jan 10 00:28:48 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 10 Jan 2008 17:28:48 +0900
Subject: Posted: Agenda Proposal
Message-ID: <mailman.88.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted Agenda Proposal on ftp.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Jan08/Agenda Jan08.doc
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 roweber at IEEE.org  Thu Jan 10 05:33:20 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Thu, 10 Jan 2008 07:33:20 -0600
Subject: 08-037 -- SA Creation corrections and clarifications
Message-ID: <mailman.89.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
I have uploaded a proposal containing 'improvements' to the
SA Creation proposal now being incorporated in SPC-4 r12
(07-437r4).
Did you seriously believe the first try would be perfect?
Please see http://www.t10.org/ftp/t10/document.08/08-037r0.pdf
for all the unsavory details.
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 Harvey.Newman at infineon.com  Thu Jan 10 12:47:28 2008
From: Harvey.Newman at infineon.com (Harvey.Newman at infineon.com)
Date: Thu, 10 Jan 2008 21:47:28 +0100
Subject: StatEye 5.0.0 
Message-ID: <mailman.90.1441607335.22514.t10@sandbox.t10.org>

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

Hi Phy group,
The StatEye 5.0.0 code is now available.
Please download from http://www.stateye.org.  Click on Stateye development
forum <http://www.stateye.org/developmentForum/doku.php&gt;  and then Recent
Changes.  Select 5.0.0 at the top of the list.
Best Regards / Mit freundlichen Gr??en / Cordiali Saluti 
Mr. Harvey Newman
Infineon Technologies North America Corp.
Sr. Staff Engineer
IFNA AIM ADS BDE
Tel: +1 (408) 503-2506
Fax: +1 (408) 503-1506
Cell: +1 (408) 205-8876
harvey.newman at infineon.com
640 N. McCarthy Blvd, MS222
Milpitas, CA 95035, USA
****VISIT US AT: www.infineon.com <http://www.infineon.com/&gt;  *****


From Brad.Goodman at schange.com  Thu Jan 10 12:45:57 2008
From: Brad.Goodman at schange.com (Brad.Goodman at schange.com)
Date: Thu, 10 Jan 2008 15:45:57 -0500
Subject: Route Table Configuration
Message-ID: <mailman.91.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Brad.Goodman at schange.com
*
I have been working on firmware for a chassis expander device, and have 
been doing some integration testing with other manufacturers' devices. 
(Disks, HBAs and Expanders).
I have had several "edge" cases, where things have failed - and in trying 
to determine who was "at-fault" - came to the conclusion that the SES spec 
was too ambiguous to determine who was required to do what - when. These 
cases deal with the routing tables - specifically, the mechanism by which 
they are altered *outside* of a "normal" power-on enumeration.
Case in point:
A bunch of disks are runnig off of an expander, 2 expanders down from an 
HBA.
HBA->ExpA->ExpB->Disks
 The expander to which the disks are immediately connected [ExpB] is 
disconnected from ExpA, and connected to a different *port* pm ExpA. I 
have seen several different pieces of equipment react completley 
differently to such a case:
- Some will reprogram every index of every port of every device - This 
appears as though it is probibly correct
- Some will only *add* the new entries to ExpA and ExpB. 
- Some will only reprogram the indexes of the newly-connected port on 
ExpA, and ones downtstream on ExpB.
Intuitivley, the last two don't seem so bad -  however, seeing as how the 
Route entries for the *old* port on ExpA have not been *cleared* - 
problems arise on some devices. After running into this, I thought maybe I 
should erase all my own local tables (in my expander) after BROADCAST 
(CHANGE) , seeing as how the domain would have to be re-discovered anyway. 
Right? Well, no:
Some devices, after a BROADCAST (CHANGE) would just to a REPORT GENERAL 
and a DISCOVER - and if it did not notice anything different under a given 
phy, would not re-program the route table.
So I think the real solution needs to be a clarification in the 
specification to say when these tables must be updated - and to what 
extent, and by who. My gut reaction is to say "All Entries in All Tables" 
shall be updated in response to any/all  "BROADCAST (CHANGE)" events, by 
any initiator that would normally do a discovery. And furthermore, I 
beleive (but am not sure) that upon recieving a BROADCAST (CHANGE) , any 
expander could invalidate all their tables, as they may be bad anyway, and 
shall be be re-programmed anyway.
I may not have it all 100%, but I think thats enough of a brain-dump so 
they you might know what I'm talking about...
Thanks,
Brad Goodman
SeaChange International
bgoodman at schange.com
*
* 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  Thu Jan 10 16:10:43 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Thu, 10 Jan 2008 18:10:43 -0600
Subject: 08-037 -- SA Creation corrections and clarifications
Message-ID: <mailman.92.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Several embarrassing gaffes have been reported in the original
upload of 08-037r0. Rather than leave these around for history
to see, I have overwritten the document with a much improved
version. The name is still the same:
http://www.t10.org/ftp/t10/document.08/08-037r0.pdf
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 jgeldman at lexar.com  Thu Jan 10 17:47:44 2008
From: jgeldman at lexar.com (jgeldman at lexar.com)
Date: Thu, 10 Jan 2008 17:47:44 -0800
Subject: 08-057r0 Allocation length advisories in Inquiry command (spc4r11) posted
Message-ID: <mailman.93.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <jgeldman at lexar.com>
*
A proposal on the Allocation length advisories has been posted.
Regards,
John Geldman
Lexar Media
47300 Bayside Parkway
Fremont, CA 94538
P: 510 580-8715
C: 510 449-3597
** Micron/Lexar Confidential **
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From cphill at altaeng.com  Fri Jan 11 08:00:48 2008
From: cphill at altaeng.com (Chuck Hill)
Date: Fri, 11 Jan 2008 09:00:48 -0700
Subject: Comment on 08-032r2, SSC Profile definition
Message-ID: <mailman.94.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Chuck Hill <cphill at altaeng.com>
*
All,
08-032r2 proposes the following language in section 5.3.8.1: "The slope 
of the frequency deviation shall not exceed 1200 ppm/?s when averaged 
over any 0.3?s (?0.01 ?s) window of the SSC modulation profile."  This 
is confusing and imprecise. 
The input waveform (the SSC profile) is a time waveform with value 
corresponding to frequency and units of ppm.  Call this waveform f(t).	
The slope is computed by f(t)-f(t-tau) / K  where K is a constant 
factor, the separation in time (for SAS K=0.3uS).  This is a simple 
difference equation applied to the waveform that is not a low pass 
filter.  An averaging process is of the form: Integral from t to t-tau 
of f(t) and has a strictly falling response as frequency increases, a 
low pass filter. 
The language of 08-032r2 leads the reader to believe the slope of the 
frequency deviation is averaged, thus low pass filtered, and that is not 
the intention.	It also does not precisely define the required 
computation as there is a time separation tau, as well as a scaling 
factor K.
I offer an alternative text to replace the previously mentioned 
sentence:  "The slope of the frequency deviation shall not exceed 1200 
ppm/?s when computed over any 0.3?s (?0.01 ?s) interval of the SSC 
modulation profile.  The slope is computed from the difference equation 
f(t)-f(t-0.3uS) / 0.3uS where f(t) is the SSC profile expressed in ppm."
Regards,
Chuck
*
* 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  Fri Jan 11 10:33:54 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Fri, 11 Jan 2008 12:33:54 -0600
Subject: Omission of RBC READ CAPACITY command in SPC4r11
Message-ID: <mailman.95.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Dear Mr. Wilcox,
You can expect to see this corrected in SPC-4 r12.
All the best,
.Ralph
Matthew Wilcox wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Matthew Wilcox <matthew at wil.cx>
> *
>
> In table C.2 (part 2 of 6) on page 475, the READ CAPACITY command
> (opcode 25h) is not listed as being mandatory for RBC devices.
> I believe this to be an omission based on section 5.3 of the rbc-r10a
> PDF.	Could this be corrected?
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Guillaume_Fortin at pmc-sierra.com  Fri Jan 11 10:50:22 2008
From: Guillaume_Fortin at pmc-sierra.com (Guillaume Fortin (Montreal))
Date: Fri, 11 Jan 2008 10:50:22 -0800
Subject: Comment on 08-032r2, SSC Profile definition
Message-ID: <mailman.96.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Guillaume Fortin (Montreal)" <Guillaume_Fortin at pmc-sierra.com>
*
I agree that your alternative text is clearer.
As a note, the original text was intended to refer to the averaging the slope
(df(t)/dt), which would be of the form: integral from t-tau to t of df(t)/dt
divided by tau. This is mathematically equivalent to the simpler
(f(t)-f(tau))/tau that you propose.
I will publish and r3 with your changes later today.
Regards,
Guillaume
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Chuck Hill
Sent: Friday, January 11, 2008 11:01 AM
To: t10 at t10.org
Subject: Comment on 08-032r2, SSC Profile definition
* From the T10 Reflector (t10 at t10.org), posted by:
* Chuck Hill <cphill at altaeng.com>
*
All,
08-032r2 proposes the following language in section 5.3.8.1: "The slope of
the frequency deviation shall not exceed 1200 ppm/?s when averaged over any
0.3?s (?0.01 ?s) window of the SSC modulation profile."  This is confusing
and imprecise. 
The input waveform (the SSC profile) is a time waveform with value
corresponding to frequency and units of ppm.  Call this waveform f(t).	
The slope is computed by f(t)-f(t-tau) / K  where K is a constant factor, the
separation in time (for SAS K=0.3uS).  This is a simple difference equation
applied to the waveform that is not a low pass filter.	An averaging process
is of the form: Integral from t to t-tau of f(t) and has a strictly falling
response as frequency increases, a low pass filter. 
The language of 08-032r2 leads the reader to believe the slope of the
frequency deviation is averaged, thus low pass filtered, and that is not the
intention.  It also does not precisely define the required computation as
there is a time separation tau, as well as a scaling factor K.
I offer an alternative text to replace the previously mentioned
sentence:  "The slope of the frequency deviation shall not exceed 1200 ppm/?s
when computed over any 0.3?s (?0.01 ?s) interval of the SSC modulation
profile.  The slope is computed from the difference equation
f(t)-f(t-0.3uS) / 0.3uS where f(t) is the SSC profile expressed in ppm."
Regards,
Chuck
*
* 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 curtis.stevens at wdc.com  Fri Jan 11 10:45:40 2008
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Fri, 11 Jan 2008 10:45:40 -0800
Subject: Next Week's Meeting
Message-ID: <mailman.97.1441607335.22514.t10@sandbox.t10.org>

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

Many of you are coming to Southern California for the T10 meeting next week.
I just wanted to make sure that your are aware that we are having really bad
weather forecast for next week.  The days are all forecaste to have a high
of 65-70F., so bring your jackets.  We are also forecasting lows around 45F,
so if you wish to go out in the evening, bring something heavy to wear.
Fortunately, there is no rain to compound the bad weather.  Please come
prepared.  If you have decided that based on this terrible weather you do
not wish to go outside during your stay, feel free to use the indoor heated
pool provided by the hotel.
-------------------------------------------------
Curtis E. Stevens
20511 Lake Forest Drive #C-214D
Lake Forest, California 92630
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com  


From roweber at IEEE.org  Fri Jan 11 21:35:36 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Fri, 11 Jan 2008 23:35:36 -0600
Subject: 08-034r1 -- Error history cleanup
Message-ID: <mailman.98.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
I received comments on the error history cleanup proposal
|from Rob Elliott and Kevin Butt. Those comments which I
feel competent to defend are included in r1:
http://www.t10.org/ftp/t10/document.08/08-034r1.pdf
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 roweber at ieee.org  Fri Jan 11 20:19:36 2008
From: roweber at ieee.org (Ralph Weber)
Date: Fri, 11 Jan 2008 22:19:36 -0600
Subject: SPC-4 r12 is available
Message-ID: <mailman.99.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
SPC-4 r12 is available as:
http://www.t10.org/ftp/t10/drafts/spc4/spc4r12.pdf
The only proposal not incorporated is 07-295r1.
The web site which SPC-4 is expected to reference does
not even mention standards work.
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 lohmeyer at t10.org  Sat Jan 12 23:00:41 2008
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 13 Jan 2008 00:00:41 -0700
Subject: Recent T10 documents uploaded since 2008/01/06
Message-ID: <mailman.100.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
Proposed Cable Tables for SAS2 6Gbs Phy
(by: Greg McSorley)
T10/07-471r1   Uploaded: 2008/01/09   100250 bytes
ftp://ftp.t10.org/t10/document.07/07-471r1.pdf
Proposed Cable Tables for SAS-2
(by: Greg McSorley)
T10/07-471r2   Uploaded: 2008/01/11   76483 bytes
ftp://ftp.t10.org/t10/document.07/07-471r2.pdf
SAS-2 Interconnect Signal-to-Noise Ratio Study
(by: Barry Olawsky)
T10/07-484r1   Uploaded: 2008/01/11   518096 bytes
ftp://ftp.t10.org/t10/document.07/07-484r1.pdf
SPC-4: Group Persistent Reservations - Presentation
(by: Kevin Butt)
T10/08-024r2   Uploaded: 2008/01/07   150630 bytes
ftp://ftp.t10.org/t10/document.08/08-024r2.pdf
SPC-4: Group Persistent Reservations - Proposal
(by: Kevin Butt)
T10/08-025r1   Uploaded: 2008/01/07   372404 bytes
ftp://ftp.t10.org/t10/document.08/08-025r1.pdf
Proposed modifications to SSC profile definition
(by: Guillaume Fortin)
T10/08-032r1   Uploaded: 2008/01/08   36864 bytes
ftp://ftp.t10.org/t10/document.08/08-032r1.doc
Proposed modifications to SSC profile definition
(by: Guillaume Fortin)
T10/08-032r1   Uploaded: 2008/01/08   8413 bytes
ftp://ftp.t10.org/t10/document.08/08-032r1.pdf
Proposed modifications to SSC profile definition
(by: Guillaume Fortin)
T10/08-032r2   Uploaded: 2008/01/10   37888 bytes
ftp://ftp.t10.org/t10/document.08/08-032r2.doc
Proposed modifications to SSC profile definition
(by: Guillaume Fortin)
T10/08-032r2   Uploaded: 2008/01/10   8747 bytes
ftp://ftp.t10.org/t10/document.08/08-032r2.pdf
Proposed modifications to SSC profile definition
(by: Guillaume Fortin)
T10/08-032r3   Uploaded: 2008/01/11   38400 bytes
ftp://ftp.t10.org/t10/document.08/08-032r3.doc
Proposed modifications to SSC profile definition
(by: Guillaume Fortin)
T10/08-032r3   Uploaded: 2008/01/11   8968 bytes
ftp://ftp.t10.org/t10/document.08/08-032r3.pdf
Error history cleanup
(by: Ralph O. Weber)
T10/08-034r1   Uploaded: 2008/01/11   60192 bytes
ftp://ftp.t10.org/t10/document.08/08-034r1.pdf
SA Creation corrections and clarifications
(by: Ralph O. Weber)
T10/08-037r0   Uploaded: 2008/01/10   87666 bytes
ftp://ftp.t10.org/t10/document.08/08-037r0.pdf
SMC3-New Tape Alert flags
(by: Noud Snelder)
T10/08-047r0   Uploaded: 2008/01/08   16338 bytes
ftp://ftp.t10.org/t10/document.08/08-047r0.pdf
Minutes: Group Reservations Call 7Jan2008
(by: Kevin Butt)
T10/08-051r0   Uploaded: 2008/01/07   19475 bytes
ftp://ftp.t10.org/t10/document.08/08-051r0.pdf
Proposal for SAS 2.x Specification to Enable Support for Active Cables
(by: Gourgen Oganessyan)
T10/08-052r0   Uploaded: 2008/01/08   24683 bytes
ftp://ftp.t10.org/t10/document.08/08-052r0.pdf
SPC-4: Persistent reservation fixes
(by: Gerald Houlder)
T10/08-053r0   Uploaded: 2008/01/08   39075 bytes
ftp://ftp.t10.org/t10/document.08/08-053r0.pdf
Project Proposal: ADT-3
(by: Paul Suhler)
T10/08-054r0   Uploaded: 2008/01/09   17993 bytes
ftp://ftp.t10.org/t10/document.08/08-054r0.pdf
Allocation length advisories in Inquiry command (SPC4r11)
(by: John Geldman)
T10/08-057r0   Uploaded: 2008/01/10   73678 bytes
ftp://ftp.t10.org/t10/document.08/08-057r0.pdf
INCITS Executive Board Request for Confirmation of Liaisons
(by: Lynn Barra)
T10/08-058r0   Uploaded: 2008/01/10   19486 bytes
ftp://ftp.t10.org/t10/document.08/08-058r0.htm
INCITS Executive Board Request for Confirmation of Liaisons
(by: Lynn Barra)
T10/08-058r0   Uploaded: 2008/01/10   87625 bytes
ftp://ftp.t10.org/t10/document.08/08-058r0.pdf
Revisiting Extended Copy
(by: Roger Cummings)
T10/08-063r0   Uploaded: 2008/01/11   25440 bytes
ftp://ftp.t10.org/t10/document.08/08-063r0.pdf
Working Drafts
--------------
SCSI Primary Commands - 4 (SPC-4)
(Editor: Ralph Weber)
 Rev: 12       Uploaded: 2008/01/11   6592453 bytes
ftp://ftp.t10.org/t10/drafts/spc4/spc4r12.pdf
(Report generated on 2008/01/13 at 00:00:41)
*
* 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  Mon Jan 14 10:49:30 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Mon, 14 Jan 2008 12:49:30 -0600
Subject: 08-037r1 -- SA Creation corrections and clarifications
Message-ID: <mailman.101.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
A new revision of the SA Creation corrections and clarifications
proposal has been uploaded as:
http://www.t10.org/ftp/t10/document.08/08-037r1.pdf
I wish I could promise that no additional revisions will be
uploaded before CAP consideration, but the bugs are still
crawling out of the woodwork. Feel free to make your own
contributions to the r2 ASAP.
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 dpeterso at brocade.com  Mon Jan 14 12:20:56 2008
From: dpeterso at brocade.com (David Peterson)
Date: Mon, 14 Jan 2008 13:20:56 -0700
Subject: SSC-3: Rev 03f now available
Message-ID: <mailman.102.1441607335.22514.t10@sandbox.t10.org>

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

http://www.t10.org/ftp/t10/drafts/ssc3/ssc3r03f.pdf
...Dave


From lohmeyer at t10.org  Tue Jan 15 15:40:22 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 15 Jan 2008 16:40:22 -0700
Subject: SAT-2 WG minutes posted
Message-ID: <mailman.103.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft SAT-2 working group minutes are available at:
   http://www.t10.org/ftp/t10/document.08/08-060r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI 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 kdbutt at us.ibm.com  Tue Jan 15 15:43:19 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Tue, 15 Jan 2008 16:43:19 -0700
Subject: Action Items from yesterdays ADI meeting
Message-ID: <mailman.104.1441607335.22514.t10@sandbox.t10.org>

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

Georg,
Thanks.  I have copied the reflector so all can see your response.
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/ 
Georg Boasson <Georg.Boasson at tandbergstorage.com> 
01/15/2008 11:56 AM
To
Kevin D Butt/Tucson/IBM at IBMUS
cc
Subject
Action Items from yesterdays ADI meeting
Hello Kevin
Here is answer for our Action Item from yesterday?s ADI meeting:
Sorry for the delay. Are you the right person for this answeer?
Georg Boasson
To Action Item on Tape Alert flag 19h.
I have checked with Tandberg Data here in Oslo and they do not implement 
this flag in their libraries or loaders.
At least not in the libraries developed here in Norway. What they do in 
the libraries from Exabyte, now Tandberg Data
I do not know.
Our opinion here at Tandberg Storage is that this flag is some kind of 
bucket where you put all cases that does not fit anywhere else.
We generally do not like unspecified TA flags like this. We should either 
remove it or make clear that this is a flag that can be used to indicate 
that 
The library has an unspecified problem. The action should probably be 
something like that ?If the problem persist, call a service 
representative?.
Unless someone comes up with a more specific use for this flag, I would 
probably vote for the removal solution.
Halvard Eriksen
Tandberg Storage


From lohmeyer at t10.org  Tue Jan 15 17:54:39 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 15 Jan 2008 18:54:39 -0700
Subject: SAS-2 Protocol WG minutes posted
Message-ID: <mailman.105.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft SAS-2 Protocol working group minutes are available at:
  http://www.t10.org/ftp/t10/document.08/08-059r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI 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 roweber at IEEE.org  Tue Jan 15 20:39:28 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Tue, 15 Jan 2008 22:39:28 -0600
Subject: 08-037r2 -- SA Creation corrections and clarifications
Message-ID: <mailman.106.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
The revision of the SA Creation corrections and clarifications proposal
that David and I want reviewed by CAP is now available as:
http://www.t10.org/ftp/t10/document.08/08-037r2.pdf
Hopefully, we can put this very SCSI episode in our rearview mirrors
this week.
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 Frederick.Knight at netapp.com  Tue Jan 15 21:12:05 2008
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Wed, 16 Jan 2008 00:12:05 -0500
Subject: March T10 Meeting
Message-ID: <mailman.107.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
The announcement for the March T10 meeting has been
updated to include the www reservation information.
The updated document can be found here:
http://www.t10.org/ftp/t10/announce/ann-m084.pdf
So make your plans to join us in Raleigh, NC.
	Fred Knight
*
* 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  Tue Jan 15 22:53:22 2008
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Wed, 16 Jan 2008 00:53:22 -0600
Subject: SAS PHY WG minutes posted
Message-ID: <mailman.108.1441607335.22514.t10@sandbox.t10.org>

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

The SAS PHY WG minutes are posted at:
 http://www.t10.org/ftp/t10/document.08/08-072r0.pdf
Alvin Cox
Seagate Technology, LLC
Office 405-381-8067
Cell 405-206-4809


From roweber at ieee.org  Wed Jan 16 05:58:12 2008
From: roweber at ieee.org (Ralph Weber)
Date: Wed, 16 Jan 2008 07:58:12 -0600
Subject: 07-169r6 -- ESP-SCSI for Parameter Data
Message-ID: <mailman.109.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
The latest revision of the ESP-SCSI proposal is now
available at:
http://www.t10.org/ftp/t10/document.07/07-169r6.pdf
See you all in CAP,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Rrose at tandbergdata.com  Wed Jan 16 09:08:02 2008
From: Rrose at tandbergdata.com (Rose, Roger)
Date: Wed, 16 Jan 2008 10:08:02 -0700
Subject: Action Items from yesterdays ADI meeting
Message-ID: <mailman.110.1441607335.22514.t10@sandbox.t10.org>

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

Kevin & Georg,
I didn't see the original request, so I'm not sure which Tape Alert flag
19h you're referring to or the exact question.	Regardless, none of the
current Tandberg Data US-designed products set this flag.  (Georg has
already received a response for our Oslo-designed products.)
My best guess at the intended usages:
    SMC-2 Tape Alert 19h - Operation invalid at this time.  Probably
used to indicate operations that are currently not possible (e.g. move
medium involving an open I/E Port)
    SSC-2 Tape Alert 19h - Redundant interface port has failed.  Only
applies to multi-ported drives.  (e.g. FibreChannel GBIC failure)
    ADC Tape Alert 19h - Dual port interface error.  The meaning is
probably a reflection of the SSC-2 redundant port failure.  Under ADT &
ADT-2, I suspect this can only apply to non-bridged libraries or
libraries bridged through a multi-port drive.  (Odd that it's
arbitrarily limited to dual-port in ADC.)
-roger rose   { rrose at tandbergdata.com
<blocked::mailto:rrose at tandbergdata.com>  } 
Product Test, Tandberg Data 
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: Tuesday, January 15, 2008 4:43 PM
To: Georg Boasson
Cc: t10 at t10.org
Subject: Re: Action Items from yesterdays ADI meeting
Georg, 
Thanks.  I have copied the reflector so all can see your response. 
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/ 
Georg Boasson <Georg.Boasson at tandbergstorage.com> 
01/15/2008 11:56 AM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
Subject
Action Items from yesterdays ADI meeting
Hello Kevin 
Here is answer for our Action Item from yesterday's ADI meeting: 
Sorry for the delay. Are you the right person for this answeer? 
Georg Boasson 
To Action Item on Tape Alert flag 19h. 
I have checked with Tandberg Data here in Oslo and they do not implement
this flag in their libraries or loaders. 
At least not in the libraries developed here in Norway. What they do in
the libraries from Exabyte, now Tandberg Data 
I do not know. 
Our opinion here at Tandberg Storage is that this flag is some kind of
bucket where you put all cases that does not fit anywhere else. 
We generally do not like unspecified TA flags like this. We should
either remove it or make clear that this is a flag that can be used to
indicate that 
The library has an unspecified problem. The action should probably be
something like that "If the problem persist, call a service
representative". 
Unless someone comes up with a more specific use for this flag, I would
probably vote for the removal solution. 
Halvard Eriksen 
Tandberg Storage 


From roweber at ieee.org  Thu Jan 17 03:30:16 2008
From: roweber at ieee.org (Ralph Weber)
Date: Thu, 17 Jan 2008 05:30:16 -0600
Subject: 08-034r2 -- Error history cleanup {CAP recommended}
Message-ID: <mailman.111.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
The revision of 08-034 containing the CAP recommended
changes is available as:
http://www.t10.org/ftp/t10/document.08/08-034r2.pdf
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 roweber at ieee.org  Thu Jan 17 04:14:03 2008
From: roweber at ieee.org (Ralph Weber)
Date: Thu, 17 Jan 2008 06:14:03 -0600
Subject: 07-169r7 -- ESP-SCSI for Parameter Data {CAP recommended}
Message-ID: <mailman.112.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
The ESP-SCSI proposal that contains the CAP recommended changes
is available as:
http://www.t10.org/ftp/t10/document.07/07-169r7.pdf
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 roweber at ieee.org  Thu Jan 17 05:11:52 2008
From: roweber at ieee.org (Ralph Weber)
Date: Thu, 17 Jan 2008 07:11:52 -0600
Subject: 08-037r3 -- SA Creation corrections and clarifications {CAP recommended}
Message-ID: <mailman.113.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
The revision of the SA creations fixes proposal that contains
the CAP recommended changes is available as:
http://www.t10.org/ftp/t10/document.08/08-037r3.pdf
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 lohmeyer at t10.org  Thu Jan 17 19:00:03 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Thu, 17 Jan 2008 20:00:03 -0700
Subject: CAP WG minutes posted
Message-ID: <mailman.114.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft CAP working group minutes are available at:
   http://www.t10.org/ftp/t10/document.08/08-061r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI 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 Quicksall_SCSI at Bellsouth.net  Fri Jan 18 10:17:40 2008
From: Quicksall_SCSI at Bellsouth.net (Eddy Quicksall)
Date: Fri, 18 Jan 2008 13:17:40 -0500
Subject: invalid task attribute
Message-ID: <mailman.115.1441607335.22514.t10@sandbox.t10.org>

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

What should a target do if the task attribute is invalid?


From Quicksall_SCSI at Bellsouth.net  Fri Jan 18 10:24:35 2008
From: Quicksall_SCSI at Bellsouth.net (Eddy Quicksall)
Date: Fri, 18 Jan 2008 13:24:35 -0500
Subject: invalid task attribute
Message-ID: <mailman.116.1441607335.22514.t10@sandbox.t10.org>

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

Never mind. I didn't notice paragraph 5.8.5.
  ----- Original Message ----- 
  From: Eddy Quicksall 
  To: t10 at t10.org 
  Sent: Friday, January 18, 2008 1:17 PM
  Subject: invalid task attribute
  What should a target do if the task attribute is invalid?


From lohmeyer at t10.org  Sat Jan 19 23:00:41 2008
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 20 Jan 2008 00:00:41 -0700
Subject: Recent T10 documents uploaded since 2008/01/13
Message-ID: <mailman.117.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SMC-3 New Additional Sense Codes Usage
(by: Rod Wideman)
T10/07-018r2   Uploaded: 2008/01/15   112857 bytes
ftp://ftp.t10.org/t10/document.07/07-018r2.pdf
ESP-SCSI for Parameter Data
(by: Ralph O. Weber)
T10/07-169r6   Uploaded: 2008/01/16   106396 bytes
ftp://ftp.t10.org/t10/document.07/07-169r6.pdf
ESP-SCSI for Parameter Data
(by: Ralph O. Weber)
T10/07-169r7   Uploaded: 2008/01/17   108916 bytes
ftp://ftp.t10.org/t10/document.07/07-169r7.pdf
SAT-2: Translation of zero-length security commands
(by: Mark A Overby)
T10/07-325r1   Uploaded: 2008/01/15   57620 bytes
ftp://ftp.t10.org/t10/document.07/07-325r1.pdf
SAS-2 6Gbps PHY specification
(by: Alvin Cox)
T10/07-339r9   Uploaded: 2008/01/15   1474704 bytes
ftp://ftp.t10.org/t10/document.07/07-339r9.pdf
SAS-2: Limiting SAS Target response to OPEN_REJECT (RETRY)
(by: George O. Penokie)
T10/07-391r3   Uploaded: 2008/01/15   203442 bytes
ftp://ftp.t10.org/t10/document.07/07-391r3.pdf
SAS-2: Indeterminate response length to a SMP REPORT GENERAL function
(by: George O. Penokie)
T10/07-397r3   Uploaded: 2008/01/15   195316 bytes
ftp://ftp.t10.org/t10/document.07/07-397r3.pdf
SAS-2 Add SMP Report General Open Response While Configuring
(by: Brad Besmer)
T10/07-403r2   Uploaded: 2008/01/14   97169 bytes
ftp://ftp.t10.org/t10/document.07/07-403r2.pdf
SAM-4 SPC-4 SBC-3 Unit attention condition queuing
(by: Rob Elliott)
T10/07-459r3   Uploaded: 2008/01/16   186907 bytes
ftp://ftp.t10.org/t10/document.07/07-459r3.pdf
SAM-4 SPC-4 SBC-3 Unit attention condition queuing
(by: Rob Elliott)
T10/07-459r4   Uploaded: 2008/01/17   187094 bytes
ftp://ftp.t10.org/t10/document.07/07-459r4.pdf
Proposed Cable Tables for SAS-2
(by: Greg McSorley)
T10/07-471r3   Uploaded: 2008/01/15   51671 bytes
ftp://ftp.t10.org/t10/document.07/07-471r3.pdf
SAS-2 Phy test pattern transmitter controls
(by: Rob Elliott)
T10/07-479r2   Uploaded: 2008/01/15   53898 bytes
ftp://ftp.t10.org/t10/document.07/07-479r2.pdf
SAS-2 Interconnect Signal-to-Noise Ratio Study
(by: Barry Olawsky)
T10/07-484r2   Uploaded: 2008/01/17   307416 bytes
ftp://ftp.t10.org/t10/document.07/07-484r2.pdf
SAT-2 Additional power management methods
(by: Frederick Knight)
T10/07-485r1   Uploaded: 2008/01/14   98488 bytes
ftp://ftp.t10.org/t10/document.07/07-485r1.pdf
SAS-2 Receiver Device Physical Testing
(by: Kevin Witt & Mahbubul Bari)
T10/07-486r2   Uploaded: 2008/01/15   82999 bytes
ftp://ftp.t10.org/t10/document.07/07-486r2.pdf
SAS-2 Receiver Device Physical Testing
(by: Kevin Witt & Mahbubul Bari)
T10/07-486r3   Uploaded: 2008/01/15   83578 bytes
ftp://ftp.t10.org/t10/document.07/07-486r3.pdf
SAS-2_Transmit_Waveform_Calibration_for_RX_Testing
(by: Mahbubul Bari and Kevin Witt)
T10/07-492r1   Uploaded: 2008/01/15   1542153 bytes
ftp://ftp.t10.org/t10/document.07/07-492r1.pdf
SAS-2 Elasticity buffer clarifications
(by: Rob Elliott)
T10/08-009r1   Uploaded: 2008/01/15   148510 bytes
ftp://ftp.t10.org/t10/document.08/08-009r1.pdf
SAS-2: SP State Machine - SL State Machine interaction issue
(by: William Martin)
T10/08-010r1   Uploaded: 2008/01/14   32124 bytes
ftp://ftp.t10.org/t10/document.08/08-010r1.pdf
SAS-2: Remove restrictions for SSC
(by: Gerald Houlder, Alvin Cox)
T10/08-014r4   Uploaded: 2008/01/15   38822 bytes
ftp://ftp.t10.org/t10/document.08/08-014r4.pdf
SSC-3 Automation device serial number VPD page
(by: Rod Wideman)
T10/08-022r1   Uploaded: 2008/01/15   137451 bytes
ftp://ftp.t10.org/t10/document.08/08-022r1.pdf
SPC-4: Group Persistent Reservations - Proposal
(by: Kevin Butt)
T10/08-025r2   Uploaded: 2008/01/15   378620 bytes
ftp://ftp.t10.org/t10/document.08/08-025r2.pdf
Proposed modifications to SSC profile definition
(by: Guillaume Fortin)
T10/08-032r4   Uploaded: 2008/01/17   34816 bytes
ftp://ftp.t10.org/t10/document.08/08-032r4.doc
Proposed modifications to SSC profile definition
(by: Guillaume Fortin)
T10/08-032r4   Uploaded: 2008/01/17   9430 bytes
ftp://ftp.t10.org/t10/document.08/08-032r4.pdf
Error history cleanup
(by: Ralph O. Weber)
T10/08-034r2   Uploaded: 2008/01/17   66798 bytes
ftp://ftp.t10.org/t10/document.08/08-034r2.pdf
SA Creation corrections and clarifications
(by: Ralph O. Weber)
T10/08-037r1   Uploaded: 2008/01/14   140623 bytes
ftp://ftp.t10.org/t10/document.08/08-037r1.pdf
SA Creation corrections and clarifications
(by: Ralph O. Weber)
T10/08-037r2   Uploaded: 2008/01/15   142840 bytes
ftp://ftp.t10.org/t10/document.08/08-037r2.pdf
SA Creation corrections and clarifications
(by: Ralph O. Weber)
T10/08-037r3   Uploaded: 2008/01/17   145528 bytes
ftp://ftp.t10.org/t10/document.08/08-037r3.pdf
Use period as decimal separator in T10 standards
(by: Rob Elliott)
T10/08-041r1   Uploaded: 2008/01/16   23625 bytes
ftp://ftp.t10.org/t10/document.08/08-041r1.pdf
Minutes: ADI Meeting 14 January 2008
(by: Michael Banther)
T10/08-042r0   Uploaded: 2008/01/14   24197 bytes
ftp://ftp.t10.org/t10/document.08/08-042r0.pdf
Minutes: ADI Meeting 14 January 2008
(by: Michael Banther)
T10/08-042r1   Uploaded: 2008/01/14   24140 bytes
ftp://ftp.t10.org/t10/document.08/08-042r1.pdf
Minutes: SMC-3 14 January 2008
(by: Kevin Butt)
T10/08-045r0   Uploaded: 2008/01/15   31748 bytes
ftp://ftp.t10.org/t10/document.08/08-045r0.pdf
Minutes: SMC-3 14 January 2008
(by: Kevin Butt)
T10/08-045r1   Uploaded: 2008/01/17   31734 bytes
ftp://ftp.t10.org/t10/document.08/08-045r1.pdf
Minutes: SSC-3 15 January 2008
(by: Kevin Butt)
T10/08-046r0   Uploaded: 2008/01/15   62005 bytes
ftp://ftp.t10.org/t10/document.08/08-046r0.pdf
SPC-4 Power Condition Mode Page
(by: Frederick Knight)
T10/08-050r0   Uploaded: 2008/01/14   29971 bytes
ftp://ftp.t10.org/t10/document.08/08-050r0.pdf
SPC-4 Power Condition Mode Page
(by: Frederick Knight)
T10/08-050r1   Uploaded: 2008/01/15   29722 bytes
ftp://ftp.t10.org/t10/document.08/08-050r1.pdf
SPC-4: Persistent reservation fixes
(by: Gerald Houlder)
T10/08-053r1   Uploaded: 2008/01/16   20393 bytes
ftp://ftp.t10.org/t10/document.08/08-053r1.pdf
T11 Liaison Report, December, 2007
(by: Robert Snively)
T10/08-055r0   Uploaded: 2008/01/14   13282 bytes
ftp://ftp.t10.org/t10/document.08/08-055r0.pdf
Minutes of SAS PHY Working Group conference call January 10, 2008
(by: Alvin Cox)
T10/08-056r0   Uploaded: 2008/01/14   20659 bytes
ftp://ftp.t10.org/t10/document.08/08-056r0.pdf
Minutes of SAS Protocol Working Group - January 14, 2008
(by: Weber & Lohmeyer)
T10/08-059r0   Uploaded: 2008/01/15   46479 bytes
ftp://ftp.t10.org/t10/document.08/08-059r0.htm
Minutes of SAS Protocol Working Group - January 14, 2008
(by: Weber & Lohmeyer)
T10/08-059r0   Uploaded: 2008/01/15   123467 bytes
ftp://ftp.t10.org/t10/document.08/08-059r0.pdf
Minutes of SAT-2 Working Group - January 15, 2008
(by: Lohmeyer & Overby)
T10/08-060r0   Uploaded: 2008/01/15   33979 bytes
ftp://ftp.t10.org/t10/document.08/08-060r0.htm
Minutes of SAT-2 Working Group - January 15, 2008
(by: Lohmeyer & Overby)
T10/08-060r0   Uploaded: 2008/01/15   102427 bytes
ftp://ftp.t10.org/t10/document.08/08-060r0.pdf
Minutes of CAP Working Group - January 16-17, 2008
(by: Weber & Lohmeyer)
T10/08-061r0   Uploaded: 2008/01/17   56917 bytes
ftp://ftp.t10.org/t10/document.08/08-061r0.htm
Minutes of CAP Working Group - January 16-17, 2008
(by: Weber & Lohmeyer)
T10/08-061r0   Uploaded: 2008/01/17   143027 bytes
ftp://ftp.t10.org/t10/document.08/08-061r0.pdf
SAS-2 SPC-4 Differentiate between ACK NAK timeout reasons
(by: Rob Elliott)
T10/08-064r0   Uploaded: 2008/01/14   196940 bytes
ftp://ftp.t10.org/t10/document.08/08-064r0.pdf
MMC Command Descriptions for the Optical Security Subsystem Class
(by: William McFerrin)
T10/08-065r0   Uploaded: 2008/01/13   147386 bytes
ftp://ftp.t10.org/t10/document.08/08-065r0.pdf
SMC-3, Report Element Information
(by: Curtis Ballard)
T10/08-066r0   Uploaded: 2008/01/14   147714 bytes
ftp://ftp.t10.org/t10/document.08/08-066r0.pdf
ADI-2 Working Group Report to Plenary, January 2008
(by: Paul Suhler)
T10/08-067r0   Uploaded: 2008/01/14   11881 bytes
ftp://ftp.t10.org/t10/document.08/08-067r0.pdf
ADI-2 Working Group Report to Plenary, January 2008
(by: Paul Suhler)
T10/08-067r1   Uploaded: 2008/01/16   11859 bytes
ftp://ftp.t10.org/t10/document.08/08-067r1.pdf
FCP-4: Working Group Agenda, January 15, 2008
(by: David Peterson)
T10/08-068r0   Uploaded: 2008/01/16   9191 bytes
ftp://ftp.t10.org/t10/document.08/08-068r0.pdf
SSC-3: Working Group Agenda, January 15, 2008
(by: David Peterson)
T10/08-069r0   Uploaded: 2008/01/16   11001 bytes
ftp://ftp.t10.org/t10/document.08/08-069r0.pdf
Thin Provisioning Concept Proposal
(by: Frederick Knight)
T10/08-070r0   Uploaded: 2008/01/14   100185 bytes
ftp://ftp.t10.org/t10/document.08/08-070r0.pdf
Minutes of FCP-4 Working Group - January 15, 2008
(by: Bob Nixon)
T10/08-071r0   Uploaded: 2008/01/15   19014 bytes
ftp://ftp.t10.org/t10/document.08/08-071r0.pdf
Minutes of SAS Physical Working Group - January 15, 2008
(by: Alvin Cox)
T10/08-072r0   Uploaded: 2008/01/15   29285 bytes
ftp://ftp.t10.org/t10/document.08/08-072r0.pdf
SAS-2 StatEye v5.080111 results
(by: Rob Elliott)
T10/08-073r0   Uploaded: 2008/01/15   18074 bytes
ftp://ftp.t10.org/t10/document.08/08-073r0.pdf
SAS-2 StatEye v5.080111 results
(by: Rob Elliott)
T10/08-073r0   Uploaded: 2008/01/15   1201497 bytes
ftp://ftp.t10.org/t10/document.08/08-073r0.zip
IEEE SISWG P1619 Status Report to T10, Jan 2008
(by: Matthew Ball)
T10/08-074r0   Uploaded: 2008/01/17   33630 bytes
ftp://ftp.t10.org/t10/document.08/08-074r0.pdf
SPC-4, SAT-2, Proposal to add the ATA device password security feature
(by: Curtis Stevens)
T10/08-075r0   Uploaded: 2008/01/15   167436 bytes
ftp://ftp.t10.org/t10/document.08/08-075r0.pdf
SPC-4, SAT-2, Proposal to add the ATA device password security feature
(by: Curtis Stevens)
T10/08-075r1   Uploaded: 2008/01/15   163748 bytes
ftp://ftp.t10.org/t10/document.08/08-075r1.pdf
STA Event (Fujitsu): An Idea for 6G Implementation
(by: Masakazu Kawamoto)
T10/08-076r0   Uploaded: 2008/01/15   441699 bytes
ftp://ftp.t10.org/t10/document.08/08-076r0.pdf
STA Event (HP): Beyond SAS-2
(by: Rob Elliott)
T10/08-077r0   Uploaded: 2008/01/15   1214344 bytes
ftp://ftp.t10.org/t10/document.08/08-077r0.pdf
STA Event (LSI): Improving SAS for future generations
(by: Timothy Hoglund)
T10/08-078r0   Uploaded: 2008/01/15   373548 bytes
ftp://ftp.t10.org/t10/document.08/08-078r0.pdf
STA Event (Quellan): Considerations for Active Copper Cables for SAS-
2 and Beyond
(by: Gourgen Oganessyan)
T10/08-079r0   Uploaded: 2008/01/15   1511567 bytes
ftp://ftp.t10.org/t10/document.08/08-079r0.pdf
STA Event (Molex): Molex Connector Proposals for SAS 2.x
(by: Jay Neer)
T10/08-080r0   Uploaded: 2008/01/15   1711244 bytes
ftp://ftp.t10.org/t10/document.08/08-080r0.pdf
STA Event (Luxtera): QSFP addition to SAS
(by: Tom Palkert)
T10/08-081r0   Uploaded: 2008/01/15   889132 bytes
ftp://ftp.t10.org/t10/document.08/08-081r0.pdf
FCP-4: Status Report, January 17, 2008
(by: David Peterson)
T10/08-082r0   Uploaded: 2008/01/16   15299 bytes
ftp://ftp.t10.org/t10/document.08/08-082r0.pdf
SSC-3: Status Report, January 17, 2008
(by: David Peterson)
T10/08-083r0   Uploaded: 2008/01/16   20752 bytes
ftp://ftp.t10.org/t10/document.08/08-083r0.pdf
SMC-3 January, 2008 Plenary Report
(by: Curtis Ballard)
T10/08-084r0   Uploaded: 2008/01/17   17914 bytes
ftp://ftp.t10.org/t10/document.08/08-084r0.pdf
STA -T10 Liaison Report - January 17, 2008
(by: Marty Czekalski)
T10/08-086r0   Uploaded: 2008/01/17   177854 bytes
ftp://ftp.t10.org/t10/document.08/08-086r0.pdf
T13 Liaison Report January 08
(by: Dan Colegrove)
T10/08-087r0   Uploaded: 2008/01/17   4361 bytes
ftp://ftp.t10.org/t10/document.08/08-087r0.pdf
Working Drafts
--------------
SCSI Stream Commands - 3 (SSC-3)
(Editor: Dave Peterson)
 Rev: 03f      Uploaded: 2008/01/14   2772431 bytes
ftp://ftp.t10.org/t10/drafts/ssc3/ssc3r03f.pdf
SCSI Stream Commands - 3 (SSC-3)
(Editor: Dave Peterson)
 Rev: 04       Uploaded: 2008/01/16   2868255 bytes
ftp://ftp.t10.org/t10/drafts/ssc3/ssc3r04.pdf
(Report generated on 2008/01/20 at 00:00:41)
*
* 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  Sun Jan 20 22:09:30 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Mon, 21 Jan 2008 15:09:30 +0900
Subject: 1/24, 25 Speed Control SWG meeting announcement
Message-ID: <mailman.118.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
Toshiba and Pioneer prepare a meeting room for the SWG. 1/24 is at Toshiba,
1/25
is at Pioneer.
Registration by 2008/1/23 is required for both days.
Agenda: Real-time streaming playback model
Date: 2008/1/24, 25
Time: 10:00AM - 5:00PM
Place at 1/24
Toshiba Headquaters Building (Available from 9:30)
http://www.toshiba.co.jp/worldwide/about/overseas.html
Seven minutes on foot through passage from Hamamatsucho Station,
Yamanote Line or Keihin-Tohoku Line. (JR)
Place at 1/25
1-1, SHIN-OGURA, SAIWAI-KU, KAWASAKI-SHI KANAGAWA 212-0031, JAPAN
TEL: 81-44-580-3211
http://pioneer.jp/corp/profile/map/kawasaki/index-e.html
13 people of the beginning will have free lunch in the building at 1/25.
Best regards,
Keiji Katata
PIONEER CORP.
TEL +81-49-279-2387
*
* 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  Mon Jan 21 01:36:39 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Mon, 21 Jan 2008 18:36:39 +0900
Subject: Posted: Meeting minutes and delivered documents
Message-ID: <mailman.119.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted Meeting minutes and delivered documents.
<ftp.avc-pioneer.com&gt;
/Mtfuji_7/Minutes
 DaftMinJan08.pdf <OK>
 1-9Speed ControlSWGminutes.pdf <OK>
 1-14Speed ControlSWGminutes.pdf <OK>
/Mtfuji_7/Proposal/Jan08
 Mt Fuji proposal StreamingPlayback_20080115.doc
 Pioneer Stream Model-3.doc
Best regards,
Keiji Katata
PIONEER CORP.
TEL +81-49-279-2387
*
* 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 Jan 21 15:41:47 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Mon, 21 Jan 2008 16:41:47 -0700
Subject: T10 Plenary minutes posted
Message-ID: <mailman.120.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft T10 plenary minutes for meeting #083 have been posted at:
  http://www.t10.org/ftp/t10/document.08/08-062r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI 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 keiji_katata at post.pioneer.co.jp  Mon Jan 21 20:54:14 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 22 Jan 2008 13:54:14 +0900
Subject: Posted: December Meeting minutes
Message-ID: <mailman.121.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted December Meeting minutes.
ftp.avc-pioneer.com/Mtfuji_7/Minutes/MinDec07.pdf
Best regards,
Keiji Katata
PIONEER CORP.
TEL +81-49-279-2387
*
* 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 Jan 22 01:20:47 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 22 Jan 2008 18:20:47 +0900
Subject: Remainder: 1/24, 25 Speed Control SWG meeting announcement
Message-ID: <mailman.122.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I received notice from these persons.
Horiuchi    Lenovo
Akahoshi    Hitachi
Mine	    Optiarc
Yamazaki
Tazawa		  HLDS
Kimura		  Toshiba
Please send your notice if you will attend these meeting.
Best regards,
Keiji Katata
PIONEER CORP.
keiji_katata at post.pioneer.co.jp@avc-pioneer.com on 2008/01/21 15:09:30
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 Reflector <t10 at t10.org>
bcc:
$B7oL>(B:  1/24, 25 Speed Control SWG meeting announcement
Hello all,
Toshiba and Pioneer prepare a meeting room for the SWG. 1/24 is at Toshiba,
1/25
is at Pioneer.
Registration by 2008/1/23 is required for both days.
Agenda: Real-time streaming playback model
Date: 2008/1/24, 25
Time: 10:00AM - 5:00PM
Place at 1/24
Toshiba Headquaters Building (Available from 9:30)
http://www.toshiba.co.jp/worldwide/about/overseas.html
Seven minutes on foot through passage from Hamamatsucho Station,
Yamanote Line or Keihin-Tohoku Line. (JR)
Place at 1/25
1-1, SHIN-OGURA, SAIWAI-KU, KAWASAKI-SHI KANAGAWA 212-0031, JAPAN
TEL: 81-44-580-3211
http://pioneer.jp/corp/profile/map/kawasaki/index-e.html
13 people of the beginning will have free lunch in the building at 1/25.
Best regards,
Keiji Katata
PIONEER CORP.
TEL +81-49-279-2387
*
* 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  Tue Jan 22 08:47:14 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Tue, 22 Jan 2008 09:47:14 -0700
Subject: 07-454r5: CbCS posted
Message-ID: <mailman.123.1441607335.22514.t10@sandbox.t10.org>

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

2008/01/22 09:21:13 
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.07/07-454r5.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  Tue Jan 22 13:12:59 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 22 Jan 2008 14:12:59 -0700
Subject: Fwd: Conference Call for USB Attached SCSI
Message-ID: <mailman.124.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
>Subject: Conference Call for USB Attached SCSI
>Date: Tue, 22 Jan 2008 13:10:01 -0800
>From: "Curtis Stevens" <curtis.stevens at wdc.com>
>To: "John Lohmeyer" <lohmeyer at t10.org>
>Cc: "McGowan, Steve" <steve.mcgowan at intel.com>, <rogris at microsoft.com>,
>	 "John Geldman" <jgeldman at lexarmedia.com>,
>	 <martin.r.furuhjelm at seagate.com>,
>	 "Elliott, Robert \(Server Storage\)" <Elliott at hp.com>,
>	 "Avraham Shimor" <Avraham.Shimor at sandisk.com>
>
>John
>
> 
>
>		Please add the following UAS Conference call info to the
event notices.
>
> 
>
>Date: 28-Jan-08
>
>Time: 3pm PST
>
> 
>
>Phone Number: 866-692-3158
>
>Passcode: 3087876
>
> 
>
>Agenda:
>
> 
>
>1.	 Introductions
>
>2.	 Continue discussion on approach to the protocol
>
>3.	 Setup outline for draft standard
>
>4.	 Need for F2F on 7-Feb following the USB Mass Storage meeting.	Could
we do a F2F in the afternoon on 6-Feb?
>
>5.	 Adjourn
>
> 
>
>-------------------------------------------------
>
>Curtis E. Stevens
>
>20511 Lake Forest Drive #C-214D
>
>Lake Forest, California 92630
>
>Phone: 949-672-7933
>
>Cell: 949-307-5050
>
>E-Mail: Curtis.Stevens at WDC.com
>
> 
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI 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 roweber at IEEE.org  Tue Jan 22 20:35:34 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Tue, 22 Jan 2008 22:35:34 -0600
Subject: OSD-2 r03 available
Message-ID: <mailman.125.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
The latest revision of OSD-2, which contains all the approved
proposals the editor could remember, is a available as:
http://www.t10.org/ftp/t10/drafts/osd2/osd2r03.pdf
Please send your comments and corrections to the address
shown above.
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 shunsuke.kimura at toshiba.co.jp  Wed Jan 23 03:13:12 2008
From: shunsuke.kimura at toshiba.co.jp (Shunsuke Kimura)
Date: Wed, 23 Jan 2008 20:13:12 +0900
Subject: Remainder: 1/24, 25 Speed Control SWG meeting announcement
Message-ID: <mailman.126.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Shunsuke Kimura <shunsuke.kimura at toshiba.co.jp>
*
Dear all,
I have not announced the Jan 24th meeting room number yet. 
The room number is 3903(39th floor).
Best regards,
Shunsuke Kimura
Toshiba
keiji_katata at post.pioneer.co.jp $B$5$s$O=q$-$^$7$?(B:
>* From the T10 Reflector (t10 at t10.org), posted by:
>* keiji_katata at post.pioneer.co.jp
>*
>
>Hello all,
>
>I received notice from these persons.
>
>Horiuchi    Lenovo
>Akahoshi    Hitachi
>Mine	     Optiarc
>Yamazaki
>Tazawa 	   HLDS
>Kimura 	   Toshiba
>
>Please send your notice if you will attend these meeting.
>
>Best regards,
>
>Keiji Katata
>PIONEER CORP.
>
>
>
>
>
>keiji_katata at post.pioneer.co.jp@avc-pioneer.com on 2008/01/21 15:09:30
>
>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 Reflector <t10 at t10.org>
>bcc:
>$B7oL>(B:  1/24, 25 Speed Control SWG meeting announcement
>
>
>Hello all,
>
>Toshiba and Pioneer prepare a meeting room for the SWG. 1/24 is at Toshiba,
1/25
>is at Pioneer.
>Registration by 2008/1/23 is required for both days.
>
>
>Agenda: Real-time streaming playback model
>Date: 2008/1/24, 25
>Time: 10:00AM - 5:00PM
>
>Place at 1/24
>Toshiba Headquaters Building (Available from 9:30)
>http://www.toshiba.co.jp/worldwide/about/overseas.html
>Seven minutes on foot through passage from Hamamatsucho Station,
>Yamanote Line or Keihin-Tohoku Line. (JR)
>
>Place at 1/25
>1-1, SHIN-OGURA, SAIWAI-KU, KAWASAKI-SHI KANAGAWA 212-0031, JAPAN
>TEL: 81-44-580-3211
>http://pioneer.jp/corp/profile/map/kawasaki/index-e.html
>13 people of the beginning will have free lunch in the building at 1/25.
>
>Best regards,
>
>Keiji Katata
>PIONEER CORP.
>TEL +81-49-279-2387
>
>
>
>
>
>
>
>
>
>
>
>
>
>*
>* 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 Jan 23 10:02:28 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 23 Jan 2008 11:02:28 -0700
Subject: 08-025r3: Team Reservations uploaded
Message-ID: <mailman.127.1441607335.22514.t10@sandbox.t10.org>

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

I have uploaded the Team Reservation proposal with updated resulting from 
last weeks CAP meeting.
2008/01/23 10:36:14 
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.08/08-025r3.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 richd at serverengines.com  Thu Jan 24 17:32:03 2008
From: richd at serverengines.com (Rich Deglin)
Date: Thu, 24 Jan 2008 17:32:03 -0800
Subject: SMP frame - issue with maximum number of valid data bytes
Message-ID: <mailman.128.1441607335.22514.t10@sandbox.t10.org>

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

SAS 2 (r13) section 9.4.3, I think, clearly shows that a maximum length SMP
RESPONSE frame consists of the following:
1 byte FRAME TYPE
1024 bytes RESPONSE BYTES
3 fill bytes
4 bytes CRC
In my reading of this section, this means that an SMP RESPONSE frame with a
maximum length RESPONSE BYTES field has NO MORE THAN 1025 valid data bytes
plus 3 fill bytes plus 4 CRC bytes = 1032 total bytes. The "header"
mentioned in section 10.4.3.2 is not shown here.
Section 10.4.3.2 conflicts with this. It states that a maximum length SMP
RESPONSE frame consists of the following:
1 byte FRAME TYPE
1 byte FUNCTION
1 byte FUNCTION RESULT
1 byte RESPONSE LENGTH
1024 bytes RESPONSE BYTES
0 fill bytes
4 bytes CRC
In my reading of this section, this means that an SMP RESPONSE frame with a
maximum length RESPONSE BYTES field has EXACTLY 1028 valid data bytes plus 0
fill bytes plus 4 CRC bytes = 1032 total bytes. A 4 byte "header" is
mentioned in the text of this section but is not explicitly defined, which I
would contend is an oversight in the document.
The SMP REQUEST frame descriptions demonstrate the same issue.
Please explain the apparent conflict. If there is a real problem here in the
spec, is a proposal necessary to correct it?
Also note that the same issues exist in the SAS 1.1 spec, but I am guessing
that no problems occurred in practice, due to the fact that the lengths of
the SAS 1.1 defined SMP REQUESTs and RESPONSEs do not get anywhere near the
limits.
_____________________________________________________________________________
______
This message, together with any attachment(s), contains confidential and
proprietary information of
ServerEngines LLC and is intended only for the designated recipient(s) named
above. Any unauthorized
review, printing, retention, copying, disclosure or distribution is strictly
prohibited.  If you are not the
intended recipient of this message, please immediately advise the sender by
reply email message and


From lohmeyer at t10.org  Sat Jan 26 23:00:46 2008
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 27 Jan 2008 00:00:46 -0700
Subject: Recent T10 documents uploaded since 2008/01/20
Message-ID: <mailman.129.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
Capability based Command Security
(by: Kevin Butt & Sivan Tal)
T10/07-454r5   Uploaded: 2008/01/22   376781 bytes
ftp://ftp.t10.org/t10/document.07/07-454r5.pdf
SPC-4: Team Reservation (Proposal)
(by: Kevin Butt)
T10/08-025r3   Uploaded: 2008/01/23   410690 bytes
ftp://ftp.t10.org/t10/document.08/08-025r3.pdf
Automation encryption control
(by: Curtis Ballard)
T10/08-029r1   Uploaded: 2008/01/25   190789 bytes
ftp://ftp.t10.org/t10/document.08/08-029r1.pdf
Minutes of T10 Plenary Meeting #83 - January 17, 2008
(by: Weber & Lohmeyer)
T10/08-062r0   Uploaded: 2008/01/21   144222 bytes
ftp://ftp.t10.org/t10/document.08/08-062r0.htm
Minutes of T10 Plenary Meeting #83 - January 17, 2008
(by: Weber & Lohmeyer)
T10/08-062r0   Uploaded: 2008/01/21   341941 bytes
ftp://ftp.t10.org/t10/document.08/08-062r0.pdf
STA Event (Fujitsu): An Idea for 6G Implementation
(by: Masakazu Kawamoto)
T10/08-076r0   Uploaded: 2008/01/22   489561 bytes
ftp://ftp.t10.org/t10/document.08/08-076r0.pdf
Minutes: MMC WG Meeting Minutes, 16 Jan 2008
(by: William McFerrin)
T10/08-085r0   Uploaded: 2008/01/23   13596 bytes
ftp://ftp.t10.org/t10/document.08/08-085r0.pdf
Agenda for T10 Meeting #84 March 2008
(by: John Lohmeyer)
T10/08-088r0   Uploaded: 2008/01/21   60966 bytes
ftp://ftp.t10.org/t10/document.08/08-088r0.pdf
T10 Project Summary - January 2008
(by: John Lohmeyer)
T10/08-089r0   Uploaded: 2008/01/21   34451 bytes
ftp://ftp.t10.org/t10/document.08/08-089r0.pdf
Jeopardy Letter for March 2008 meeting
(by: John Lohmeyer)
T10/08-090r0   Uploaded: 2008/01/21   89177 bytes
ftp://ftp.t10.org/t10/document.08/08-090r0.pdf
Working Drafts
--------------
Object-Based Storage Devices - 2 (OSD-2)
(Editor: Ralph Weber)
 Rev: 03       Uploaded: 2008/01/22   2703497 bytes
ftp://ftp.t10.org/t10/drafts/osd2/osd2r03.pdf
SCSI Block Commands - 3 (SBC-3)
(Editor: Mark Evans)
 Rev: 13       Uploaded: 2008/01/24   2489949 bytes
ftp://ftp.t10.org/t10/drafts/sbc3/sbc3r13.pdf
(Report generated on 2008/01/27 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 Elliott at hp.com  Sun Jan 27 18:48:11 2008
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Mon, 28 Jan 2008 02:48:11 +0000
Subject: SMP frame - issue with maximum number of valid data bytes
Message-ID: <mailman.130.1441607335.22514.t10@sandbox.t10.org>

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

We don't really use "fill bytes" in SMP, since the request and response
frames are always defined as containing structures that are multiples of 4
bytes.	The only one that does not do so is the ZONED BROADCAST request, but
it already defines a "PAD" field on its own to round up to a multiple of 4
bytes.
Removing the "fill bytes" concept would be a good letter ballot comment on
sas2r14.
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Rich Deglin
Sent: Thursday, January 24, 2008 7:32 PM
To: t10 at t10.org
Subject: SMP frame - issue with maximum number of valid data bytes
SAS 2 (r13) section 9.4.3, I think, clearly shows that a maximum length SMP
RESPONSE frame consists of the following:
1 byte FRAME TYPE
1024 bytes RESPONSE BYTES
3 fill bytes
4 bytes CRC
In my reading of this section, this means that an SMP RESPONSE frame with a
maximum length RESPONSE BYTES field has NO MORE THAN 1025 valid data bytes
plus 3 fill bytes plus 4 CRC bytes = 1032 total bytes. The "header" mentioned
in section 10.4.3.2 is not shown here.
Section 10.4.3.2 conflicts with this. It states that a maximum length SMP
RESPONSE frame consists of the following:
1 byte FRAME TYPE
1 byte FUNCTION
1 byte FUNCTION RESULT
1 byte RESPONSE LENGTH
1024 bytes RESPONSE BYTES
0 fill bytes
4 bytes CRC
In my reading of this section, this means that an SMP RESPONSE frame with a
maximum length RESPONSE BYTES field has EXACTLY 1028 valid data bytes plus 0
fill bytes plus 4 CRC bytes = 1032 total bytes. A 4 byte "header" is
mentioned in the text of this section but is not explicitly defined, which I
would contend is an oversight in the document.
The SMP REQUEST frame descriptions demonstrate the same issue.
Please explain the apparent conflict. If there is a real problem here in the
spec, is a proposal necessary to correct it?
Also note that the same issues exist in the SAS 1.1 spec, but I am guessing
that no problems occurred in practice, due to the fact that the lengths of
the SAS 1.1 defined SMP REQUESTs and RESPONSEs do not get anywhere near the
limits.


From keiji_katata at post.pioneer.co.jp  Mon Jan 28 00:16:19 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Mon, 28 Jan 2008 17:16:19 +0900
Subject: Posted: 1/24,25 SWG Meeting minutes and delivered documents
Message-ID: <mailman.131.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted Meeting minutes and delivered documents.
<ftp.avc-pioneer.com&gt;
/Mtfuji_7/Minutes
 SpeedControlSWG Japanese Memo 20080125.pdf
 1-25Speed ControlSWGminutes.pdf
/Mtfuji_7/Proposal/Jan08/SWG
 Mt Fuji proposal StreamingPlayback_20080124.pdf
Best regards,
Keiji Katata
PIONEER CORP.
TEL +81-49-279-2387
*
* 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  Mon Jan 28 12:23:23 2008
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Mon, 28 Jan 2008 20:23:23 +0000
Subject: ADC-2 Conference call January 30th 8AM PST
Message-ID: <mailman.132.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
*
The ADC-2 working group will host an ad-hoc teleconference on 30 January,
2008 starting at 8:00 AM PST and concluding at 10:00 AM PST.  An agenda will
follow.  Contact details for this teleconference appear below. If you wish to
attend from a country not listed, please contact me.
Toll: 574-941-6128
US Toll Free: 866-370-6095
Conference Code: 8983013
Toll free bridge lines - call bridge line number from a land line then enter
toll free number from above (as shown, no 1 in front) - mobile calls to
bridge lines will not work
Netherlands: 0800-022-5059
Norway: 800-15802
UK: 0800-032-0634
A Virtual Classroom link has been set up at:
https://www.rooms.hp.com/attend/default.aspx?key=EHVU3W4SLP
The virtual classroom software has been updated since the last ADC-2 working
group meeting so you may want to visit the test link to update before the
meeting.
https://www.rooms.hp.com/testsetup
Curtis Ballard
Hewlett Packard
StorageWorks Division
Fort Collins, CO
(970) 898-3013
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From richd at serverengines.com  Mon Jan 28 13:30:42 2008
From: richd at serverengines.com (Rich Deglin)
Date: Mon, 28 Jan 2008 13:30:42 -0800
Subject: SMP frame - issue with maximum number of valid data bytes
Message-ID: <mailman.133.1441607335.22514.t10@sandbox.t10.org>

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

Ah yes, Rob, but which tables are the correct ones, those in section 9 or
those in section 10? Or are you suggesting that both sets of tables be
reworked?
Thanks.
  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Elliott,
Robert (Server Storage)
Sent: Sunday, January 27, 2008 6:48 PM
To: t10 at t10.org
Subject: RE: SMP frame - issue with maximum number of valid data bytes
We don't really use "fill bytes" in SMP, since the request and response
frames are always defined as containing structures that are multiples of 4
bytes.	The only one that does not do so is the ZONED BROADCAST request, but
it already defines a "PAD" field on its own to round up to a multiple of 4
bytes.
Removing the "fill bytes" concept would be a good letter ballot comment on
sas2r14.
-- 
Rob Elliott, elliott at hp.com 
Hewlett-Packard Industry Standard Server Storage Advanced Technology 
  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Rich Deglin
Sent: Thursday, January 24, 2008 7:32 PM
To: t10 at t10.org
Subject: SMP frame - issue with maximum number of valid data bytes
SAS 2 (r13) section 9.4.3, I think, clearly shows that a maximum length SMP
RESPONSE frame consists of the following:
1 byte FRAME TYPE
1024 bytes RESPONSE BYTES
3 fill bytes
4 bytes CRC
In my reading of this section, this means that an SMP RESPONSE frame with a
maximum length RESPONSE BYTES field has NO MORE THAN 1025 valid data bytes
plus 3 fill bytes plus 4 CRC bytes = 1032 total bytes. The "header"
mentioned in section 10.4.3.2 is not shown here.
Section 10.4.3.2 conflicts with this. It states that a maximum length SMP
RESPONSE frame consists of the following:
1 byte FRAME TYPE
1 byte FUNCTION
1 byte FUNCTION RESULT
1 byte RESPONSE LENGTH
1024 bytes RESPONSE BYTES
0 fill bytes
4 bytes CRC
In my reading of this section, this means that an SMP RESPONSE frame with a
maximum length RESPONSE BYTES field has EXACTLY 1028 valid data bytes plus 0
fill bytes plus 4 CRC bytes = 1032 total bytes. A 4 byte "header" is
mentioned in the text of this section but is not explicitly defined, which I
would contend is an oversight in the document.
The SMP REQUEST frame descriptions demonstrate the same issue.
Please explain the apparent conflict. If there is a real problem here in the
spec, is a proposal necessary to correct it?
Also note that the same issues exist in the SAS 1.1 spec, but I am guessing
that no problems occurred in practice, due to the fact that the lengths of
the SAS 1.1 defined SMP REQUESTs and RESPONSEs do not get anywhere near the
limits.
_____________________________________________________________________________
______
This message, together with any attachment(s), contains confidential and
proprietary information of
ServerEngines LLC and is intended only for the designated recipient(s) named
above. Any unauthorized
review, printing, retention, copying, disclosure or distribution is strictly
prohibited.  If you are not the
intended recipient of this message, please immediately advise the sender by
reply email message and


From Elliott at hp.com  Mon Jan 28 16:53:02 2008
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Tue, 29 Jan 2008 00:53:02 +0000
Subject: SAS-2 revision 14 now available
Message-ID: <mailman.134.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
Serial Attached SCSI - 2 (SAS-2) revision 14 (sas2r14) is now available
on http://www.t10.org/drafts.htm and http://www.t10.org/new.htm,
incorporating proposals approved by the January 2008 T10 plenary.
This revision includes the 6 Gbps physical layer specifications.  Alvin
Cox (Seagate) led the physical WG through twenty revisions of the core
6 Gbps proposal, starting with 07-063r0 (2/2007) and ending with
07-339r9 (1/2008).
This version will undergo T10 letter ballot.  Because the letter ballot
will not complete until the end of March, the February and March WG
meetings will be covering post SAS-2 topics.  The May face-to-face WG
meetings will focus on resolving SAS-2 letter ballot comments (bumping
post SAS-2 topics if necessary).
SAS Physical WG:
  Thu 2/14 teleconference (10am-12pm)
  Tue 3/11 face-to-face (full day: 9am-6pm)
  Suggested topics:
  a) StatEye results
  b) interface power management
  c) active cables
  d) 8-wide connectors
SAS Protocol WG:
  Mon 3/10 face-to-face  (half-day only; 9am-1pm)
  Suggested topics:
  a) interface power management
  b) device power management
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
*
* 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  Mon Jan 28 17:13:19 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 29 Jan 2008 10:13:19 +0900
Subject: Reflector cleanup notice
Message-ID: <mailman.135.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
The following people have bounced repeatedly and removed from mtfuji5
reflector:
 Joe.Maciel at am.sony.com
They may get back on the reflector by sending a message to
majordomo at avc-pioneer.com with the following line in the message body:
subscribe mtfuji5
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 Elliott at hp.com  Mon Jan 28 17:18:44 2008
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Tue, 29 Jan 2008 01:18:44 +0000
Subject: SAS-2 letter ballot procedure
Message-ID: <mailman.136.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
Serial Attached SCSI - 2 (SAS-2) revision 14 (sas2r14) is now
undergoing T10 letter ballot, closing Friday 28 March 2008.
The preferred format for letter ballot comments is an Adobe
Acrobat .fdf file.  When you place your vote, email the .fdf
file to lohmeyer at t10.org and elliott at hp.com.
Not a T10 member?
=================
Although joining T10 is encouraged, comments are accepted
|from anyone.  Send them to me and I'll include them in my
own comment set.
Creating an .fdf file
=====================
Historically, only the full version of Adobe Acrobat could
create comments, not Acrobat Reader.  Acrobat 7.0 can create
a .pdf that lets Acrobat Reader 7.0 be used to create comments
as well.  Unfortunately, that format is not readable by earlier
versions of Reader, so it is not the standard released format.
If you want an Acrobat 7.x-formatted version to create
comments with Reader 7.0, send me an email.
Converting .fdf to .txt
=======================
A perl program to generate text versions of Acrobat comments
|from an .fdf file is available on http://www.t10.org/tools.htm.
John Lohmeyer or I will run this for you if needed (the
official letter ballot results file is in .txt format).
Viewing Acrobat comments
========================
The Comments tab on the left leads to a listing of all the
comments (its location differs in different versions of Acrobat).
Comments can be sorted by page, date, author, etc., and filtered,
but those controls tend to cause Acrobat to crash.
Setup
=====
In Edit...Preferences:
- disable "Create new pop-ups aligned to the edge of the document"
- enable "Copy selected text into Highlight, Cross-Out,
    and Underline comment pop-ups"
Comment content
===============
Please don't including the section number and section name in
the comment. That was helpful when the .txt version mattered,
but just adds clutter when working with the .fdf file.
Please don't include page numbers in the comments.
If a comment applies to multiple sections, you can just place
one comment on the first occurrence and include all the other
section numbers in the description.  If it occurs many times
in the document, place it on any (preferably the first)
occurrence and add "Global" to the description rather than
highlight each one.
You don't need to label comments as editorial/technical -
they'll all be addressed.
You don't need to number your comments.
Creating Acrobat comments
=========================
There are several tools with which you can create comments.
1. The highlighting tools
  a) Highlighter tool (yellow)
  b) Cross-Out Text tool (red)
  c) Underline Text tool (green)
These associate a comment with specific words. Acrobat seeds the
comment with the selected text, which you can edit.
Use Highlighter when you're suggesting a change. Format the
comment as:
selected text
s/b   (s/b = should be)
new text
Please don't excerpt 60 words and just change a comma in the
middle - focus on the change.
Use Underline Text if you have overlapping comments; it's an
alternate to the Highlighter tool.
Use Cross-Out Text when you're suggesting deletion. If
the selected text is huge, replace the innards with "..."
If you're trying to select a link (e.g. "(see Table 37)"), select
some text around the link along with the link (if you manage to
comment just the link text itself, then clicking on it will follow
the link rather than open the comment box).
Please don't use the "Text Edits" tools like "Insert Text At Cursor".
2. The drawing markup tools
  a) Rectangle tool
  b) Oval tool
  c) and others
These associate a comment with specific areas on the page.  Use
these to highlight parts of figures or large sections of text.
3. Commenting tools
  a) Note tool (yellow)(Post-It Note)
This creates an arbitrary comment on a page, not associated
with any particular text.
Saving comments
===============
The location of these varies in different Acrobat versions.
Save comments to an .fdf file:
  File/Export/Comments (Acrobat 5)
  Comments/Export Comments/to File (Acrobat 7)
Save the .pdf file with comments:
  File/Save
Not using Acrobat FDF format?
=============================
If you don't have Acrobat and don't obtain the version to add
comments with Reader 7.0, you can provide comments in .txt format.
They must be accompanied by additional text describing where
they apply.
1. Number your company's comments starting with #1.
2. Identify the _PDF_ page number. Acrobat shows page numbers
   like this: "146 (181 of 417)".  Use the number inside the
   parenthesis in comments (e.g., 181).
3. Identify the section number.
4. Identify the figure or table.
5. Identify the paragraph/sentence or row/column to which the
   comment applies.
The text file should look like this:
HP #1
PDF Page 180
7.4.1 CRC Overview
Table 67 - CRC polynomials
Third row
<substance of comment>
HP #2
PDF Page 181
7.4.3 CRC checking
Second paragraph
<substance of comment>
...
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
*
* 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  Mon Jan 28 20:12:53 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 29 Jan 2008 13:12:53 +0900
Subject: Posted: Fuji7 Rev. 0.95
Message-ID: <mailman.137.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
The Rev 0.95 is now ready to review.
ftp.avc-pioneer.com/Mtfuji_7/Spec/
 FUJI7r095_diff.zip
 FUJI7r095_diff.pdf
Best regards,
Keiji Katata
PIONEER CORP.
TEL +81-49-279-2387
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From dpeterso at Brocade.COM  Tue Jan 29 12:16:51 2008
From: dpeterso at Brocade.COM (David Peterson)
Date: Tue, 29 Jan 2008 13:16:51 -0700
Subject: SSC-3: Letter Ballot Comment Database (T10/08-095r0)
Message-ID: <mailman.138.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "David Peterson" <dpeterso at Brocade.COM>
*
To all who submit letter ballot comments against SSC-3 rev 04a please
use 08-095r0.xls as a template to submit the comments.
Thanks...Dave
-----Original Message-----
From: Administrator at scsibbs.co.lsil.com
[mailto:Administrator at scsibbs.co.lsil.com] On Behalf Of T10 Document
Administrator
Sent: Tuesday, January 29, 2008 2:07 PM
To: David Peterson
Subject: Re: Re: T10 Document Number Assigned (T10/08-095r0)
2008/01/29 13:07:19 
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.08/08-095r0.pdf
Non-PDF File(s) that will be posted are:
   08-095r0.xls will be posted as 08-095r0.xls
Normally, the posting/archiving process takes about 30 minutes.
Please contact John Lohmeyer <lohmeyer at t10.org>
should you need further assistance.
david.peterson at brocade.com wrote:
> Date: Tue Jan 29 13:06:35 2008
> From: david.peterson at brocade.com
> To: T10 Document Administrator via web upload <docs at t10.org>
> Subject: Re: T10 Document Number Assigned (T10/08-095r0)
> 
> T10 document upload details:
> 
>   Document Number: T10/08-095r0
>	Upload Code: AC_03805azSkrj2hc2
>     Document_Date: 2008/01/29
>   Document_Author: David Peterson
>    Document_Title: SSC-3: Revision 04a Letter Ballot Comment Database
>    Meeting_Agenda: SSC - SCSI Stream Commands
> Document_Comments: <none>
>      Other_Number: <none>
>	  Post_File: pdf xls
> 
> ## 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\08-095r0.pdf"
> 
> Attachment Converted: "D:\T10\ATTACH\08-095r0.xls"
> 
*
* 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  Wed Jan 30 13:54:39 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 30 Jan 2008 14:54:39 -0700
Subject: T10 Reflector clean up
Message-ID: <mailman.139.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
#
#
#
#
#
#
#
#
#
#
It is time again to clean up the T10 Reflector. The following addresses have
bounced consistently since the last clean up:
Addresses removed:
  Trung.Nghiem at am.sony.com
  dennis.pak at am.sony.com
  jchow at marvell.com
  kevin.maloney at lsi.com
  paul.grun at intel.com
  Mark.Marlett at lsi.com
  emhill at microsoft.com
  Alfred.Missbrenner at quantum.com
  Steve_Messinger at mail.boi.hp.com
  Truong_Nguyen at pmc-sierra.com
  matt.ball at Quantum.com
  harry_yang at adaptec.com
  curtin at vitesse.com
  djohnson at vitesse.com
  jims at vitesse.com
  sbc at vitesse.com
  samb at vitesse.com
  Daniel.Sullivan at Emulex.com
  Alan_Spalding at adaptec.com
  Amr_Wassal at pmc-sierra.com
  narayan at sierralogic.com
  murthy_kompella at sierralogic.com
  kristie_amanna at sierralogic.com
  dowens at cbltech.com
  Sandeep_Kapoor at adaptec.com
  Jean.Xue at Emulex.Com
  rwkembel at adelphia.net
  Lenny.Szubowicz at compaq.com
  Tonya.Comer at compaq.com
  DeTarG at LOUISVILLE.STORTEK.COM
  HarneFP at LOUISVILLE.STORTEK.COM
  stawir at rockice.ib.stortek.com
  sgates at broadcom.com
  kirokiro at icqmail.com
  Anand.Kulkarni at hitachigst.com
These people may re-subscribe (hopefully, with a better address) by sending
an email to majordomo at t10.org with the following line in the message body:
  subscribe t10
Regards,
John
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI 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 James.C.Hatfield at seagate.com  Wed Jan 30 15:21:55 2008
From: James.C.Hatfield at seagate.com (James.C.Hatfield at seagate.com)
Date: Wed, 30 Jan 2008 16:21:55 -0700
Subject: Fw: [T13] T13.org update
Message-ID: <mailman.140.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* James.C.Hatfield at seagate.com
*
Just in case any of you are having problems with T13.org.......
It is down for maintenance. See the attached note from Curtis Stevens.
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....:  720-684-2711
==========================================
----- Forwarded by James C Hatfield/Seagate on 01/30/2008 04:20 PM -----
	     curtis.stevens at wd						   
	     c.com							   
	     Sent by:							To 
	     T-13-Owner at t13.or						   
	     g								cc 
	     No Phone Info						   
	     Available						   Subject 
				       [T13] T13.org update		   
	     01/29/2008 08:56						   
	     PM 							   
	     Please respond to						   
	     curtis.stevens at wd						   
		   c.com						   
We are updating www.t13.org, it is now down and will be back up tomorrow by
noon PST.
-------------------------------------------------
Curtis E. Stevens
20511 Lake Forest Drive #C-214D
Lake Forest, California 92630
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com
*
* 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  Wed Jan 30 15:42:06 2008
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Wed, 30 Jan 2008 23:42:06 +0000
Subject: 08-029r2 Automation Encryption Control as approved for inclusion in
 ADC-3 posted
Message-ID: <mailman.141.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
*
I have posted the final draft of 08-029 for inclusion in ADC-3 at the
following link.
http://www.t10.org/ftp/t10/document.08/08-029r2.pdf
Curtis Ballard
Hewlett Packard
*
* 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  Wed Jan 30 17:44:00 2008
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Thu, 31 Jan 2008 01:44:00 +0000
Subject: SES-2 revision 19b now available
Message-ID: <mailman.142.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
SCSI Enclosure Services - 2 (SES-2) revision 19b (ses2r19b) is now
available on http://www.t10.org/drafts.htm and http://www.t10.org/new.htm,
incorporating resolutions for all comments.
There will be some SAM-4/SES-2 letter ballot comment resolution calls before
the next T10 week, at which resolutions may be contested and new comments
added.	Watch the T10 reflector for notices of the calls.
ses2r19b.pdf is the new working draft incorporating the changes.
	     Change bars reflect changes since ses2r19.
07-512r0.pdf contains the original letter ballot comments.
08-049r1.pdf contains ses2r19 side-by-side with the comments
	     (including resolution status).
	     On some of the pages, Acrobat messed up the pagination such
	     that the comments are on the left and the arrows don't
	     line up, but it's decipherable.
08-049r1.fdf contains just the comments (including resolution status)
	     and can be imported into ses2r19.pdf using full Acrobat.
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From curtis.stevens at wdc.com  Thu Jan 31 10:46:54 2008
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 31 Jan 2008 10:46:54 -0800
Subject: UAS Meeting Call 6-Feb-2008
Message-ID: <mailman.143.1441607335.22514.t10@sandbox.t10.org>

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

UAS Face to Face Meeting Call
When:
6-Feb-2008 1pm-3pm Atlanta Time (EST?)
Where: 
Doubletree Hotel Atlanta Buckhead 
3342 Peachtree Road, N.E. 
Atlanta, GA  30326
-------------------------------------------------
Curtis E. Stevens
20511 Lake Forest Drive #C-214D
Lake Forest, California 92630
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com  


From mikeb at bustrace.com  Thu Jan 31 11:02:36 2008
From: mikeb at bustrace.com (Mike Berhan)
Date: Thu, 31 Jan 2008 11:02:36 -0800
Subject: Read Disc Structure - Format Code FFh - Structure length ambiguity
Message-ID: <mailman.144.1441607335.22514.t10@sandbox.t10.org>

Formatted message: <A HREF="r0801311_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0801311_image001.png">image001.png</A>
Attachment #2: <A HREF="r0801311_image002.png">image002.png</A>

The Read Disc Structure - Format Code FFh CDB (MMC / Mt. Fuji devices)
allows software to retrieve the supported disc structures.  Each structure
list entry is four bytes in length and looks like this:
The "Structure Length" is defined in Mt. Fuji 7 and MMC as:
The Structure Length field shall specify the length of the DISC STRUCTURE
data that is identified by the Format Code.
Each disc structure is preceded by a four byte header.	For example, using
the above "Physical Format Information," a device could return:
Note that offset 0-1 shows 0802h as the "Data Structure Length".  When you
retrieve the length from the capability list (topmost example), the drive
returns 0800h.	The 0802h adds two bytes for the two additional bytes in the
header (typical length scheme used in all the t10 specifications).
Here is the problem.  In the capability list, what exactly is the "Structure
Length?"  I have drives from various vendors that all handle this
differently.  They use one of the following three methods.  Each can argue
that they meet the requirement of The Structure Length field shall specify
the length of the DISC STRUCTURE data that is identified by the Format Code:
1.	 Method #1:  The drive returns the length of the structure not
including any header bytes (as you see in the above example).  For fixed
length structures, this value would be two bytes less than the value that is
returned in the structure header.
2.	 Method #2:  The drive returns the same value as in the structure
header.  In other words, the "Structure Length" equals the "Data Structure
Length".  Technically, this value is two bytes larger than the actual disc
structure (i.e. those two reserved bytes after the Data Structure Length).
3.	 Method #3:  The drive returns the length of the structure INCLUDING
the four byte header.  For fixed length structures, this value would be two
bytes more than what is returned in the structure header.
While I find the specification not clear on this point, I do believe that
Method #1 is the most technically accurate (i.e. not including the header
bytes in the count).
This confusion comes from the specification leaving room for interpretation
on how to handle this (both Mt. Fuji and MMC).	Katata-san, can you clarify
what was intended with the specification and also have the next draft
specification address this issue?  Thank you.
-------
Mike Berhan
busTRACE Technologies
9700 Village Center Drive
Suite 50-F
Granite Bay, CA  95746
916.773.4554 phone
916.218.6283 fax
http://www.bustrace.com