SBP forwarding letter ballot results

[John Lohmeyer]

Attached are the results of the X3T10 letter ballot on forwarding SBP to
X3.  The ballot passed but X3T10 must attempt to resolve the negative
comments.  Tentative resolution was reached last week.  The SBP editor(s)
will be working with the commentors to produce a revision 17 document and
a document describing the comment resolutions.

John

*****************************************************************************

SBP Letter Ballot Results:  50:2:0:7 = 59

Yes, with comment: Apple, Quantum

No:  Digital Equipment, IBM

Did not respond: AMD, Compaq, DPT, Harbor Electronics, Maxtor,
P.E. Logic, Samsung

------------------------------------------------------------------------------
Apple comment:

My comment is that there needs to be a section describing the format of the
isochronous control CDS.  I propose specific text for this section, which will
be forwarded separately to the officers of X3T10 and to the current editors
of SBP.

------------------------------------------------------------------------------
Quantum comment: 

Our comment is that this approval, like our approval of FCP, is given 
reluctantly given the lack of approval of SAM.

------------------------------------------------------------------------------
Digital Equipment comment:

My no vote on forwarding SBP is based on the following comments, which 
identify areas where SBP is not compliant with SAM.

1. Section 6.3, Task Management Services

The task management services in this section do not define the protocol for 
executing the TERMINATE TASK task management function.

According to the last paragraph in section 5 on page 61 of SAM R13:

"All SCSI-3 protocol specifications shall provide the functionality needed 
for a task manager to implement all of the task management functions defined 
above."

2. Section 6.3.6, "Clear Auto Contingent Allegiance", second sentence.

The sentence states:

"It is an error for an Auto Contingent Allegiance CDS to be received at a 
target unless that target is in the state such that an ACA condition is true."

The quoted sentence has the following problems:

1. An ACA is a task set condition, not a target condition.

2. As specified in section 5.3 of SAM, a CLEAR ACA task management function 
is not an error if there is no ACA in effect for the task set.

I will be submitting a more detailed set of comments next week.

------------------------------------------------------------------------------
IBM comment: 

My vote is not to forward SBP because I believe that several
critical characteristics are omitted. The problems which I found
are indicated and changes have been suggested.

Thank you.
********************************************************
Items preceeded by "*" are technical. Others are editorial.

3.2. Define CDS & ATA

*5.2.1. Add a sentence: "In a cooperative multi-initiator environment
in which no initiator is exceeding its tap slot allocation, a target
must never reject a tap."

*6.1.1:
Paragraph 1:
Add the sentence: "A target must always have the ability to receive a
CDS and examine its contents."
(Without this requirement, a target cannot return a status block as
specified because it would not know the status address.)
Also, the fact that the busy/retry protocol may have been carried out
before the tap was received should be clarified by addition of the
following sentence:
"As in any P1394 transaction, the busy/retry protocol may be carried
out before the application responds to the tap."
(The best place to insert these two sentences is after the last
sentence of the paragraph.)
Paragraph 2:
Add the sentence: "In a cooperative multi-initiator
environment in which no initiator is exceeding its tap slot
allocation, a target must never reject a tap."

*6.1.2.Paragraph 2 should be replaced by:
"If the target SBP receives FROM ITS TRANSACTION LAYER anything other
than COMPLETE, then....."
The reason for this is because, as defined in P1394 section 7.1.2.2,
transaction data confirmations go from the transaction layer to the
application layer within a target or an initiator, they do not go from
initiators to targets or vice versa. Also, the words "FROM
ITS TRANSACTION LAYER" are needed to stress the fact
that the busy/retry protocol inside the transaction layer may have
been executed before the COMPLETE response was sent up to the
application layer. As mentioned in comment 6.1.1, this can be
clarified by adding the following sentence at the end of paragraph 2:
"As in any P1394 transaction, the busy/retry protocol may be carried
out before the application responds to the tap."

*6.2.1 As in comment 6.1.2, paragraph 3 should be replaced by:
"If the target SBP receives FROM ITS TRANSACTION LAYER anything other
than COMPLETE, then....."
Please see comment 6.1.2 for the explanation.
Also as mentioned in comment 6.1.1, the fact that the busy/retry
protocol may  have been carried out before the COMPLETE response was
sent to the application layer should again be made clear. This can be
done by adding the following sentence at the end of paragraph 3:
"As in any P1394 transaction, the busy/retry protocol must be carried
out before the COMPLETE response is returned."

