Results of T10 letter ballot on forwarding SBP-2

John Lohmeyer John.Lohmeyer at symbios.com
Tue Jan 13 09:54:23 PST 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* John Lohmeyer <John.Lohmeyer at Symbios.com>
*
                                                           T10/98-005 R0
Voting Results on T10 Letter Ballot 97-038r0 on
Forwarding SBP-2 to first public review

Organization                      Name                 S Vote Add'l Info
--------------------------------- -------------------- - ---- ----------
Adaptec, Inc.                     Lawrence J. Lamers   P YesC Cmnts=20
AMP, Inc.                         Charles Brill        P Yes =20
Amphenol Interconnect             Michael Wingard      P Yes =20
Ancot Corp.                       Gary Porter          P Yes =20
Apple Computer                    Harlan Andrews       P Yes =20
Berg Electronics                  Doug Wagner          P Yes =20
Cable Design Technologies         richard wagner       P Yes =20
Ciprico Inc.                      Gerry Johnsen        P Yes =20
Circuit Assembly Corp.            Ian Morrell          P Yes =20
Tandem, a Compaq Company          Pete Tobias          P Yes =20
Congruent Software, Inc.          Peter Johansson      P YesC Cmnts=20
Dallas Semiconductor              Charles Tashbook     P Yes =20
Data General / Clariion           Gary S. Peterson     P Yes =20
Digital Equipment Corp.           Douglas Hagerman     P Yes =20
Diogenes SCSI                     Keith W. Parker      P Yes =20
Distributed Processing Tech.                             DNV =20
Eastman Kodak Co.                 Robert Reisch        P Yes =20
ENDL                              I D Allan            P Yes =20
Exabyte Corp.                     Constance L. Kephart P Yes =20
FSI Consulting Services                                  DNV =20
Fujitsu                           Chris Nieves         P Yes =20
Harting, Inc. of N. America       Marcos Barrionuevo   P Yes =20
Hewlett Packard Co.               J. R. Sims, III      P Yes =20
Hitachi Cable Manchester,Inc      Zane Daggett         P Yes =20
Hitachi Storage Products          Anthony Yang         P Yes =20
Honda Connectors                  Thomas J. Kulesza    P Yes =20
IBM Corp.                         George Penokie       P Yes =20
Iomega Corp.                      tim bradshaw         P Yes =20
KnowledgeTek, Inc.                Dennis Moore         P Yes =20
Linfinity Micro                   Dean Wallace         P Yes =20
LSI Logic Corp.                   Alan Littlewood      P Yes =20
Madison Cable Corp.               Robert A. Bellino    P Yes =20
Maxtor Corp.                      Pete McLean          P Yes =20
Methode Electronics, Inc.         Bob Masterson        P Yes =20
Molex Inc.                        Joe Dambach          P Yes =20
Oak Technology, Inc.              Robin Freeze         P Yes =20
Ophidian Designs                  Edward A. Gardner    P Yes  IV=20
Philips Key Modules               Bill McFerrin        P Yes =20
QLogic Corp.                      skip jones           P Yes =20
Quantum Corp.                     James McGrath        A Yes =20
Seagate Technology                Gene Milligan        P YesC IV Cmnts=20
Silicon Systems, Inc.             Stephen Finch        A No   IV Cmnts=20
Sony Electronics, Inc.            Jan F. Rebalski      A Yes =20
Storage Technology Corp.          Erich Oetting        P Yes =20
Sun Microsystems Computer Co      Robert Snively       P Yes =20
Symbios, Inc.                     John Lohmeyer        P Yes =20
SyQuest Technology, Inc.          Patrick Mercer       P Yes =20
Toshiba America Info Sys          Tokuyuki Totani      P Yes =20
UNISYS Corporation                Ken Hallam           P Yes =20
Unitrode Corporation              Paul D. Aloisi       P Yes =20
Western Digital Corporation       Jeffrey L Williams   P YesC Cmnts=20
Woven Electronics                 Doug Piper           P Yes =20

Key:
P       Voter indicated he/she is principal member
A       Voter indicated he/she is alternate member
O       Voter indicated he/she is observer member
?       Voter indicated he/she is not member or does not know status
YesC    Yes with comments vote
Abs     Abstain vote
DNV     Organization did not vote
IV      Individual vote (not organizational vote)
Cmnts   Comments were included with ballot
NoCmnts No comments were included with a vote that requires comments
DUP     Duplicate ballot (last ballot received from org. is counted)
PSWD    The password was not correct (vote not counted)
ORG?    Organization is not voting member of T10 (vote not counted)

Ballot totals:
 49 Yes
  1 No
  0 Abstain
  2 Organization(s) did not vote
 52 Total voting organizations
  5 Ballot(s) included comments

This 2/3rds majority ballot passed.

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

Comments attached to YesC ballot from Lawrence J. Lamers of=20
Adaptec, Inc.:

Adaptec votes YES on forwarding SBP-2 with the following comments:

Comment 1
Figure D-2 (SCSI configuration ROM) in section D.2 (SCSI command set target)=
=20
of Annex D (informative) (Sample configuration ROM) uses a key value which=
=20
does not have a definition in any other standard.  The ninth (quadlet) entry=
=20
has a key type of 0, a key value of 17 hex and an information field of=20
"model_ID."  The last paragraph of section D.2.1 (Unit_Directory) says:
"The Model_ID entry in the unit directory, with a key field of 17 (subscript=
=20
16), has an immediate value whose meaning is specified by the module vendor.=
 =20
Immediately following the Model_ID entry is a textual descriptor leaf entry,=
=20
with a key field of 81 (subscript 16), whose indirect_offset value of 5=
 points

to a leaf that contains the ASCII string "QQQQ"".=20

Furthermore, ISO/IEC 13213 ANSI/IEEE Std 1212, in section 8.6 (Key=20
definitions), specifies that key values 17 hex to 2F hex are reserved for=20
future definition by the CSR Architecture.=20

Thus, it appears that the informative annex does not comply with 13213/1212=
=20
CSR Architecture.=20

Comment 2
There are issues in the Configuration ROM for target devices regarding the=
=20
desire to provide textual descriptors and, perhaps, special identifier=
 values=20
for the class driver and type class driver of the Microsoft device driver=20
stack.  Various proposals which have made "loose" use of textual descriptor=
=20
leaves, bus_dependent_info and "model_name" entries.  Compatibility among=
 many

target device types as well as many initiator types need these issues need=
 to=20
be cleared up.=20

Lawrence J. Lamers
Ljlamers at corp.adaptec.com

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

Comments attached to YesC ballot from Peter Johansson of=20
Congruent Software, Inc.:

These comments accompany my ballot to forward SBP-2 to NCITS for
further processing. They are split into two groups, editorial and
technical comments.

Page   Clause       Editorial comment

vi    Foreword      In the first sentence of the first paragraph
                    the word 'such' should be deleted.
5     3.1.2.3       In the definition of a device server,
                    'function' should either be changed to
                    'functional' or deleted.
      3.1.2.4       Correct 'is' to 'are' to agree with plural
                    'terabytes'.
6     3.1.2.8       Here and throughout the draft, correct usage
                    of 'isochronous cycle' to match 'isochronous
                    period' terminology used by P1394a.
      3.1.2.10      Change the definition of 'listener' to:
                    A node that receives stream packet(s) for a
                    channel. A listener that receives isochronous
                    data typically observes a single stream
                    packet each isochronous period. There may be
                    zero, one or more listeners for any given
                    channel.
                    The revised definition matches the P1394a
                    changes with respect to asynchronous streams
                    and 'loose' isochronous.
      3.1.2.15      The term 'asynchronous command block' is
                    nowhere used in the draft. The second
                    sentence of the definition should be changed
                    to read:
                    Asynchronous Serial Bus transfers are used to
                    effect the data transfer.
7     3.1.2.29      The end of the sentence should read '... not
                    specified by this standard.'
17      4.6         The second sentence of the second paragraph
                    should read, 'A consequence of ordering is
                    that...'
21     4.7.3        A phrase in the first sentence should be
                    changed to read '... receive reports of all
                    errors ...'
24      5.1         In the paragraph immediately below Figure 14,
                    a period following 'ORB' should be a comma.
25     5.1.2        In the note, change '... appropriate for ...'
                    to '... well-suited to ... '.
28     5.1.3        In the third sentence of the first paragraph,
                    '... isochronous requests ...' should be '...
                    isochronous commands ...'.
39    5.1.4.3       In Figure 29 and the paragraph below, it
                    might be clearer to refer to stream_ID in
                    place of login_ID.
72     9.1.4        In the second paragraph below Figure 58, the
                    introductory phrase is missing a space after
                    'Transition'.
77      10.1        The definition of 'working set' should be
                    reinforced by a reference here. For example,
                    the last sentence of the second paragraph
                    might conclude, '...the ORB's already fetched
                    by the target (the working set).'
        10.1        The last paragraph is unclear with respect to
                    a normal task set. Replace the second
                    sentence with:
                    Although this one-to-one association between
                    a normal task set (the task set created by a
                    login request) and a logical unit is
                    retained, the concept is extended by SBP-2 to
                    permit multiple stream task sets per logical
                    unit.
        10.2        There is a redundant 'is' in the first
                    sentence of the last paragraph on the page.
79     10.4.1       Procedural list paragraph d) has a
                    typographical error; correct REQUEST to
                    REQUEST COMPLETE.
82     10.4.6       A sentence should be added to the first
                    paragraph that says:
                    Targets that implement other task management
                    models may optionally support terminate task.
124     G.4         In Figure G-3, the numeric value for
                    command_set_spec_ID is missing a space before
                    the subscript '16'.

The following comments are technical.

Page   Clause       Technical comment

33     5.1.4        The paragraph below Figure 21 should specify
                    that the notify bit shall be one.
35    5.1.4.1       The paragraph below Figure 22 hasn't been
                    corrected to reflect the inclusion of Annex C
                    on password security.
47      5.3         The table of possible sbp_status values
                    should be updated to include 0x0B to
                    correspond to ack_tardy defined by IEEE
                    P1394a. The error occurs if the addressed
                    node continues to return ack_tardy after some
                    time limit.

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

Comments attached to YesC ballot from Gene Milligan of=20
Seagate Technology:

The SBP-2 draft standard is very well documented. But I do have some=
 comments
to improve it:

1) The T10 format uses both an ISO/IEC and a NCITS document number. However
the
final document is=20
editorially slightly different. If this practice is to continue, SBP-2=
 should