Finally, the case in which the target's transaction layer responds
with DATA ERROR should also be included. As specified in section
6.3.5, if the target's transaction layer returns DATA ERROR, then
the target retries the transaction indefinately.

*6.2.2 Paragraph 3. Please refer to comment 6.2.1 above.

*6.3.5. Paragraph 3 and following. The "Deal with ..." phrase seems to
be out of context. This phrase and the all the following paragraphs
should be either be removed from SBP, or completely revised.
Here are some problems with the information.

All the definitions seem to imply that TR_DATA.confirmations go from
an initiator to a target. P1394 section 7.1.2.2 defines them as going
|from a target's (or an initiator's) transaction layer to its
application layer. When this definition is applied, the "TARGET CASE"
and "INITIATOR CASE"  headings are reversed. Also, as mentioned above,
section 6.2.1 needs to be made compatible with these definitions.

*7. Please see comment 6.3.5.

*7.1. Paragraph 3. Please see comment 6.1.1, equivalent revisions are
needed.

*7.3.1. Paragraph 3:
Please refer to comment 6.2.1. As stated, a more appropriate wording
would be:
"If the target SBP receives FROM ITS TRANSACTION LAYER anything other
than COMPLETE with rcode of resp_complete, then....."
(Please refer to comment 6.2.1 for justification.) Also, the text
describing the busy/retry and DATA ERROR cases needs to be included
as in 6.2.1.

*7.3.2. Please refer to comment 7.3.1.

*7.4. Please refer to comment 7.3.1

*8.2.1. Add a sentence: "In a cooperative multi-initiator environment
in which no initiator is exceeding its tap slot allocation, a target
must never reject a tap."

*8.2.2. Add a sentence: "In a cooperative multi-initiator environment
in which no initiator is exceeding its tap slot allocation, a target
must never reject a tap."

*9.1 Table 8
The "Tap slot available" flag is defined here to mean that a tap
slot previously used by the initiator is available for reuse. This
is the correct function of this bit and this function should be made
clear.
(Note also that section 6.1.1 seems to imply that
this flag is used for telling the initiator that the tap slot it
just attempted to use was unavailable. This usage conflicts with the
definition in Table 8.)

*9.1 Table 13
Residue over and underrun field definitions do not indicate what value
is placed in this field. I suggest borrowing the wording in FCP
rev.008a for the definitions.

10.1 Table 14
As in FCP, it would be helpful to refer to SAM for the definition
of the command byte count. Please see SAM R13, section 4.3.1.

*10.1.1 Table 19-20
These fields deal with physical parameters of the underlying transport
medium and should not be put in the SBP ULP command protocol unless
absolutely required. These parameters should be established at
login. If this is done, then the ULP will not need to manage physical
configurations except at login time.

*10.2. The CDS Codes field is not defined in this section.

10.3. Either remove or expand on the words "rkr notes" on p. 27.

10.3 Table 26.
The "Number of Slots" field is not defined properly. I think the
intent is that this field is the REQUESTED number of slots which the
initiator is requesting to be allocated to it.

*11.1.3. Last paragraph seems vague. I think wording such as this
might better express the intent:
"Initiators are not required to limit their use of tap slots to the
number they have been allocated. If all initiators using the
target are cooperating by staying within their allocations, then the
availability of their slots is guaranteed. In all other cases, tap
slot accesses may result in rejections."

Notes:
1. All references to P1394 refer to revision 6.8v1.

2. Please fix Scott Smyers telephone number on the front of the
document. The FAX number is listed twice.

3. It would be useful to add an implementers note somewhere in the
document (perhaps in section 6.1) discussing the setting of RETRY
LIMIT. This should mention 1) that P1394 REQUIRES implementation of at
least one retry for each transaction, 2) that setting the retry limit
too high may result in wasting bus bandwidth on transactions which may
never sucessfully complete anyway, and 3) setting it too low may waste
an application's resources by causing the application to repeatedly
perform retries best done at the lower protocol layers.

-- 
John Lohmeyer                      E-Mail:  John.Lohmeyer at FtCollinsCO.NCR.COM
NCR Microelectronics                Voice:  719-573-3362
1635 Aeroplaza Dr.                    Fax:  719-597-8225
Colo Spgs, CO 80916              SCSI BBS:  719-574-0424 300--14400 baud