be 14776-TBD. I can provide the=20
TBD when back in the office.

2) The 1394 reflector subscription address has changed.

3) Regarding the abstract my recollection of the 1394 title is that it is
somewhat different than 'Serial Bus'.

4) I assumed SBP-2 was not limited to isochronous.

5) The draft is missing the patent statement.

6) Annex F needs an expanded title since it is not the SCSI architecture
model.

7) Regarding the foreword operating systems and embedded applications are=
 not
initiators. In this instance=20
initiators should be replaced with upper layer protocols.

8) Change 'Vendors that wish to implement devices that connect to Serial Bus
may follow the requirements=20
of this and other standards to manufacture an SBP-2 compliant device.' to
'Vendors that wish to implement=20
devices that connect to Serial Bus may follow the requirements of this and
other normatively referenced=20
standards to manufacture an SBP-2 compliant device.'

9) Change 'This standard was developed by T10 during 1996 and 1997.' to=
 'This
standard was developed=20
by T10 during 1996 through early 1998.'

10) I think the foreword should have a statement about why this is SBP-2
rather
than SBP.

11) The membership list for NCITS looks like a remarkably old X3 list.

12) Delete the revision history but it would be nice to keep it in a=
 separate
document.

13) Regarding the scope I doubt that SBP-2 conforms to other standards. This
should be restated to the fact=20
that SBP-2 requires implementations to conform to the other standards.

14) I suggest changing the purpose towards the 1394 not just a serial
interface
which was previously=20
accomplished and moving all the desired information to the foreword.

15) IEC 61883/FDIS is actually five standards each with a slightly different
title. All five should be listed=20
unless certain ones among the family should not be referenced.

16) Is there a reason not to list the published SAM and other command sets?

17) It would be better to include the key words listed under conformance in=
 a
Key Word clause as is done in=20
most of the other SCSI standards.

18) Expected should be compared to the other SCSI standards to determine why
the definition should be=20
different.

19) I prefer the reserved definition in this draft to that in other SCSI
standards but the last sentence 'The=20
recipient of a defined object shall check its value and reject reserved code
values.' seems to disagree with=20
the bulk of the definition. I think the problem is object as opposed to=
 field.

20) Regarding 3.1.2.1 are bytes only used for data?

21) Regarding 3.1.2.2 there seem to be extraneous '-'s as there are in
3.1.2.34.

22) In SBP-2 the device server definition is '3.1.2.3 device server: A
function
component of a logical unit=20
responsible to execute tasks initiated by command blocks that specify data
transfer or other device=20
operations.' T10 should consider this definition for SPI-2 which is missing
the
definition.

23) Change '3.1.2.4 initial node space: The 256 terabytes of Serial Bus
address
space that is available to=20
each node.' to '3.1.2.4 initial node space: The 256 terabytes of Serial Bus
address space that may be=20
available to each node.' as I presume not every implementation will populate
all=20
256 terabytes.

24) In 3.1.2.8 change 'During an isochronous cycle, the bus is available to
isochronous talkers, only.' to=20
'During an isochronous cycle, the bus is available to isochronous talkers
only.

25) The definition 'A task has a lifetime, which commences when the task is
signaled to the target, proceeds=20
through a period of execution by the target and finishes when completion
status
is stored at the initiator.=20
While a task is active, it makes use of both target resources and initiator
resources.' is very clear but my=20
understanding of a task was that it began when a nexus or I/O operation was
entered into the task set.

26) The abbreviations should include msb and lsb and the use of MSB and LSB=
 as
in all other SCSI=20
standards should be considered.

27) Make a global deletion of 'precisely' (e.g. change 'precisely defines'=
 to
'defines').

28) Regarding one of the unlabeled tables it is of no value to have=
 mandatory
requirements for what a=20
standard contains, the only value for mandatory requirements is for
implementations. Consequently and for=20
typo reasons change 'The meaning of the field shall by defined by the bus
standard, in this case IEEE Std=20
1394-1995' to 'The meaning of the field is defined by IEEE Std 1394-1995'.

29) What does 'The meaning of the field shall be defined by the organization
responsible for the unit=20
architecture' mean? How is it different than vendor dependent (which in=
 other
SCSI standards is vendor=20
specific)?

30) I assume the use of terms differing from other members of the SCSI=
 family
of standards is not NIH but=20
is congruence with 1394 and/or 13213. If the assumption is correct, it
would be
helpful to add an=20
informative annex providing a correlation table of 1394/SCSI terms (e.g.
lsb/LSB; vendor=20
dependent/vendor specific). If I am wrong and it is NIH then change the=
 terms
to the SCSI family terms.

31) Add a glossary definition of 'node'.

32) Above other unlabeled tables, what is the difference between 'may be
specified by the terms below'=20
and 'shall be specified by the terms below'? Since the requirements should=
 not
be for the editor, I think=20
both should be 'is specified by the terms below'.

33) In Clause for, due to the baggage 'may' carries, I suggest changing=
 'which
may be neither the initiator=20
nor an SBP-2 device.' to  'which may be an initiator, a target, or a device
that is not a SBP-2 device.'

34) I think the two paragraphs of clause 4 should be reversed.

35) Does 'In CSR architecture and Serial Bus terminology, devices=
 implemented
to this standard (targets)=20
are units.' mean that initiators are not implemented to this standard?

36) With regard to figure 6, is the ground symbol at the end of a linked=
 list
conforming to some standard for=20
illustrating linked lists? To me it seems odd.

37) In 4.5 change 'The time-critical nature of isochronous operations=
 requires
that stream control agents=20
support linked lists of requests, just as command block agents.' to 'The
time-critical nature of isochronous=20
operations requires that stream control agents support linked lists of
requests, just as command block agents=20
do.'

38) Assuming there is a reason to keep clause 4 from being normative, in 4.6
change 'The ordered model=20
specifies both that tasks shall be executed in order and that completion
status
shall be returned in the same=20
order.' to 'The ordered model assumes both that tasks are executed in order
and
that completion status is=20
returned in the same order.'

39) Change 'A consequence of ordering that completion status for one task
implicitly indicates successful=20
completion status for all tasks that preceded it in the ordered list.' to 'A
consequence of ordering is that=20
completion status for one task implicitly indicates successful completion
status for all tasks that preceded it=20
in the ordered list.'

40) Change 'Unrestricted reordering places the responsibility for the
assurance
of data integrity on the=20
initiator.' to 'Unrestricted reordering leaves the responsibility for the
assurance of data integrity with the=20
initiator.'

41) I think figure 9 needs additional labels to convey the information I
assume
was intended by the author.=20
Some of the lines of explosion(?) leave me with a 'Huh?).

42) In 4.7.1 change 'Isochronous data is essentially time-ordered. As a
consequence, the isochronous data=20
transferred to or from the device medium must be presented in correct order.
Therefore no reordering of=20
isochronous commands is permitted within the task set associated with an
isochronous stream and the=20
failure of any one task requires that all subsequent tasks be aborted.=20

This requires not only that tasks in a stream task set are executed in order
but also that their completion=20
status reported in the same order.' to

'Isochronous data is essentially time-ordered. As a consequence, the
isochronous data transferred to or from=20
the device medium needs to be presented in correct order. Therefore no
reordering of isochronous=20
commands is done within the task set associated with an isochronous stream=
 and
the failure of any one task=20
results in all subsequent tasks being aborted.=20

Not only are tasks in a stream task set executed in order but also their
completion status is reported in the=20
same order.'

43) In clause 5 change 'The node_ID field shall specify the Serial Bus node
for
which the address pointer is=20
valid, as defined by IEEE Std 1394-1995.' to  'The node_ID field shall=
 contain
the Serial Bus node for=20
which the address pointer is valid, as defined by IEEE Std 1394-1995.'

44) The break lines (I presume) in Figure 14 are peculiar.

45) In 5.1 change 'If the request completes with an error condition, the=
 value
of notify is ignored and a=20
status block shall be stored at the status_FIFO address.' to  'If the=
 request
completes with an error=20
condition, the value of notify is ignored and a status block shall be
stored at
the status_FIFO address=20
specified in the ORB or, if not specified in the ORB. at the address=
 supplied
in the login or create stream=20
request.' or to 'If the request completes with an error condition, the
value of
notify is ignored and a status=20
block shall be stored.'

46) Regarding 'A target's command set and device type determine the length=
 of
the ORB's which shall be=20
fixed for a particular command set and device type.' in 5.1.2, some command
sets have different length=20
command blocks. Should this be 'A target's command set maximum length and
device type determine the=20
length of the ORB's which shall be fixed for a particular command set and
device type.'? If so is padding=20
defined somewhere?

47) Regarding 'There are two kinds of command block ORB, one for normal
(asynchronous) operations=20
and one for isochronous operations.', but are they the same size as defined
above?

48) I think there are many places where 'specify' should be replaced with
'contain'.

49) Regarding figure 16, how do you determine the length of the command=
 block
since the device seems to=20
be able to choose a fixed length?

50) The unlabeled table does not seem to match the numbering convention. It
seems odd the 0-8 have no=20
subscripts but F does.

51) What does 'enqueued' mean? My 1922 Funk and Wagnells does not have
'enqueued' but based upon=20
its lengthy discussion of 'en' which was gravitating to 'in' it appears that
'enqueued' is the feminine=20
version of 'queued'.

52) Below figure 24 change 'All of these buffers shall be in the same node=
 as
the initiator; consequently the=20
node_ID field of these addresses shall be reserved.' to  'All of these=
 buffers
shall be in the same node as the=20
initiator; consequently the node_ID field of these addresses is reserved.'

53) Change '5.1.4.3 Create stream ORB Before any stream requests can be
made of
a target, the initiator=20
shall first complete a create stream procedure that uses the ORB format=
 shown
below.' to Change '5.1.4.3=20
Create stream ORB Before any stream requests are made of a target, the
initiator shall first complete a=20
create stream procedure that uses the ORB format shown below.'

54) Change 'Valid values for idf are encoded in the table below.' to 'Valid
values for idf are shown in the=20
table below.'

55) In 5.1.4.5 change 'When an initiator wishes to relinquish its access
privileges for a logical unit or an=20
isochronous stream, it shall perform a logout with the ORB format shown
below.'
to 'In order to relinquish=20
its access privileges for a logical unit or an isochronous stream, an
initiator
 shall perform a logout with the=20
ORB format shown below.'

56) The unnumbered note 'NOTE - In the case of TARGET RESET, which does not
pertain to any one=20
task set, login_ID shall be set to a value obtained as the result of any
successful login completed by the=20
initiator.' should be made part of the body text or changed to eliminate the
mandatory requirement.

57) 5.3 is redundant to the requirements of 5.1. It would be better if 5.1
deleted the requirements in favor of=20
5.3.

58) The unnumbered note 'NOTE - An SBP-2 response code of ILLEGAL REQUEST
shall
not be used to=20
indicate unsupported fields or bit values in the command set-dependent=
 portion
of the ORB. This response=20
code shall be used only to indicate an error in the first 20 bytes of the
ORB.'
should be made part of the=20
body text or changed to eliminate the mandatory requirements.

59) Regarding an unlabeled table what is the difference between 'Reserved=
 (not
to be used)' and 'Reserved=20
for future standardization'?

60) I think Std may be a standard abbreviation for standard but I do not=
 think
it is for ANSI. I suggest that a=20
'Std' be globally replaced with 'standard'.

61) Since all the other SCSI standards use ISO/IEC rules for decimal values
and
any desired ISO/IEC=20
standard for SBP-2 will use the ISO/IEC rules, I suggest SBP-2 be revised to
include and conform with=20
those rules at this time (e.g. '24.576 MHz' changes to '24,576 MHz'). Be=
 sure
to add the conventions=20
statement to avoid US 24 GHz implementations.

62) In 7 shouldn't 'all other directories and leaves' be 'all other
directories
and leafs'?

63) In 7.4.1, 'The value indicates that the NCITS Secretariat is responsible
for the software interface=20
definition.' Say what?

64) Referring to 8.1 'Targets shall implement a logical unit reservation
protocol that by itself supports=20
neither persistent reservations nor passwords;' does this mean it shall be
vendor dependent except that it=20
must not support persistent reservations? Does this mean an exception to
SPC by
making persistent=20
reservations prohibited?

65) The unnumbered note 'NOTE - The speed at which the block write request=
 to
the=20
MANAGEMENT_AGENT register is received shall determine the speed used by the
target for all=20
subsequent requests to read the initiator's configuration ROM, fetch ORB's
from
initiator memory or store=20
status at the initiator's status_FIFO. Command block ORB's separately=
 specify
the speed for requests=20
addressed to the data buffer or page table.' should be made part of the body
text or changed to eliminate the=20
mandatory requirement.

66) The unnumbered note 'NOTE - Upon playback (when the target is a talker),
the aggregate maximum=20
isochronous payload shall reflect the total of all channels recorded on the
medium=97not just the aggregation=20
of payload(s) for the channels to be transmitted on Serial Bus. This is
essential since the target reads all of=20
the data from the medium even though the channel mask may select a small
subset
for playback.' should be=20
made part of the body text or changed to eliminate the mandatory=
 requirement.

67) Larger and/or darker font in figure 58 would be helpful.

68) The unnumbered note 'NOTE - The fetch agent may issue either an 8-byte
block read request (to fetch=20
just the next_ORB field) or it may reread the entire ORB. The initiator=
 shall
insure that system memory=20
occupied by the ORB remains accessible, as described in 9.3.' should be made
part of the body text or=20
changed to eliminate the mandatory requirement.

69) The paragraph above the note in 10.2 is redundant to the model clause=
 4.6.
The redundancy can be=20
resolved by changing the wording of 4.6 to eliminate the mandatory
requirements
in the informative clause.

70) The combination of suggestions and mandatory requirements in 10.4.1
'Otherwise, the target should=20
perform the following actions in response to a task management ORB with the
ABORT TASK function:
a) The target should not issue additional data transfer requests for the=
 task;
b) The target shall wait for responses to pending data transfer requests=
 and,
once all such responses are=20
received, shall not issue additional data transfer requests for the task;
c) So long as none of the target medium, data buffer or status FIFO have=
 been
modified as the result of=20
partial execution of the task, the target shall store completion status of
REQUEST COMPLETE with an=20
sbp_status field that indicates dummy ORB completed;
d) Otherwise, if task execution has commenced and any one of the target
medium,
data buffer or
status FIFO has been modified, then the target shall store completion
status of
REQUEST with an
sbp_status field that indicates request aborted.' may lead to confusion. I
think the shalls in this sequence=20
should be shoulds.

71) I suggest that the Terminate Task definition should end immediately=
 after
'FUNCTION REJECTED.'

72) In 11.2, 12.3, and Annex G identify which parts of 61883 are being
referenced.

73) Delete 'notable' from the first paragraph of 12.1.

74) Regarding 'See section 9 for a more detailed description;' of what?
Regarding 'the information is as=20
applicable to stream control ORB's as it is to normal command block requests
and stream command block=20
ORB's.' which information?

75) In Annex A does 'In addition to those minimum capabilities defined by=
 IEEE
Std 1394-1995, this=20
annex specifies the minimum capabilities that an initiator or a target shall
support in order to implement=20
SBP-2.' that the list in 1394 is to be ignored or that Annex A is an
incremental addition to the list?

76) The unnumbered note 'NOTE - The value of STATE_CLEAR. dreq shall be
unaffected by a Serial=20
Bus reset. The target may automatically set dreq to zero (request initiation
enabled) upon a power reset or a=20
command reset.' should be made part of the body text or changed to eliminate
the mandatory requirement.

77) Clause A.2 would be strengthened by being more specific several places
than
'this capability'.

78) Regarding 'A Serial Bus reset, by itself, shall not alter a target's
responsiveness to request subactions.',=20
should there be some mention of what might make the reset more virile and=
 make
it not 'by itself'?

79) The unnumbered note 'NOTE - While initializing after a power reset, a
target shall respond to quadlet=20
read requests addressed to FFFF F000 040016 with either a response data=
 value
of zero or acknowledge the=20
request subaction with ack_tardy, as specified by draft standard IEEE=
 P1394a.
This indicates that the=20
remainder of configuration ROM, as well as other target CSR's, are not
accessible.' should be made part of=20
the body text or changed to eliminate the mandatory requirement.

80) ) The unnumbered note 'NOTE - SBP-2 permits the return of a status block
between two and eight=20
quadlets in length. When a truncated status block is stored, the omitted
quadlets shall be interpreted as if=20
zero values were stored.' should be made part of the body text or changed to
eliminate the mandatory=20
requirement.

81) There are several mandatory requirements in informative Annex E=
 including
those in notes, these=20
should either be reworded to remove the mandatory requirements or Annex E=
 made
normative. In any case=20
the offending note should be corrected.

82) Regarding 'F.8 Hard reset A Serial Bus reset causes the target to
execute a
hard reset, as defined by=20
SAM-2.' does Annex A 'A Serial Bus reset, by itself, shall not alter a
target's
responsiveness to request=20
subactions.' match the F.8 claim?

83) Regarding Annex G there is also an EIA 1394/61883 specification being
developed that perhaps should=20
be referenced.

84) Either rewrite Annex G to be normative or change 'The len field=
 indicates
the size of the status block=20
and shall have a value of four.' to 'The len field indicates the size of the
status block and has a value of=20
four.'

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

Comments attached to No ballot from Stephen Finch of=20
Silicon Systems, Inc.:

The following comments are provided. These comments can be divided into
three catagories:  purely editorial and not the basis of the NO vote;
technical issues that should be resolved but are not individually the basis
of the NO vote, although if a number of these aren't resolved to my
satisfaction anyone of them could be the basis of a NO vote; and,
significant technical issues that are the basis of the NO vote.  Each
comment is numbered separately.  Each number is followed by (E), (M) or (N)
to indicate whether the comment is editorial, an area needing technical
correction, or the reason for the NO vote.

1. (N)  This document provides a definition of several basic functions:
access control; task management; asynchronous command, data and status
tranportation; isochronous command, data and status transportation;
isochronous control and status transportation; and, isochronous control
commands.  The definition and documentation of most of these are fairly
mature with the exception of the those sections dealing with isochronous
operation.  This, I beleive, is a direct result of insufficient
participation by experts from the A/V and consumer electronics fields and a
lack of attention to the subject matter by the storage manufacturers
present.  While we have made a valent attempt to obtain the inputs and
participation from the A/V and consumer electronics industry, and some of
the participents from storage manufacturers have spent a lot of individual
time studying documents generated by other groups, I believe we can not
assume we have accomplished this goal, especially not to the extent of
setting it in concrete, i.e., including it into a standard.  I recommend
that the information pertaining to isochronous commands and isochronous
operation be removed from this standard and that a new project be authorized
to document these aspects.  The need for isochronous storage devices is not
so near that it needs to be documented immediately.  I believe it is much
more important that such documentation be complete and correct.  I know of
individuals who are willing to chair such a group and edit such a document.
I have input from some A/V manufacturers that they want to pursue this mode
of operation starting this year, so there participation can be expected.  I
think we had the best of intensions when we included isochronous operatons
in the scope of this project, but is was just too early to get the
appropriate attention of those with the appropriate knowledge and
experience.  I do not want to see the asynchronous portion of this standard
delayed.

2. (E)  Remove the text title "Revision history" on pages ix through xviii.
This information is not appropriate for inclusion in a standard.

3. (E)  Section 1.1, change first sentence to read:  "This standard defines
a transport protocol for exchanging commands, data and status on the High
Performance Serial Bus,..."

4. (E)  Section 2 lists normative references.  Is there a method of listing
informative references?  I think we should add this to cover cases such as
the reference in Annex G to the "1394 Trade Associate Specification for AV/C
Digitial Interface Command Set, Version 2.0, April 22, 1997".  Note that
this document reference is now out of date.

5. (M)  Section 3.1.2  The term "target" is used extensively through out
this document and is not defined.  Add a definition for target.  In some
places in the document target is used when node is meant.  I have tried to
note these in my comments.  I suggest the following definition:

"3.1.2.x  target: A device containing logical units that receive and execute
commands from one or more initiators.  A target is a unit as defined in CSR
architecture and Serial Bus terminology."

6. (M)  Section 3.1.2  The term "initiator" is used extensively through out
this document and is not defined.  Add a definition for initiator.  I
suggest the following definition:

"3.1.2.x initiator: A device containing application clients that originate
commands to be processed in a target."

7. (M)  Section 3.1.2  The term "request" is used extensively through out
this document.  This term has specific a meaning in IEEE 1394-1995 which is
different from the usage in this document.  Add a definition for "request"
and for a second term "request subaction".  I suggest the following
definitions:

"3.1.2.x request: An ORB constructed by an initiator for processing by a
target.  The term request is not a request packet as defined by IEEE
1394-1995"

"3.1.2.x request subaction: A request packet as defined by IEEE 1394-1995."

8. (M)  Section 3.1.2  The term "response" is used extensively through out
this document.  This term has specific a meaning in IEEE 1394-1995 which is
different from the usage in this document.  Add a definition for "response"
and for a second term "response subaction".  I suggest the following
definitions:

"3.1.2.x response: An block of data constructed by a target in response to a
request which is stored in the initiators system memory by the target.
Login Response and Status are examples of responses."  The term response is
not a response packet as defined by IEEE 1394-1995"

"3.1.2.x response subaction: A response packet as defined by IEEE
1394-1995."

9. (E)  Section 3.1.2  There are a lot of related and/or similarly named
 terms such as command block, normal command block, stream command block,
 command descriptor block, stream command ORB, stream command block ORB, and
 other combinations of these terms with other terms such as agent.  I don't
 believe these are consistantly used and nor adequately defined.  I propose
 that we limit the number of such terms to the following list, define these
 terms in section 3.1.2, and review the document to make sure the usage of
 these terms is consistant:


command_block
        a field with a Command ORB

Command ORB
        either a Normal Command ORB or a Stream Command ORB

Command Agent
        an agent the processes either a Normal Command ORB or a Stream
        Command ORB

CDB, SCSI CDB or command block descriptor
        what is placed in the command_block of a Normal Command ORB when the
        target to which the request has been signaled is expecting a SCSI
        command.

Normal Command ORB
        an ORB signaled to a normal command agent whose address was returned
        as part of a Login response.

Normal Command Agent
        an agent the processes Normal Command ORB's

Normal Command Task Set
        a linked set of Normal Command ORBs available for the target to
        execute

Stream Command ORB
        an ORB signaled to a stream command agent whose address was returned
        as part of a Create stream response.

Stream Command Agent
        an agent the processes Stream Command ORB's

Stream Command Task Set
        a linked set of Stream Command ORBs available for the target to
        execute

Stream Control ORB
        an ORB signaled to a stream control agent whose address was returned
        as part of a Create stream response.

Stream Control Agent
        an agent the processes Stream Control ORB's

Stream Control Task Set
        a linked set of Stream Control ORBs available for the target to
        execute

Management ORB
        a generic term to describe an ORB which was signaled to a Management
        agent of a target.  This includes the:  Login ORB, Query login ORB,
        Create stream ORB, Reconnect ORB, Logout ORB and the task management
        ORBs (Terminate Task ORB, Abort Task ORB, Abort Task Set ORB, Clear
        Task Set ORB, Logical Unit Reset ORB, and Target Reset ORB)

Management Agent
        an agent the processes Management ORB's

Login ORB
        a specific type of Management ORB

Query login ORB
        a specific type of Management ORB

Create stream ORB
        a specific type of Management ORB

Reconnect ORB
        a specific type of Management ORB

Logout ORB
        a specific type of Management ORB

Task management ORBs
        a sub-type of Management ORB, a generic term for any of the
        following:  Terminate Task ORB, Abort Task ORB, Abort Task Set ORB,
        Clear Task Set ORB, Logical Unit Reset ORB, and Target Reset ORB

Terminate Task ORB
        a specific type of Management ORB of the sub-type Task Management
        ORB

Abort Task ORB
        a specific type of Management ORB of the sub-type Task Management
        ORB

Abort Task Set ORB
        a specific type of Management ORB of the sub-type Task Management
        ORB

Clear Task Set ORB
        a specific type of Management ORB of the sub-type Task Management
        ORB

Logical Unit Reset ORB
        a specific type of Management ORB of the sub-type Task Management
        ORB

Target Reset ORB
        a specific type of Management ORB of the sub-type Task Management
        ORB


9. (E)  Section 3.1.2.3, change "function component" to "functional
component", and change "responsible to execute tasks" to "responsible for
the execution of tasks".

10. (M)  Section 3.1.2.7, change "and one or more nodes that are listeners"
to "and zero or more nodes that are listeners".  As currently stated, it
directly contradicts the statement in the definition of listener (3.1.2.10)
which states "There may be zero, one or more listeners for any given
isochronous channel."

11. (E)  Section 3.1.2.15, delete the last sentence which reads "Sometimes
referred to as an asynchronous command block, since asynchronous Serial Bus
transfers are used to effect the data transfer."  There are no other
occurrances of the term "asynchronous command block" in the document.

12. (E)  Section 3.1.2.20, change "request and response subactions" to
"request subaction and response subaction".

13. (M)  Section 3.1.2.22, change "A data structure written to" to "A data
structure which may be written to".  The return of status blocks is optional
for commands which do not have the notify bit set and which complete without
error.

14. (M)  Section 3.1.2.24, states "requires coordination with stream control
ORB's".  This is not true.  Language has been added to the standard which
allows for isochronous operation when stream control functionality is
provided by means that do not utilize stream control ORB's.  I recommend we
delete the second.

15. (E)  Section 3.1.2.25, change "stream ID" to "stream identifier (stream
ID)".

16. (E)  Section 3.1.2.26, change "common example of nodes that make system
memory addressable" to "common example of nodes which might make system
memory addressable".

17.  (M) Section 3.1.2.28, according to this section, if the notify bit is
zero and the target device chooses not to return status, the task is never
complete.

18.  (M) Section 3.1.2.28:  the use of the term "stored" is not clear.
Whereever "store" is used, replace with "is written to the initiator by the
target via a write quadlet request or a write block request" or  "is written
to the target by the initiator via a write quadlet request or a write block
request".  It might be easier to include a definition of "store".

19. (M)  Section 3.1.2.29, delete the entire second sentence.  The intent of
this sentence is not clear and doesn't add any useful information

20. (E)  Section 3.1.2.31, this definition is too lengthy and, argueably,
wrong.  I suggest we use a slight modification of the definition from IEEE
1394-1995:  "A request subaction and the corresponding response subaction.
The response subaction may be null for transactions with broadcast
destination addresses, or the need for a response subaction may be met by an
ack_complete being returned in response to the initial request subaction."

21. (E)  Section 4, second paragraph, first sentence, change "describes
components of the SBP-2 model" to "describes typical components and
operation of the SBP-2 model".

22. (E)  Section 4.3, in paragraph proceeding Figure 6, change "Login and
management requests are directed to agents" to "Management requests,
including Login Requests, are directed to an agent".  After this first
sentence, add "These requests do not contain a field which allows multiple
ORB's to be linked together."

23. (E)  Section 4.4, change the first sentence by replacing "and" with
"and, for those commands which transfer data,"

24. (E)  Section 4.4, last paragraph, delete "(or a scatter/gather list)".
This terminology is used only twice, each time as parenthetical adjunct to
insert a second name for an unrestricted page table.  This second name is
never used elsewhere, so there is no reason to include it at all.  The other
location is in section 5.1.2.1.

25. (M)  Section 4.5, there are statements that seem to indicate that the
normal command agent and the stream command agent.  These two agents are
distinct and may operate differently, depending upon implementation.  The
paragraph which includes the second set of bullets reads:

"There are three defined target agents:
 - management;
 - command block; and
 - stream control."

Change this to read:

"There are four defined target agents:
 - management;
 - normal command;
 - stream command; and
 - stream control."

Change the next to last paragraph,

"A successful login request returns the address of a normal command block
agent.  A successful create stream returns the address of a stream command
block agent.  Both of these types of command block agents service requests
that are organized in linked lists.  Each linked list is managed by a
separate command block agent."

26. (M)  Section 4.5, last paragraph includes "(e.g., plug control registers
as specified by IEEE P1394a)".  Plug control registers are not defined in
that standard.  The easiest solution is to delete the parenthetical phrase.

27. (M)  Section 4.5, last paragraph, last sentence, delete "The time
critical nature of isochronous operations requires that".  This is not
necessarily true, depending upon the isochronous control ORB's that are
issues and the functionality supported by a target device.

28. (M)  Section 4.6, last sentence of first paragraph uses the term "mass
storage" when what is meant is "random access storage".  The term "mass
storage" includes, at least in my mind, tape drives, writeable CD's and
other devices where there is positional context.  If we agree that "mass
storage" is not the same as "random access storage", then there are a number
of places within this document that need to be changed.

29. (E)  Section 4.7, third paragraph, change "The presentation of this data
is controlled by ORB's that request data transfer to or from the medium and,
optionally, other ORB's that control its flow on Serial Bus. The second type
of ORB, the stream control ORB is not required if the target has other
facilities to control the flow of isochronous data from or to Serial
Bus.",to "The presentation of this data is controlled by stream command
ORB's that request data transfer to or from the medium and, optionally,
stream control ORB's that control its flow on Serial Bus. The stream control
ORB is not required if the target has other facilities to control the flow
of isochronous data from or to Serial Bus."

30. (E)  Figure 9 has gray scale material that leads to understanding of the
figure.  When I printed out the .pdf file, the differences in the gray
scales is marginal at best.  I suggest that the gray scale be changed to
some type of fill pattern to aid in the reliable production of the standard.

31. (E)  Figure 10, and text in section 4.7 introduce the concept of "Flow
control" and "Stream task set".  I believe that these terms are actually
referring to Stream Control ORB's and Agents, and Stream Command ORB's and
Agents.

32. (M) In the note below figure 10, in section 4.7 it states:  "NOTE - When
a target does not implement a stream control agent, the left-hand side of
the figure (which shows flow control ORB's and their fetch agent) is not
present.  Other facilities, such as plug control registers, provide a means
to specify channel number(s) while the flow control functions START, PAUSE
and STOP are typically part of the command set used in the stream command
block ORB's."  I know of no method or command set that allows the passing of
any stream control ORBs (sic) via the stream command ORB agent.  I suggest
that we change this to:  "NOTE - When a target does not implement a stream
control agent, the left-hand side of the figure (which shows stream control
ORB's and their fetch and execution agents) are not present.  Control
functions and methodologies that are used when a Stream Control Agent is not
present are beyond the scope of this standard."

33. (E)  Section 4.7.1, change the first paragraph to read:  "Both a normal
(or asynchronous) task set and a stream task set consist of a set of
commands that request data transfer to or from a device's medium. A stream
task set is different in two important respects:

  - no system memory addresses; and

  - implicit order relationships."

To read:  "A stream command task set consists of a set of commands that
request data transfer to or from a device's medium. A Stream command ORB is
different from a Normal command ORB in that there is no system memory
address contained in the ORB.  In addition, stream control task sets are
executed sequentially."

34. (M)  Section 4.7.2, the last paragraph states:

"Stream controller actions may be queued by the target. This permits
time-critical operations to be specified in advance and avoids latency
problems that could arise if the stream controller could accept no more than
one request at a time.  Within the queue of requests to the stream
controller, each is executed in order as the preceding stream control ORB
completes."

While I agree that this may be a valid implementation, I don't think it has
been established that this is the only implementation nor that it is the
implementation desired when using isochronous streams.  Delete this
paragraph or atleast the last sentence of the paragraph.  The remainder of
this section stands by itself.

35.  (E)  Section 5, first sentence.  "Serial Bus Protocol" has been
retracted, change to either "this standard" or "Serial Bus Protocol-2".

36.  (E)  Section 5, paragraph above Figure 12 begins: "ORB's shall be
allocated at the initiator's node and may be organized into a linked list.
Since the node ID is known for all ORB's in a give list, ..."  to "All ORB's
shall be allocated at the initiator's node.  Some types of ORB's are
organized as linked lists and contain a forward address pointer.  Since the
node ID is known for all ORB's in such a list, ..."

37.  (E)  Section 5, last paragraph:  change the last sentence from "In this
case the target shall ignore the ORB offset fields." to "In this case the
target shall ignore the offset_hi and offset_lo fields."  The term "ORB
offset fields" is not defined.

38.  (E)  Section 5.1.2, first paragraph, last sentence, change: "...in
configuration ROM..." to "...in its configuration ROM..."

39.  (E)  Section 5.1.2, delete the NOTE.  It adds nothing to the standard
and makes a statement which may or may not be true.

40.  (M)  Section 5.1.2.1, Table 1.  Table 1 indicates that the values for
3-7 are "As standardized by P1394a", yet an I can not find any table or set
of values in P1394a that correspond to the values of 0-2 and their meaning
as shown in this table, so interpreting values for 3-7 are not possible.  I
recommend we state the values as 3 equals S800, 4 equals S1600 and 5 equals
S3200 and 6-7 are reserved.

41.  (M)  Section 5.1.2.1, second paragraph after Table 1, change the second
sentence to "When data_descriptor addresses a page table, this bit shall be
one."  While the sentence as currently written is true, it is a bit obtuse.

42.  (M) Section 5.1.2.1, fourth paragraph after Table 1, delete "(also
known as a scatter/gather list)".  This terminology is used only twice, each
time as parenthetical adjunct to insert a second name for an unrestricted
page table.  This second name is never used elsewhere, so there is no reason
to include it at all.  The other location is in section 4.4.

43.  (M) Section 5.1.2.2, the cm field and the associated text that follows
are intertwined in a way that I find confusing.  I believe that this field
should be devided into two fields:  cycle_mark_start and stream_start.  If
cycle_mark_start is one, then cycle_mark_offset specifies the location of
the first CYCLE MARK as an offset, in quadlets, relative...,  else the
location of the CYCLE MARK, even if present, is undefined.  If stream_start
is one, the cycle_mark_offset specifies the the location of the first
quadlet of the isochronous data as an offset, in quadlets, relative..., else
the offset is zero and the data begins with the first data byte specified by
the command.

I see no reason to tie these two conditions together and I can visualize a
case where the stream offset is non-zero and there is no CYCLE MARK to be
pointed to.

44.  (M)  Section 5.1.2.2, general comment:  if a cycle offset mark is
specified, I think it MUST be limited to pointing to a location within the
first block of a block oriented device.  If a device has 512 byte blocks,
then the maximum value of the offset is 127 (quadlets).  Currently, there is
no restriction on the value in this field, so if the command transfers 256
blocks (32k quadlets), the offset could be a large number.  This makes the
target's life unduely complicated.

If the above isn't acceptable, at least limit the value of the
cycle_mark_offset field to be less than or equal to the stream_length.

45.  (E)  Section 5.1.3, first paragraph, change "... then records the data
on themedium as specified by isochronous requests." to "... then records the
data on themedium as specified by stream command ORB's."

46.  (E)  Section 5.1.3, the change the term "stream_ctrl-dependent" to
"stream_ctrl_dependent", the use of a "-" isn't required and, at first
glance, the use of the "-" and the fact that "dependent" isn't italisied may
lead someone to think that this syntax has some special meaning.

47.  (M)  Section 5.1.3, in the paragraph describing the STOP control
function:  if a stream which is set up for recording (listening) is stopped
its data is "made available to the isochronous commands previously enqueued
at the stream command block agent."  (In the above, isochronous commands
should be changed to Stream Command ORB's.) There is no statement, here or
elsewhere, that this data must written to the media nor that the current
stream command ORB should be considered complete and a status returned to
indicate a partial write, nor that any commands currently pending on the
stream command linked list should be discarded or completed with an error.
In other words, how does one gracefully stop a stream?

Similarly, if a device is talking, the text says the buffers are flushed,
but what of the stream command ORB's still pending?  Are these commands,
i.e. the task set, also flushed?

In both cases, should the stream command block agent be transitioned to the
dead state?

48.  (E)  Through out section 5 and possibly other sections, the term
"isochronous command(s)" is used instead of "stream command ORB('s)".
Either replace them all or add isochronous command to the glossary (and to
the section on stream command ORB's).

49.  (M) Section 5.1.3, in the paragraph immediately below Figure 19, delete
"specified by login_ID" in the third sentence.  What has login_ID to do with
this function?

50.  (M) Section 5.1.3:  why do we have both a Channel Mask and a Configure
Channels?  If we had only a Configure Channel function and added a one bit
field for this function, we could accomplish the same thing.  In addition,
this would allow changing the channel mask functionality when the stream is
not stopped.

51.  (E) Section 5.1.3, in the second paragraph below Figure 19, delete the
second sentence.  This sentence adds nothing and appears to describe the
transformation in at a general level but only covers one case.  Everything
contained in this sentence is contained and stated more clearly in later
sentences.

52.  (M) Section 5.1.3, delete the NOTE after Figure 19 or clarify.  If you
want to include it, I can come up with a thousand more "usage" notes.  Why
add this one only?

53.  (M) Section 5.1.3:  SET ERROR MODE and the rpt field are insufficient.
A general concept was established within SBP-2 that errors cause: 1)  the
associated fetch engine to go to the dead state, and 2) the task set to be
flushed.  Errors in the isochronous case are not exempted from this.  The
SET ERROR MODE command and the rpt field appear to change this for ALL
errors.  For the list of errors in section 12.3, I believe we want a
granularity.  For example, we might want to ignore missing CYCLE START
packets and Data CRC errors, but cause fatal errors if the other errors
listed occur.

54.  (E) Section 5.1.3:  Add a table that shows which fields are valid for
which command and, in appropriate cases, what values within a field are
valid on a per command basis.  For example, the stream_event field is only
valid for START, STOP, PAUSE or UPDATE CHANNEL MASK commands, and the values
that are valid for these commands depend on whether the stream is a listener
or a talker.

55.  (E) Section 5.1.3:  I believe the organization of this section could be
enhanced by making each of the commands described as subsections.  For
example, 5.1.3.1 would be the START command, 5.1.3.2 would be the STOP
command, etc.  This would require that the field definitions which follow
the command descriptions be moved to a position before the definition of the
commands.  Some of the information associated with the field usage should
then be moved into the command definitions.  I believe the resulting clarity
would be of great benefit.

56.  (N) Section 5.1.4, Table 2:  delete the entry for TERMINATE TASK, make
the value Reserved for future standarization.  Section 10.2 states "Targets
shall support, at a minimum, a basic task management model.", section 10.4.6
states "Targets that implement the basic task management model shall not
support TERMINATE TASK...".  This means that TERMINATE TASK shall not be
supported by any SBP-2 device.  Why are we definiting a command that can not
be used?  Remove this command from the table and delete section 10.4.6 and
any refereneces in SBP-2 to TERMINATE TASK through out this standard
including any reference in any changes I may have recommended.

57.  (N) Section 5.1.4, first paragraph below Figure 21:  add the following
sentence:  "The notify bit shall be set to one by the initiator and the
target need not check the notify bit and shall always return a status for
any completed management ORB."  I can find no method that an initiator can
determine if a management command completed if a target should decide to not
return a status when a command completes without error.  The above behavior
must be mandatory.

58.  (N) Section 5.1.4, Table 2:  I believe we need to allow command sets
the freedom to define an additional management command if such a command is
required by the functionality of the device type.  Change "5-6  Reserved for
future standardization" to two entries "5   Command set specific" and "6
Reserved for future standardization".

59. (M) Section 5.1.4.1, first paragraph after Figure 22:  states that the
usage of password data is beyond the scope of this standard, yet Annex C
(Normative) defines it.  This is inconsistant.

60.  (M) Section 5.1.4.1, second paragraph after Figure 22:  add "The
login_response_length shall be set to a value of 12 by the initiator and may
be ignored by the target."  The length of the login response is fixed and it
make no sense to allow the initiator to set a different value nor cause the
target device to check for a minimum length.

61.  (M) Section 5.1.4.1, second paragraph after Figure 22, last sentence,
change "no response data shall be stored" to "with the exception of a
transport error during the transmission of the login response, the target
device shall not send a login response."  I have argued repeatedly that the
term "shall be stored" is insufficient.  Does it mean that the target shall
not send or that the host shall accept it and keep it around until the
status is received and then, based upon the status, store it or throw it.

62.  (M) Section 5.1.4.1, sixth paragraph after Figure 22, add a sentence:
"The status_FIFO field is subject to the definition of the status_FIFO field
for all management commands."

63.  (M) Section 5.1.4.1, Figure 23 show the length field to be a value of
12, and in the paragraph below Figure 23 change the paragraph to read "The
length field shall specify the length, in bytes, of the login response data
and shall be 12."  The login response data is useless unless complete and
there is no reason to force checking for odd conditions.

64.  (E) Section 5.1.4.2, third paragraph after Figure 24, delete "and
status_FIFO" as this is already defined.  Change the wording of the second
sentence from "All of these buffers" to "This buffer" and "these addresses"
to "this address".

65.  (M) Section 5.1.4.2, first paragraph after Figure 25, move the last
sentence to be the second sentence and then add the following sentences
after the last:  "The target shall limit the transmission of the login
response to the length specified in the query logins ORB.  If the query
login response is smaller than the buffer allocated by the initiator, the
target shall not pad the response to meet the allocated length."

66.  (M) Section 5.1.4.3, Figure 26:  the channels field is too long.  It
should be shortend to 6 bits.

67.  (M) Section 5.1.4.3, there is no way to indicate during the create
stream process whether stream control is to be accomplished via a stream
control agent or via some other means as indicated in section 4.5, 4.7, and
Annex F.  A 2 bit field in the create stream ORB should be assigned to
indicate the method of stream control.  A value of zero can mean via a
stream control agent, a value of one can mean via AV/C as defined in IEC
61883, the value of 2 and 3 should be reserved.

68. (M) Section 5.1.4.3, the table after Figure 26 has for value of zero an
unstructured format.  In discussions within the committee, it was suggested
that such an unstructured format may mean to meter out the data in the file
in a fashion that would imply the contents of the data on the media did not
include any isochronous packet headers and was encapsulated into isochronous
packets of fixed size by the stream engine.  If this is so, how is the
packet size communicated to the stream engine?  To do this as part of the
create stream is one option, another is to have a stream control command
which does it.  Neither are defined in this standard.

69.  (M) Section 5.1.4.3, in the table after Figure 26 change the term
"structured" in the name entry for values of 2 and 3 to "Isochronous data
interchange format", as it is called in section 11.  Also add "(See Clause
11.)"  I believe other structured formats may be defined in future versions
or addendums to this standard, so the name should be explicit and not
general.

70.  (M) Section 5.1.4.3, in the paragraph describing max_aggregate_payload
add a sentence to the effect "This information is provided to the target to
aid it in the determination if sufficient internal resources are available.
During operation, the target device is not required to check to see if this
limit is exceeded.

71.  (M) Section 5.1.4.3, in the paragraph describing create_stream_response
and create_stream_response_length, add the following sentence:  "The value
of create_stream_response_length shall be set to 24 by the initiator and may
be ignored by the target." The length of the create stream response is fixed
and it make no sense to allow the initiator to set a different value nor
cause the target device to check for a minimum length.

72.  (M) Section 5.1.4.3, Figure 27, change command_block_agent to
stream_command_block_agent.  The command_block_agent was returned in the
login response, this field is not the same and should have a unique name to
prevent confusion.  Also, change all occurances of command_block_agent to
stream_command_block_agent where appropriate in this section (and throughout
the document?).

73.  (M) Section 5.1.4.3, in the second paragraph below Figure 27, add a
sentence "If the create stream request indicated that flow control was by a
means other than a stream control agent, then stream_control_agent field is
reserved."

COMMENT:  I wonder how many other things haven't been considered as required
options for the create stream command.

74.  (M) Section 5.1.4.4, first paragraph provides information on operation
which typically is not included in section 5.  This information should be
moved to section 8.3.

75.  (E) Section 5.1.4.6, FIgure 30:  the ORB_offset field should be changed
to ORB_offset_lo as indicated in the text below.

76.  (M) Section 5.1.4.6, change "TERMINATE TASK or ABORT TASK" to "ABORT
TASK".

77.  (M) Section 5.1.4.6, in the paragraph defining the function field,
delete "TERMINATE TASK".

78.  (M) Section 5.1.4.6, add a new paragraph after the NOTE:  "If the
login_ID is that obtained from a create stream response, then the task
management function applies to both the stream control and stream command
task sets."

79.  (E) Section 5.2, second paragraph, why is via in italics?

80.  (E) Section 5.2, second paragraph, add the following sentence before
the last sentence in this paragraph: "Each page table element is eight bytes
in length."

81.  (E) Section 5.2.2, first paragraph, change "data_length less than or
equal to" to "data_length less that or equal to data_size * 8 and less than
or equal to".  This adds wording similar to that in the first paragraph of
section 5.2.1.

82.  (E) Section 5.2.2, add the following to the last sentence of the NOTE:
"i.e., page_size is equal to 4."

83.  (E) Section 5.2.2, in the table, change the column heading "Element" to
"Element position in the page table", change "0" to "First", "1 - n-2" to
"Middle", "n-1" to "Last", and swap the table entries for "1 - n-2" and
"n-1" under column labeled "2".  I have had more questions from the
engineers that work for me about this table than any other portion of this
document.  When I have redrawn this table as I suggest here, the idea has
become immediately clear.

84.  (E) Section 5.2.3, first paragraph, next to last sentence, change from
"Otherwise, the target shall store the status block at the status_FIFO
address provided by the initiator as part of the login or create stream
request." to "Otherwise, the target shall store the status block at the
status_FIFO address provided by the initiator as part of the login, if the
ORB to shich the status pertains was a normal command block, or create
stream request, if the ORB to which the status pertains was a stream command
block or a stream control block."

85.  (M) Section 5.2.3, first paragraph, add the following to the end of
this paragraph "Unsolicitated status associated with a specific task set,
but not a specific task, shall be reported to each initiator logged in to
that task set."

86.  (M) Section 5.2.3, first table after Figure 33, add the following text
to the description for value 3 "Such a status block can only be placed on a
status_FIFO identified during a create stream command."

87.  (M/E) Section 5.2.3 does not describe all status formats and values.
Section 12.3 defines formats and values associated with isochronous streams.
These two sections overlap in some areas and disagree in others.  Those
portions of 12.3 that define status formats and fields should be moved to
section 5.2.3.

88. (E) Section 6.4, the paragraph follow table in that section describes
how the base address is obtained for the normal command agent.  It should be
expanded to state how the base is obtained from the create stream.  Change
this paragraph to read:
"The base address of each set of fetch agent's CSR's is obtained from:
- the command_block_agent field in the login response returned by the target
as part of a successful login,
- the stream_command_block_agent field in the create stream response return
by the target as part of a successful create stream, or
- the stream_control_agent field in the create stream response return by the
target as part of a successful create stream, if one is provided.

89.  (E) Section 6.4.3, first paragraph after Figure 37, doesn't read
clearly to me.  I suggest replacing this paragraph with the following: "The
ORB_offset_hi and ORB_offset_lo fields together form an ORB_offset field.
The Serial Bus address used to fetch an ORB shall be formed from the
concatenation of the 16-bit node ID of the initiator (available to the
target as a result of a login), the ORB_offset field and two least
significant bits of zero."

90.  (M) Section 7.1, first paragraph.  Add the following sentence to the
end of the paragraph:  "The results of reads to other portions of the
configuration during the initialization process is unpredictable."

91.  (M) Section 7.2, in the paraphgraph describing max_rec, delete the
second sentence.  While this statement is true for 1394A, 1394B will break
this.  Since this limit is in the base standard, it need not be repeated
here and imply a limit imposed by SBP-2.

92.  (M) Section 7.4.8, Figure 52 and related text, and section 7.5.4:  The
mgt_ORB_timeout field is not a logical unit characteristic, it is a unit
(target) characteristic.  In fact, if there are multiple logical units with
different characteristics, there could be multiple instances of this entry,
and there is no mandate that this field be consistant throughout.  I suggest
a "Unit_Characteristics" entry be defined that contains this field.

93.  (E) Section 7.6 shows the first quadlet of the leaf as having a size
and CRC.  This quadlet exists for the unit directory and the logical unit
director but sections 7.4 (unit directory) and 7.5 (logical unit directory)
do not mention these fields.

94.  (E) Section 8, first paragraph talks about commands to a target when it
is discussing commands to a logical unit.  Change the paragraph to read:
"Before an initiator may signal commands to a logical unit or task
management requests to a target related to a logical unit, access privileges
shall first be granted by the target. The criteria for the grant of access
may include resource availability or other target requirements. This section
specifies the target facilities that support access control and the methods
by which an initiator requests access to a logical unit and eventually
relinquishes access when it is no longer required."

95.  (E) Section 8.1, second paragraph, first bullet:  change "and the
login_ID used by the initiator to identify the login" to "and the login_ID
returned to the initiator in the login_response data and used by the
initiator to identify the login."

96.  (E) Section 8.2, change title from "Login requests" to "Access
requests" as 8.2.2 contains a description of create stream operation.

97.  (E) Sectoin 8.2.1, change the Note to read:
"NOTE - The speed at which the block write request to the MANAGEMENT_AGENT
   register is received shall determine the speed used by the target for:
   - all subsequent requests to read the EUI-64 from the initiator's
     configuration ROM
   - all subsequent requests to read ORB's from initiator memory, or store
     status at the initiator's status_FIFO associated with the logical unit
     once
     access to the logical unit has been granted to the initiator.
Command block ORB's separately specify the speed for requests addressed to
the data buffer or page table."

98.  (M) Section 8.2.1, second paragraph after the Note:  change "The target
shall perform the following..." to "The target shall perform, in any order,
the following...".

99. (M) Section 8.2.1, in the list of items to be validated, labeled "a)"
through "e)", item "a)" is not a validation but a step in performing the
validation contained in "b)".  Merge these two bullets to make on validation
step.

100.  (M) Section 8.2.1, in the list of items to be validated, item "e)" is
not a validation step, but a function performed by the target.

101.  (M) Section 8.2.1, item "e)", change the first sentence to "The target
shall determine if a free login_descriptor is available for the logical
unit."  The target might choose to support multiple initiator access to its
logical units, but reserve atleast one login_descriptor for each logical
unit thus preventing the initiators using up all of the login_descriptors to
access a single logical unit.

102.  (M) Section 8.2.1, after the list of validation items, add the
following note:  "NOTE - In the case of an unsuccessful login request,
target access of the EUI-64 may or may not have occurred."

103.  (E) Section 8.2.1, an observation:  This section (and similarly
section 8.2.2 in regards to create streams) covers some of the actions of
both the initiator and the target.  For example, the text says that the
initiator signals the login ORB to the target, and we state that the targer
reads the EUI-64 and returns a login response, but we never say the target
reads the ORB nor that the target returns a status.  I feel that we should
make this be a more definitive list of the actions of both side.

104.  (M) Section 8.2.2, in the paragraph after the three bullet items, we
need to indicate that a target may use the mode of operation, listener or
talker, in determining whether resources are available.  Change the
paragraph to read "The mode of operation, listener or talker, and the
maximum number of channels to be supported may be used by the target to
allocate sufficient and appropriate resources."

105.  (M) Section 8.2.2, item "b)" in the list of things a target validates
for a create stream is not a validation item, but a resource allocation.
Merge the lead in sentence to the list with item "a)" and make item "b)" a
separate paragraph.

106.  (M) Section 8.2.2., item "b)", first sentence, change to read "if a
free login_descriptor is available" to "if a free stream_descriptor for the
stream is available". The term login_descriptor is applied to both logins
and create stream and there is a different set of information that needs to
be stored in each case.  The term login_descriptors should be reserved for
login operations, and the term stream_descriptor for create streams.

107.  (E) Section 8.3, first paragraph, last sentence, change to read "Both
the stream command block and stream control requests fetched prior the the
bus reset shall continue to be executed by the target but the return of
status shall be deferred until a successful reconnection.  New stream
command block and stream control requests shall not be fetched until a
successful reconnect to the underlying logical unit is complete."

108.  (N) Section 8.3, second paragraph introduces the "one second"
reconnect time.  This value needs a minimum and a maximum number.  No one
can guarantee exactly one second for many reasons such as the reference
clocks are typically +- 100 ppm, and  the timeout is likely to be
implemented in software.  The target detection should be 1.0 second minimum,
1.25 (?) seconds maximum, and the initiator should reconnect within 1.0
seconds.

109.  (M) Section 8.3, second paragraph, first sentence contains "reconnect
login ID and associated stream ID's."  This seems to imply that there are
separate reconnects for each stream where it is stated in item "c)" and "d)"
below that when an initiator reconnects to a logical unit, any streams
associate with that logical unit are also re-established.

110.  (M) Section 8.3, in the list of items "a)" to "d)", combine items a)
and b) as item a) is not a validation, but what must be done before the
validation in step b) Is performed.  Items c) and d) are also not validation
steps.

111.  (M) Section 8.3, insert the following sentence after items a) through
d):  "The fetch agent for the logical unit to which the reconnect was
accomplish shall be in the reset state upon completion of a successful
reconnect."

112.  (M) Section 8.3, last paragraph.  Is the status_FIFO in the
login_description the value in the original login request or the value in
the reconnect request, or is it required that the value in the reconnect be
the same value as was in the original login request?

113.  (N) Section 8.4, add an additional paragraph to the end of this
section: "Upon a successful logout specifying a login_ID obtained during a
login, any streams associated with that logical unit connection are also
logged out."

114.  (E) Section 9.1, first paragraph, second sentence, change "and refuses
subsequent Serial Bus transactions" to "and indicates a resource conflict
via either a ack_conflict or resp_conflict_error to another writes to the
address of the management ORB"

115.  (E) Section 9.1, second paragraph, first sentence, change "The other
target agents, command block and stream control," to "The other target
agents, normal command block, stream command block and stream control".

116.  (E) Section 9.1, paragraph 3, first sentence, change "either be null
or point to" to "either be a null pointer or point to".

117.  (E) Section 9.1.1, add one a note at the end of the section:  "NOTE -
Initialization does not require that the first command block signaled to the
fetch agent be a dummy ORB, nor does it require that the list containing
only a single command.  A linked list contain one or more commands can be
used to both execute the commands and to initialize the fetch engine."

118.  (E) Section 9.1.2, paragraph after item "c)", last sentence, change
"all or part of an ORB" to all or part of the ORB pointed to by the
ORB_pointer register".

119.  (M) Section 9.1.2, add the following to the NOTE:  "Write requests to
the agent registers by nodes other than the logged in initiator have no
effect upon the fetch agent state machine."

120.  (E) Section 9.1.3, change first paragraph to read:  "Any initiator
application that executes in a single-threaded environment, such as DIOS,
has little need of the target fetch agent's capabilities to manage multiple
outstanding requests. Such applications may use a simpler procedure than
that described in 9.1.2 to signal requests to the target.  Subsequent to
initialization of the target fetch agent by means of a write to the
AGENT_RESET register, the BIOS may signal one request at a time to the
target as follows:"

121.  (N) Section 9.1.4, Figure 58: add the following changes:
a)  For F0:F1, change the the transition condition from
"TR_DATA.indication(WRITE,ORB_POINTER)" to "Logged In and
TR_DATA.indication(WRITE,ORB_POINTER)".
b)  Add an F0:F0 transition condition labeled:  "Not logged in"
c)  Add a transition Any:F0c with transition condition labeled "Logout"
d)  Change F1:F1 transition to F1:Fnew.
e)  Add new state Fnew, call it "Wait for next ORB to be returned", set
"AGENT_STATE.st =3D ACTIVE"
f)  Change F1:F2 transition to Fnew:F2
g)  Change F3:F2 transition to F3:Fnew (The ORB_pointer register is defined
such that it does not have the ability to have a null pointer.  The null
pointer flag is reserved and writing to it is ignored.)
h)  On F3:F4 transition change "doorbell variable equal to one" to "target
resources available and doorbell variable equal to one"

Make changes to the text describing the state machine (some of which are in
following comments).

122.  (M) Section 9.1.4, Text describing transition Any:F0b:  Add the
following sentence at the end:  "If a read request for an ORB is
outstanding, the subsequent resonse (if any) should be accepted but the
content of the response should be discarded."

123.  (E) Section 9.1.4, Text describing transition F0:F1, change in last
sentence "with a response of COMPLETE" to "with an ack_complete or an
ack_pending followed by a response containing resp_complete."

124.  (M) Section 9.1.4, Text describing transition "F1:F1" to "F1:Fnew".

125.  (M) Section 9.1.4, Text describing transition "F1:F2" to "Fnew:F2".

126.  (M) Section 9.1.4, Text describing transition "F3:F2" to "F3:F1".
Delete the phrase ", set the next_ORB variable to the value of the
ORB_POINTER register", change "F2" to "F1" and delete the phrase ", from
which state an immediate F2:F1 transition follows."

127.  (M) Section 9.1.4, Text describing transition F4:F2, delete the last
sentence.

128.  (M) Section 9.1.4, Text describing transition Any:F5, the list of
errors gives an indication that only errors associated with the fetching
process cause this transition.  Add two new bullets "- any device level
error" and "- any transport error encountered during the transfer of data or
status related to a command being processed that was fetched via this fetch
agent."

129.  (M) Section 9.1.4, Text describing transition F5:Dead, change
"AGENT_STATE" to "DOORBELL".  The AGENT_STATE register is read only.

130.  (M) Section 9.2, change the title of the section from "Data transfer"
to "Data transfer (normal commands only)".

131.  (M) Section 9.2, second paragraph, add a new sentence to the end of
the paragraph "The target is also responsible for generating the proper
system memory address appropriate for the transfer being performed."

132.  (N) Section 9.3, related to the last paragraph before the note.  We
have never included any text to define how to reclaim an ORB that returns a
status with the src field equal to one.  After this last block is updated
with a new ORB pointer value and the doorbell is rung, when can the old ORB
be discarded?  One way is to monitor the ORB pointer and see if it has
changed.  This would require polling.  Another is to wait until the ORB
whose address was placed in the old ORB completes.  This could be a long
time if a linked list is appended and the device does out of order
transactions.  I don't have a fixed solution, but we need one.

133.  (M) Section 10.1, third paragraph, change the fourth sentence from
"There is a one-to-one relationship between a stream identifier and a stream
task set; there may be multiple stream task sets associated with a logical
unit." to "There is a one-to-one relationship between a stream identifier
and a stream task set.  There may be zero or more stream task sets and one
normal command task associated with a logical unit.  If there is a stream
task set associated with a logical unit, there will be a normal command task
set as well."  In the last sentence of the paragraph, change "there are no
interactions between tasks that belong to different stream task sets." to
"there are no interactions between tasks that belong to different task
sets."

134.  (M) Section 10.2, fourth bullet, change "All tasks within a task set",
to "All active tasks".

135. (N) Section 10.3, item "a)" change "of the fetch agent" to "of all
fetch agents".

136.  (N) Section 10.3, between item "b)" and "c)" add an additional item to
read "If more than one initiator is logged in to the logical unit, a unit
attention condition is declared for each of the other initiators.  For each
such initiator, if the unsolicited_status_enable variable is set an
unsolicited status is sent, else the attention condition is retained until
it can be signaled to the associated initiator."

137.  (E) Section 10.4, add to the end of the sentence "and the rq_fmt field
of the command ORB to perform task management."

138.  (E) Section 10.4.1, first paragraph, second sentence, change "targets
may also recognize task management ORB's to abort tasks." to "targets may
also recognize ABORT TASK ORB's."

139.  (E) Section 10.4.1, item "a)" of first set, contains a NOTE.  Make it
a NOTE.

140.  (E) Section 10.4.1, change paragraph after item "c)" of first set to
"Mandatory support for abort task requires the target to recognize..."

141.  (E) Section 10.4.1, in item "d)" in second set, change "REQUEST" to
"REQUEST COMPLETE".

142.  (M) Section 10.4.1, add the following paragraph to the end of this
section:  "The fetch agent associated with the login ID shall not be
transitioned to the dead state due to the processing of an abort task or a
Dummy ORB."

143.  (M) Section 10.4.2, in item "a)", change "task set" to "login ID".

144.  (E) Section 10.4.5, first sentence, chang "all initiators" to "all
logged in initiators".

145.  (M) Section 10.5, the table does not include a write to the AGENT
RESET register.

146.  (M) Section 10.5, the table:  for Faulted command, CLEAR TASK SET and
LOGICAL UNIT RESET, should transition all tasks in the task set for all
logged in intiators and transition all associated fetch engines to dead.

147.  (M) Section 10.5, the table:  for ABORT TASK SET, should transition
only the initiators fetch engine to dead and abort the only those commands
in the task set which belong to the initiator.

148.  (M) Section 10.5, the table: for TARGET RESET, transition all fetch
agents to dead.

149.  (M) Section 10.5, in third paragraph below the table, add to the end
of the first sentence "and any pending status are discarded."

150.  (M) Section 10.5, in fourth paragraph below the table, fourth
sentence: change to read "For normal command block requests, the task set is
empty and the fetch agent is in the dead state.  The initiator must
initialize the fetch agent before signaling new ORB's to the target."

151.  (E) Section 11 should be reorganized as follows:
11.  Intro to recorded information and relationship of Data Format Records
and cycle mark index entried.  explaination that, in the case of CIP format,
the internal format of isochronus data packets must be understood in order
to process the stream.
11.1 Data Format Records
11.1.1 Cycle Marks
11.1.2 Isochronous data packets
11.1.3 Null packets
11.2 Cycle mark index
11.3 Common isochronous packets

152.  (M) Section 11, the last paragraph should be moved to the section 11.2
on Isochronous data packets.

153.  (M) Section 11.1, the first sentence of the first paragraph and the
last paragraph in this section both contain information on operational
characteristic, not formats.  This information should be moved to section
12.

154.  (M) Section 11.2, in paragraph below figure 60, add "A data length of
zero is valid in which case the packet shall consist of only the header and
shall be one quadlet in length."

155.  (E) Section 11.2, in the table entry for the value of 1, P1394A says
"specified by IEC 61883/FDIS", should we add this information to this table?

156.  (M) Section 11.2, in the first paragraph below the table, change "may
have been transformed" to "shall be transformed".  It is transformed even if
the transformation causes no change in values.

157.  (E) Section 11.4, the first paragraph, add the following to the end of
the paragraph:  "Whether a cycle mark is recorded is determined by the idf
field of the create stream ORB used to establish the stream."

158.  (E) Section 11.4, the first paragraph seems to operational information
and should be moved to section 12.

159.  (M) Section 11.5 repeats a definition contained in a normative
reference which is still in the development stage.  This provides an
opportunity to have inconsistancy between these two standards.  Also see
section 12.2.3 which says "The common isochronous packet (CIP) format, as
standardized by IEC 61883/FDIS, ...".

160.  (E) Section 11.5, figure 64:  change the field "fmt-dependent" and any
textual references to "fmt_dependent".

161.  (M) Section 11.5, paragraph below figure 64 says the sid field "shall
specify the Serial Bus physical ID of the source (talker) for the
isochronous data." and then continues on to say that, when talking, we
substitute in a value for this field from a table and not that we should use
our bus ID.  This is inconsistant.

162.  (M) Section 11.5, second paragraph below figure 64, add an additional
sentence:  "The application data field shall not contain partial data
blocks."

163.  (M) Section 11.5, fourth paragraph below figure 64, add to last
sentence "and recorded when the target is a listener."

164.  (E) Section 11.5, figure 66, names a field the same name as used in
figure 64.  This is confusing and could easily be changed to another name.

165.  (M) Section 12, first paragraph, last sentence, change the sentence to
read "This section describes how an initiator may control isochronous data
transfers when a target is either the talker or a listener on Serial Bus."
The sentence had implied that there might be some form of cooperation going
on.

166.  (E) Section 12, in third bullet item, chang "stream command block
requests" to "stream command ORB's".

167.  (M) Section 12, the last paragraph, second sentence says we don't
define connection management and provides no reference to where such a
definition might be found, but the section states it is involve (required).

168.  (M) Section 12.2, add (Optional) to the title line.  Change "is" in
first line to "may be".

169.  (M) Section 12.2.1, what does the first sentence mean?

170.  (M) Section 12.2.1, second paragraph states that the channel mask can
only be changed if the stream is stopped, but I can visualize some cases
where this it may be desireable to change it on the fly.  Did we impose this
restriction?  If not, who/what/where did this restiction come from?

171. (M) Section 12.2.2, second paragraph, delete the last 2 sentences.
This operation in the case of STOP is in conflict with section 5.1.3.  In
the case of pause, the information stated is very much implementation
dependent.

172.  (E) Section 12.2.3, first paragraph, first sentence, delete "both".

173.  (E) Section 12.2.3, second bullet in second set of bullets, add after
"isochronous source packet header" ", if present."

174.  (E) Section 12.2.3, in paragraph before the first formula and in the
formula itself:  why not just do the calculation using syt.cycle_time?
Change in the text: "For the syt field" to For the cycle_time portion of the
syt field", and change the formula to: "syt.cycle_time(stored) =3D (16
+syt.cycle_time(observed) - CYCLE_TIME) % 16".  This uses only the field in
question and fixes the wrap around error that isn't covered explicitly in
the formula (although any implementation, in the process of making the
results fit into 4 bits would have to do the modulo limitation).  In the
text in the paragraph after this formula, we use text where a formula is
better suited.  Again, we see an interesting masking sequence that could be
simlified if syt.cycle_time is used, plus it looks like the mask value in
the current text is incorrect.

175.  (M) Section 12.3, in the second set of bullets, for all three bullets,
delete that portion of the items that refers to "the current stream control
ORB".  The paragraph above talks about the ORB used to set the mode, so the
term "the current stream control ORB" must be refering to the ORB setting
the mode.  This is not what was intended.

176.  (M) Section 12.3, in the second set of bullets, the first bullet, does
"and stop execution" mean the same thing as a STOP command?

177.  (E) Section 12.3, combine the paragraph after the second set of
bullets with the paragraph before the second set of bullets.  The way it is
we say that the SET ERROR MODE sets the modes, here are the modes and, by
the way, here is the field name that does it.  Why not state the field name
in the SET ERROR MODE command initially?

178.  (E) Section 12.3, figure 67:  the stream_error field is actually the
sbp_status field.  Why change the name?

179.  (E) Section 12.3, the status format and value information contained in
this section belongs in section 5.3 on the status block.  Also, some of the
values are inconsistant with the status scheme set up in section 5.3.

180.  (M) Section 12.3, in the table after Figure 67, add a not to the
descriptions for error values 2 and 3 "the isochronous packet is not
recorded on the media."

181.  (M) Section 12.3, add to the table after Figure 67 an error meaning
"found a data record which exceeded the maximum record size allowed for the
speed allowed for transmission."

182.  (E) Section A.1, last paragraph, after "shall report" "a value equal
to or greater than".

183.  (E) Section A.2, in the paragraph starting "Once a target", change
"target" to "node".  A target is equivalent to a unit, not a node.

184.  (E) Section B.2, in the first paragraph after the second table, change
"shall specify the content" to "shall specify the validity of the content".

185.  (E) Section D.1.1, third paragraph has "See C.2.2" should be "See
D.2.2".

186.  (M) Section F.8, a serial bus reset may cause the normal command block
agent set to be initialized, but does not affect the isochronous streams.
The definition of hard reset, I believe, is to make the unit go to the same
state as a power on reset.  This isn't true for an SBP-2 device.

187.  (E) Section G, second paragraph, change "April 22, 1977" to April 22,
1997".  Also, this standard has just been updated, so the date and revision
is outdated.

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

Comments attached to YesC ballot from Jeffrey L Williams of=20
Western Digital Corporation:

1) In section 3.1.2.5 initial register space is defined as 2KB starting at=
=20
FFFF F000 0000 hex. In section 3.1.2.6 initial units space is defined as=
 being

adjacent to and above initial register space and at an address of FFFF F000=
=20
0400=20
hex. This is only 1KB above initial register space. Shouldn't initial units=
=20
space start at FFFF F000 0800 hex?

2) Table 1 in section 5.1.2.1 indicates data transfer speed codes above 3=
 are=20
as defined by P1394a. P1394a defines about three different code values to=20
represent the same speed. This reference needs to be more specific.

3) Section 5.1.4.2, text states "The node_ID field of an entry shall specify=
=20
the node ID of a logged-in initiator. If a Serial bus reset has occurred=
 since

the login was established and the initiator has not reconnected the login,=
 the

node_ID field shall have a value of FFFF hex." The text should also indicate=
=20
that the FFFF hex return value is qualified by the fact that the reconnect=
=20
timeout has not expired.

4) Section 5.2.2, it is not clear what src value should be used for=
 management

ORBs. Section 9.3 appears to imply that management ORBs return status with a=
=20
src of zero.

5) Section 5.3, states that targets shall store a minimum of eight bytes of=
=20
status information, however, no minimum value is stated for the len field.=
=20
In order to meet the minimum eight byte status block requirement len has a=
=20
minimum required value of 1 as currently defined. This could be clarified.

6) Section 5.3, text in the table for the resp field indicates that=
 sbp_status

may contain additional information when the resp field contains two (ILLEGAL=
=20
REQUEST), however, later in the same section=A0 a note indicates that when=
 resp=20
equals two then sbp_status shall be set to FF hex. Which is correct?

7) Section 8.2.1, the note in this section indicates that the speed at which=
=20
the block write request to the MANAGEMENT_AGENT register is received shall=
 be=20
saved and used by the target for all subsequent requests to read the=20
initiator's=20
configuration ROM, fetch ORBS, and store status. When a serial bus reset=20
occurs=20
followed by a reconnect the new speed associated with the reconnect should=
=20
replace that stored during the login. The serial bus reset may be due to a=
=20
topology change which may affect the speed at which the initiator can be=20
accessed by the target. Adding the same note in section 8.2.1 to section 8.3=
=20
resolves this.

8) Section 7.2, Does max_rec affect response packets received by the node?=
=20
This should be clarified by the text for the max_rec field in this section.

9) Section 8.1, the third bullet implies that the reconnect timeout is two=
=20
seconds when it is actually one second.

10) Section 8.2.1, items b, c, d define situations where the login request=
=20
is rejected. No specific return status is indicated for login rejections.=20
Which status return code is appropriate for each of the conditions outlined?

11) Section 8.2.1, item d ends with the text "reject the login request;=
 and".=20
Is there something missing here or is it just a typo?

12) Section 8.2.1, item e indicates that the target checks for free=20
login_descriptors but makes no mention of what should occur if none are=
 free.=20
I assume this results in another login rejected?

13) Section 10.4.2, item d uses the terminology "recently completed tasks".=
=20
This is not completely clear. Better definition would help here. Are these=
=20
tasks that have completed all data transfer but not status? Tasks in some=20
other state?

14) Section 10.4.1, paragraph beginning "A Second method to abort tasks...",=
=20
The wording implies that this is a second method of aborting tasks when it=
 is=20
just a clarification of the relationship between Abort Task and stream task=
=20
sets. Also it mandates Abort Task be supported by targets that support=20
streams.=20
This means hard disks supporting streams must support Abort Task. Why is=
 this=20
necessary? I would rather not have the requirement to support Abort Task in=
=20
association with Streams.

15) Section E.2, The first sentence currently reads "A write to the=20
ORB_POINTER=20
register is valid only when the target fetch agent is into be in the RESET=
 or=20
SUSPENDED state. The text "into be" should be deleted.

16) Section 5.1, In the paragraph below Figure 14 the text "...if not=20
specified=20
in the ORB. at the address supplied..." should contain a comma after ORB=20
rather
than a period.

17) In various places throughout the document the status FUNCTION_COMPLETE=
 is=20
indicated. There is no such status returned defined these shall all be=20
replaced=20
with REQUEST_COMPLETE.=20

******************** End of Ballot Report ********************

--
John Lohmeyer                  Email: john.lohmeyer at symbios.com
Symbios, Inc.                  Voice: +1-719-533-7560
4420 ArrowsWest Dr.              Fax: +1-719-533-7036
Colo Spgs, CO 80907              BBS: +1-719-533-7950

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




More information about the T10 mailing list