T10/08-093r0 Voting Results on T10 Letter Ballot 08-092r0 on Forwarding SAS-2 to First Public Review Ballot closed: 2008/03/28 12:00 noon MDT Organization Name S Vote Add'l Info --------------------------------- -------------------- - ---- ---------- AMCC Paul von Stamwitz P Yes Amphenol Interconnect Gregory McSorley P Yes Brocade David Peterson P Abs Cmnts Dell, Inc. DNV EMC Corp. Mickey Felton A Yes Emulex William Martin P Yes Cmnts ENDL Ralph O. Weber P Yes FCI Douglas Wagner P Yes Finisar Corp. Chris Cicchetti A Yes Foxconn Electronics Elwood Parsons P Yes Fujitsu Mike Fitzpatrick P Yes General Dynamics Nathan Hastad P Yes Hewlett Packard Co. Rob Elliott P No Cmnts Hitachi Global Storage Tech. Dan Colegrove P Yes IBM Corp. Kevin Butt P No Cmnts Intel Corp. Mark Seidel P No Cmnts Iomega Corp. Robert Payne P Yes Kawasaki Microelectronics Am Joel Silverman P Yes KnowledgeTek, Inc. Dennis Moore P Yes Cmnts Lexar Media, Inc. John Geldman P Yes LSI Corp. John Lohmeyer P No Cmnts Marvell Semiconductor, Inc. David Geddes P Yes Maxim Integrated Products Gregory Tabor P Yes Cmnts Microsoft Corp. Robert Griswold A Yes Molex Inc. Galen Fromm A Yes Network Appliance Frederick Knight P Yes Nvidia Corp. Mark Overby P Yes PMC-Sierra Tim Symons P No Cmnts Quantum Corp. Paul Suhler P Yes Samsung Michael Rogers A Yes SanDisk Corporation Avraham Shimor P Yes Seagate Technology Gerald Houlder P No Cmnts STMicroelectronics, Inc. Stephen Finch P Yes Sun Microsystems, Inc. Vit Novak A Yes Symantec Roger Cummings P Abs Cmnts TycoElectronics Dan Gorenc A Yes Western Digital Mark Evans P No Cmnts Ballot totals: (27:7:2:1=37) 27 Yes 7 No 2 Abstain 1 Organization(s) did not vote 37 Total voting organizations 12 Ballot(s) included comments This 2/3rds majority ballot passed. 27 Yes are more than half the membership eligible to vote [greater than 18] AND 27 Yes are at least 23 (2/3rds of those voting YES or NO [34]). Key: P Voter is principal member A Voter is alternate member Abs Abstain vote DNV Organization did not vote Cmnts Comments were included with ballot NoCmnts No comments were included with a vote that requires comments [This report prepared by LB2 v2.3.] ************************************************************** Comments attached to Abs ballot from David Peterson of Brocade: Our organization has no interest in the subject matter of this proposed standard. ************************************************************** Comments attached to Yes ballot from William Martin of Emulex: Emulex comment number 1 Page=52 Subtype=Highlight Author=bmartin Comment= this standard What part of this standard defines the ATA physical interconnect? Emulex comment number 2 Page=55 Subtype=Highlight Author=bmartin Comment= (see 6.7.4.2.3.4). Make see references at the end of definitions consistent either (see x.y) or See x.y. Emulex comment number 3 Page=55 Subtype=Highlight Author=bmartin Comment= a s.b. the a implies any zoning expander, while this refers to the zone manager that locked the zoning expander device that is being referenced. Emulex comment number 4 Page=55 Subtype=Highlight Author=bmartin Comment= A storage peripheral (analogous to a SCSI target device). Clarify this as a storage device that processes requests originated by an ATA host. Emulex comment number 5 Page=58 Subtype=Highlight Author=bmartin Comment= its s.b. the receiver's Emulex comment number 6 Page=58 Subtype=Highlight Author=bmartin Comment= The process performed by a management application client to discover all the SAS devices (see 3.1.197) and expander devices (see 3.1.77) in the SAS domain (see 3.1.198) that invokes the configuration subprocess (see 3.1.35) as needed. See 4.7. add comas as shown The process performed by a management application client, to discover all the SAS devices (see 3.1.197) and expander devices (see 3.1.77) in the SAS domain (see 3.1.198), that invokes the configuration subprocess (see 3.1.35) as needed. See 4.7. Emulex comment number 7 Page=60 Subtype=Highlight Author=bmartin Comment= wide connector There is no definition of "wide connector" modify this reference to refer to multiple phys or something of that nature. Emulex comment number 8 Page=60 Subtype=Highlight Author=bmartin Comment= narrow connectors There is no definition of "narrow connector" modify this reference to refer to single phy or something of that nature. Emulex comment number 9 Page=60 Subtype=Highlight Author=bmartin Comment= one s.b. two We never refer to a one bit field, we always refer to that as a bit. Emulex comment number 10 Page=60 Subtype=StrikeOut Author=bmartin Comment= prior This term is unnecessary and is confusing as I_T nexus is 2 definitions above this one. Emulex comment number 11 Page=61 Subtype=StrikeOut Author=bmartin Comment= prior This term is unnecessary and is confusing as to what is meant by prior. Prior in time or what? Emulex comment number 12 Page=61 Subtype=Highlight Author=bmartin Comment= 3.1.116 jitter, data dependent Change 3.1.116 to 3.1.120 to be the proper name not "jitter, qualifier" (e.g., "data dependent jitter" not "jitter, data dependent"). Emulex comment number 13 Page=62 Subtype=Highlight Author=bmartin Comment= (see 3.1.278) (see 6.7.4.2.3.4). do not put two parenthetical references next to each other. Emulex comment number 14 Page=65 Subtype=Highlight Author=bmartin Comment= IR or CR compliance point There is no definition of these points. They are mentioned in the text but only as points with no textual description that I can find. Emulex comment number 15 Page=67 Subtype=Highlight Author=bmartin Comment= (see 2.3). s.b. See 2.4 Emulex comment number 16 Page=67 Subtype=StrikeOut Author=bmartin Comment= 3.1.234 signal: The entire voltage waveform during transmission. The term signal is used in its normal dictionary definition as well as this narrow definition. I would suggest deleting this definition as the meaning of signal is well understood in context where it is used or possibly replace it with transmission signal. Emulex comment number 17 Page=67 Subtype=Highlight Author=bmartin Comment= signal see comment on 3.1.234 Emulex comment number 18 Page=67 Subtype=Highlight Author=bmartin Comment= signal see comment on 3.1.234 Emulex comment number 19 Page=70 Subtype=Highlight Author=bmartin Comment= IT or CT compliance point These are not defined. Emulex comment number 20 Page=70 Subtype=Highlight Author=bmartin Comment= transport s.b. SSP transport Emulex comment number 21 Page=70 Subtype=Highlight Author=bmartin Comment= transport s.b. SSP transport Emulex comment number 22 Page=70 Subtype=Highlight Author=bmartin Comment= transport s.b. SSP transport Emulex comment number 23 Page=76 Subtype=StrikeOut Author=bmartin Comment= Fields containing only one bit are usually referred to as the NAME bit instead of the NAME field. Unless there is a place where we refer to a one bit value as a field remove this sentence. Emulex comment number 24 Page=83 Subtype=StrikeOut Author=bmartin Comment= consisting of more than one bit see other comments on one bit fields Emulex comment number 25 Page=90 Subtype=Highlight Author=bmartin Comment= are s.b. is Emulex comment number 26 Page=90 Subtype=Highlight Author=bmartin Comment= wide why is this only for wide ports shouldn't this be for wide or narrow? If removing this wide, remove the next wide in this sentence. Emulex comment number 27 Page=94 Subtype=Highlight Author=bmartin Comment= An device s.b. An ATA device Emulex comment number 28 Page=95 Subtype=Highlight Author=bmartin Comment= Each expander device contains one SMP target port and one management device server, contains one SMP initiator port and one management application client if it is self-configuring and may contain one SMP initiator port and one management application client if it is not self-configuring, and may contain SAS devices (e.g., an expander device may include an SSP target port for access to a logical unit with a peripheral device type set to 0Dh (i.e., enclosure services device) (see SPC-4 and SES-2)). Make this an a) b) list Each expander device: a) contains one SMP target port and one management device server; b) contains one SMP initiator port and one management application client if it is self-configuring; c) may contain one SMP initiator port and one management application client if it is not self-configuring; and d) may contain SAS devices (e.g., an expander device may include an SSP target port for access to a logical unit with a peripheral device type set to 0Dh (i.e., enclosure services device) (see SPC-4 and SES-2)). Emulex comment number 29 Page=104 Subtype=Highlight Author=bmartin Comment= SSP initiator ports should poll all the logical units in the SAS domain with peripheral device types set to 0Dh to determine the source. Why should SSP initiator ports poll? Isn't this the responsibility of a specific management application? Emulex comment number 30 Page=108 Subtype=Highlight Author=bmartin Comment= Cann't this also be a configuration issue where they are attached to two different expanders in the same SAS domain? What mechanism is there to determine that they are in different SAS domains? Emulex comment number 31 Page=122 Subtype=Highlight Author=bmartin Comment=4.1.7 does not specify a maximum number of phys in the expander. Emulex comment number 32 Page=139 Subtype=Highlight Author=bmartin Comment= table to table is now allowed. This always reports an error on this. This needs to be qualified by whether the expander supports table to table routing. Emulex comment number 33 Page=145 Subtype=Highlight Author=bmartin Comment= Assumes that phys in the expanders are numbered counter clockwise from the left side. Emulex comment number 34 Page=151 Subtype=Highlight Author=bmartin Comment=this should just be and Emulex comment number 35 Page=151 Subtype=Highlight Author=bmartin Comment= shouldn't this be N/A since with zoning not enabled you cannot determine that a device has access to a specific zone group? Emulex comment number 36 Page=151 Subtype=Highlight Author=bmartin Comment= This table could collapse to three rows since the only dependency is that the zone manager password must match and the value of the zone manager password, Emulex comment number 37 Page=153 Subtype=StrikeOut Author=bmartin Comment= This is duplicated in table 28 with additional information in the table, so remove this. Emulex comment number 38 Page=156 Subtype=Highlight Author=bmartin Comment=make this item c, and delete the and at the end of item a) Emulex comment number 39 Page=157 Subtype=Highlight Author=bmartin Comment= If ZP[s, d] is set to a value, ZP[d,s] shall be set to the same value ZP[s,d] has to be set to a value. Reword to: ZP[d,s] shall be set to the same value as ZP[s,d] Emulex comment number 40 Page=162 Subtype=Highlight Author=bmartin Comment= bit set S.B. bit is set Emulex comment number 41 Page=167 Subtype=Highlight Author=bmartin Comment= This table should have one additional field to indicate whether a phy event is on a logical phy or a physical phy. 01h through 04h are definitely physical phy based and 06h and above are definitely logical phy based. 05h is the only one that is difficult to determine which layer it belongs in. Emulex comment number 42 Page=167 Subtype=Text Author=bmartin Comment= add the following sentence: "Phy events on all logical phys within a phy shall be counted in a single counter associated with the phy." Emulex comment number 43 Page=307 Subtype=Highlight Author=bmartin Comment= g) Phy Capabilities Bits Received with arguments indicating the supported settings bits received; There is no text or diagrams that indicate how this message is generated by the SP receiver. There are qualifications on when the SP receiver should be looking for the Phy Capabilities Bits based on the state of the SP state machine. Emulex comment number 44 Page=331 Subtype=StrikeOut Author=bmartin Comment= delete "If this state is entered from SP_DWS1:Valid1 or SP_DWS2:Valid2 and the DWS Reset Timeout timer has expired, this state may send a DWS Reset message to the SP state machine (e.g., if the phy chooses to initiate a new link reset sequence because dword synchronization has been lost for too long)." This paragraph is a subset of this last paragraph in this subclause. Emulex comment number 45 Page=338 Subtype=Text Author=nayalasomayajula Comment= Section 7.2.5.3.3 states that NOTIFY (POWER LOSS EXPECTED) should be transmitted 3 times, so this should be a triple primitive sequence? Emulex comment number 46 Page=363 Subtype=Highlight Author=bmartin Comment= This is not totally true when you are doing SSC in an expander. When doing SSC there is a need to have elasticity or some other buffering/insertion between the internal clock and the transmitter. Emulex comment number 47 Page=365 Subtype=StrikeOut Author=bmartin Comment= It shall increase or reduce that number based on clock frequency differences between the phy transmitting the dwords to the expander device and the expander device's receiving phy (e.g., if receiving at -100 ppm and transmitting at +100 ppm, it transmits fewer deletable primitives that it receives). Delete this sentence. This does not clarify the difference of three different clock domains that are caused by SSC. Emulex comment number 48 Page=365 Subtype=Highlight Author=bmartin Comment= that s.b. than Emulex comment number 49 Page=393 Subtype=Highlight Author=bmartin Comment= a s.b. of a Emulex comment number 50 Page=398 Subtype=StrikeOut Author=bmartin Comment=to Emulex comment number 51 Page=426 Subtype=Text Author=bmartin Comment= As in the SL state machines, there should be a global transition to the XL0 state if a Phy Layer Not Ready confirmation is received; however, if the XL state machine has a connection, it should send a Forward Break request to the ECM. This affects a number of states. Emulex comment number 52 Page=429 Subtype=Highlight Author=bmartin Comment= shall s/b may There should not be any dwords except idle or BREAK received while in this state, so a receiver should be allowed to delete dwords that are should not be here. Additionally in XL6, when a dword is forwarded it may send that dword or just send idles. Emulex comment number 53 Page=431 Subtype=StrikeOut Author=bmartin Comment=g) Emulex comment number 54 Page=435 Subtype=Highlight Author=bmartin Comment= This state cannot release all resources until a BREAK or BREAK_REPLY has been received. This requirement should be moved into the transition XL10:XL0 Additionally, This state shall repeatedly send: a) Phy Status (Connection) response to the ECM if this state was entered from XL8 or XL7; b) Phy Status (Partial Pathway) response to the ECM if this state was entered from XL3 or XL6 and an AIP Received (Waiting On Partial) message was not received; or c) Phy Status (Blocked Partial Pathway) response to the ECM if this state was entered from XL3 or XL6 and an AIP Received (Waiting On Partial) message was received. Emulex comment number 55 Page=435 Subtype=StrikeOut Author=bmartin Comment= This state shall send a Transmit BREAK message to the XL transmitter (see 7.15.12.2). This sentence should be deleted as it was replaced by the a-b list below. Emulex comment number 56 Page=436 Subtype=Highlight Author=bmartin Comment= c) the Break Timeout timer expires. If the Break Timeout timer expires, should another BREAK be sent. If another BREAK is not sent, and what was lost was the BREAK, then you still have part of the path tied up in a connection. Emulex comment number 57 Page=495 Subtype=Highlight Author=bmartin Comment= the SSP ... s.b. if the SSP target port supports the TLR CONTROL field, then the SSP ... note from previous page - if the target does not support this it sends a response of INVALID FRAME. Emulex comment number 58 Page=508 Subtype=Highlight Author=bmartin Comment= and This and is in the wrong place since there are three items in the list. Emulex comment number 59 Page=508 Subtype=Highlight Author=bmartin Comment= is the following list part of the above should, or is this a shall, or is this an example of a possible situation? Emulex comment number 60 Page=509 Subtype=Text Author=nayalasomayajula Comment= What does the SSP target do if it receives a TASK frame with RETRANSMIT BIT set for a tag that it had already responded to? Emulex comment number 61 Page=626 Subtype=Highlight Author=bmartin Comment= s/b a previous Emulex comment number 62 Page=631 Subtype=Highlight Author=bmartin Comment=This reference should be 4.2.8 Emulex comment number 63 Page=636 Subtype=Highlight Author=bmartin Comment= may implemented s.b. may be implemented Emulex comment number 64 Page=649 Subtype=Highlight Author=bmartin Comment= s/b DISCOVER response or a DISCOVER_LIST response Emulex comment number 65 Page=664 Subtype=Highlight Author=bmartin Comment=This reference should be 4.2.8 Emulex comment number 66 Page=665 Subtype=Highlight Author=bmartin Comment=This reference should be 4.2.8 Emulex comment number 67 Page=667 Subtype=Highlight Author=bmartin Comment= DISCOVER response defined in table 269 (see 10.4.3.10), not including the CRC field. Does this include the SMP Frame Type, Function, and Function Result? Emulex comment number 68 Page=710 Subtype=Highlight Author=bmartin Comment=This reference should be 4.2.8 ************************************************************** Comments attached to No ballot from Rob Elliott of Hewlett Packard Co.: --- HPQ comment number 1 Page=44 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= 07-076r1 s/b 07-067r1 --- HPQ comment number 2 Page=64 Subtype=Text Subj=Note Author=hpq-relliott Comment= An end device that does not support being attached to SATA (e.g., a SAS disk drive) should be allowed to consider K28.3 based dwords as not being primitives, and thus treat them as illegal dwords. Add this somewhere: An end device that does not support STP or SATA may consider a dword containing 7Ch control byte or K28.3 control character as an invalid dword. --- HPQ comment number 3 Page=107 Subtype=Text Subj=Note Author=hpq-relliott Comment= Allow NAA=3h for software-generated SAS addresses? (from Doug Gilbert) --- HPQ comment number 4 Page=111 Subtype=Text Subj=Note Author=hpq-relliott Comment=Add more specific MUX controls in the Transmit data path figure --- HPQ comment number 5 Page=115 Subtype=Text Subj=Note Author=hpq-relliott Comment= Add more specific MUX controls in the Transmit data path for expander phy figure --- HPQ comment number 6 Page=119 Subtype=Text Subj=Note Author=hpq-relliott Comment= This figure does not show an SMP phy and associated link layer state machines below the SMP Port since figure 16 does not do so. If the expander allows more than one connection at a time to its SMP target port, then it's effectively a wide SMP port and has multiple phys and link layers. If it only allows one at a time, then it's effectively a narrow SMP port and only has one phy and link layer. --- HPQ comment number 7 Page=119 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= machine s s/b machines --- HPQ comment number 8 Page=135 Subtype=Text Subj=Note Author=hpq-relliott Comment= Add a note that the addresses in the expander-based expander route table are not sorted in any particular order. --- HPQ comment number 9 Page=135 Subtype=Text Subj=Note Author=hpq-relliott Comment= Move the application client handling of Broadcast (Expander) to another section; it may not belong here. Add "and Broadcast (Expander)" to the title of 4.6.8. --- HPQ comment number 10 Page=136 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= after "is an expander device" add: "and the expander phy has the subtractive routing attribute or the table routing attribute. If an expander is attached, but the routing attribute is direct, every address beyond the attached expander device is inaccessible. --- HPQ comment number 11 Page=136 Subtype=Text Subj=Note Author=hpq-relliott Comment= Mention what the application client is supposed to do when it determines that an expander device is going to have reduced functionality. - complete all I/Os before the reduced functionality occurs - do not start new I/Os - do not open new connections after the time expires --- HPQ comment number 12 Page=148 Subtype=Highlight Subj=Comment on Text Author=hpq-curtisb Comment= First time that "zone group 2" is introduced. It needs a reference to 4.9.3.2 --- HPQ comment number 13 Page=166 Subtype=Text Subj=Note Author=hpq-relliott Comment= Create 4.10.2 Transmit pattern phy test function containing: 4.10.2 Transmit pattern phy test function While a phy is performing the transmit pattern phy test function, the test equipment attached to that phy: a) shall not transmit COMSAS or COMWAKE; and b) shall not transmit COMINIT except to stop the phy test function. When performing the transmit pattern phy test function, a phy: a) shall ignore all dwords received; and b) shall repeatedly transmit the specified pattern at the specified physical link rate. --- HPQ comment number 14 Page=166 Subtype=Text Subj=Note Author=hpq-relliott Comment= Replace 1st paragraph, first sentence of 2nd paragraph, 3rd paragraph, and 4th paragraph with: Phy test functions (e.g., transmission of test patterns) are used for phy and interconnect characterization and diagnosis. The phy may be attached to test equipment while performing a phy test function. The following optional mechanisms are defined for invoking phy test functions: a) the Protocol-Specific diagnostic page for SAS (see 10.2.9.1) invokes a phy test function in a selected phy other thanthe phy that receives the diagnostic page in a SAS target device with an SSP target port. The SEND DIAGNOSTIC command may be sent through any SSP target port to any logical unit in the SAS target device that contains the phy that is to perform the phy test function. The phy test function starts some time after the SSP target port receives an ACK for the RESPONSE frame transmitted in response to the SEND DIAGNOSTIC command; and b) the SMP PHY TEST FUNCTION function (see 10.4.3.25) invokes a phy test function in a phy controlled by a management device server other than the phy that receives the function. The phy test function starts some time after the SMP target port transmits the SMP response frame. Each phy test function is optional. --- HPQ comment number 15 Page=166 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= Once a SAS phy has begun performing a phy test function, it shall ignore its receiver. s/b While a phy is performing a phy test function, the link layer receivers (i.e., the SL_IR receiver, SL receiver, SSP receiver, STP receiver, and SMP receiver) shall ignore all incoming dwords and the OOB signal detector shall detect COMINIT. The phy shall ignore any other OOB signals (i.e., COMSAS and COMWAKE). [the technical change here is honoring COMINIT. That could be deferred to SAS-2.1] --- HPQ comment number 16 Page=166 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= To stop a SAS phy from performing a phy test function, an application client sends a SEND DIAGNOSTIC command or an SMP PHY TEST FUNCTION function to a SAS phy in the SAS target device that is not performing a phy test function requesting a phy test function of 00h (i.e., STOP). If no such phy is available, the phy test function only stops on power loss. s/b A phy stops performing a phy test function: a) after the SCSI device server, if any, processes a Protocol-Specific diagnostic page specifying the phy and specifying a phy test function of 00h (i.e., STOP); b) after the management device serve, if any, processes an SMP PHY TEST FUNCTION request specifying the phy and specifying a phy test function of 00h (i.e., STOP); c) after the phy receives COMINIT; or d) upon power off. It is vendor-specific how long a phy takes to stop performing the phy test function. After a phy stops performing a phy test function, it performs a link reset sequence. [the technical change here is adding COMINIT. That could be deferred to SAS-2.1] --- HPQ comment number 17 Page=166 Subtype=Text Subj=Note Author=hpq-relliott Comment= Move 4.10 text into 4.10.1 Phy test functions overview, allowing room for subsections for each phy test function --- HPQ comment number 18 Page=179 Subtype=Text Subj=Note Author=hpq-bolawsky Comment= Paragraph 2 implies that pin 11 of the power section is defined the same in Serial ATA. Note d clarifies this to some extent but the original SATA-II release identifies this pin as reserved. --- HPQ comment number 19 Page=185 Subtype=Text Subj=Note Author=hpq-bolawsky Comment= Table 42/43 Why are signal pins labeled as third mate and not second? --- HPQ comment number 20 Page=194 Subtype=Text Subj=Note Author=hpq-bolawsky Comment=Why are signal pins labeled as third mate and not second? --- HPQ comment number 21 Page=196 Subtype=Text Subj=Note Author=hpq-bolawsky Comment= Pair on pins 30/31 routed to pins 2/3 do not have circle indicating foil return. --- HPQ comment number 22 Page=199 Subtype=Text Subj=Note Author=hpq-bolawsky Comment= Lane reversal is only an issue with using the "SAS 4i controller to Mini SAS 4i backplane" cable in an application where the controller is a Mini SAS version. We now have two cable pinouts and use of the "Mini SAS 4i controller to SAS 4i backplane" cable will eliminate the reversal issue. This paragraph needs to be updated based on the addition of the latter pinout option. --- HPQ comment number 23 Page=201 Subtype=Text Subj=Note Author=hpq-bolawsky Comment= Positioning of the foil return graphic for pins A5/A6 is in wrong location. --- HPQ comment number 24 Page=212 Subtype=Text Subj=Note Author=hpq-bolawsky Comment=All three dBmV references are inappropriate. Should be dB. --- HPQ comment number 25 Page=212 Subtype=Text Subj=Note Author=hpq-bolawsky Comment= The Scc22 and Scd22 specifications are not achievable with all common types of interconnect. Data supporting revised specification will be posted in 08-187r0 SAS-2 S-Parameters of Cable Assemblies and Backplanes . --- HPQ comment number 26 Page=212 Subtype=Text Subj=Note Author=hpq-bolawsky Comment= Table needs a better link to figure 124 for interpreting fmin/fmax. Referenced Figure 125/126 don't include those parameters. --- HPQ comment number 27 Page=212 Subtype=Highlight Subj= Author=ifx-hnewman Comment= 6.0 s/b 6,0 periods need to be replaced by commas in entire table --- HPQ comment number 28 Page=212 Subtype=Highlight Subj= Author=ifx-hnewman Comment= 10 s/b 100 --- HPQ comment number 29 Page=212 Subtype=Highlight Subj= Author=ifx-hnewman Comment= dBmV) s/b dB) --- HPQ comment number 30 Page=216 Subtype=Highlight Subj= Author=ifx-hnewman Comment= (see SATA-2) Move red dot to the left of the connector. This better represents the receive compliance point being referenced in SATA-2. Also in Figure 103 --- HPQ comment number 31 Page=221 Subtype=Highlight Subj= Author=ifx-hnewman Comment= SATA-2 new reference needed for 6Gbps SATA. --- HPQ comment number 32 Page=221 Subtype=Highlight Subj= Author=ifx-hnewman Comment= 1.5 s/b 1,5 "Global" --- HPQ comment number 33 Page=221 Subtype=StrikeOut Subj= Author=ifx-hnewman Comment= and receiver device compliance points c) zero-length test load (see 5.3.2.2): used with a reference receiver device (see 5.3.7.4.3) by simulation methods to determine the delivered signal. --- HPQ comment number 34 Page=221 Subtype=StrikeOut Subj= Author=ifx-hnewman Comment=and --- HPQ comment number 35 Page=223 Subtype=Text Subj=Note Author=hpq-bolawsky Comment=The shape appears to be incorrect. My data forms a straight line. --- HPQ comment number 36 Page=230 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= cd s/b CD --- HPQ comment number 37 Page=230 Subtype=Text Subj=Note Author=hpq-bolawsky Comment=Clarify note "c" for application to "6 Gbps" only --- HPQ comment number 38 Page=231 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= 3 Gbps (see figure 112 Figure 112 is a 1.5 Gbps table. Item a) should probably refer to both tables for a given compliance point.: - for CT, the interconnect must be better than figure 112 (using revision 14 figure numbers) at 1.5 Gbps and figure 110 at 3 Gbps. - for IT, the interconnect must be better than figure 111 at 1.5 Gbps and figure 109 at 3 Gbps. (from Justin Wang, Uniconn) --- HPQ comment number 39 Page=231 Subtype=Text Subj=Note Author=hpq-relliott Comment= Need to state the goals for the statistical eye calculated by the reference receiver when performing channel testing: minimum amplitude 100 mV maximum TJ 0.60 UI --- HPQ comment number 40 Page=233 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= cd s/b CD --- HPQ comment number 41 Page=243 Subtype=Text Subj=Note Author=hpq-bolawsky Comment=Notes c and d are not used. --- HPQ comment number 42 Page=243 Subtype=Highlight Subj= Author=ifx-hnewman Comment= c Add footnote 'c' and 'd' to table. --- HPQ comment number 43 Page=244 Subtype=Highlight Subj=Highlight Author=hpq-bolawsky Comment= b is wrong or missing --- HPQ comment number 44 Page=244 Subtype=Text Subj=Note Author=hpq-relliott Comment=Move N to the right --- HPQ comment number 45 Page=244 Subtype=Text Subj=Note Author=hpq-bolawsky Comment=All three dBmV references are inappropriate. Should be dB. --- HPQ comment number 46 Page=246 Subtype=Text Subj=Note Author=hpq-relliott Comment=StatEye default RJ/DJ is a bit different than this. --- HPQ comment number 47 Page=251 Subtype=Text Subj=Note Author=hpq-bolawsky Comment=All three dBmV references are inappropriate. Should be dB. --- HPQ comment number 48 Page=254 Subtype=Text Subj=Note Author=hpq-relliott Comment= 20 ppm is just the minimum, so the equation is not always correct. Reference the "NEXT offset frequency"" variable below. --- HPQ comment number 49 Page=254 Subtype=Text Subj=Note Author=hpq-relliott Comment=Fo is not defined --- HPQ comment number 50 Page=254 Subtype=Text Subj=Note Author=hpq-relliott Comment= Add a list right after the figure describing what each of the blocks are. In particular, a link describing the ISI generator is needed. (suggested by Mike Jenkins in March WG) --- HPQ comment number 51 Page=275 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= 13.65 us is based on nominal OOBI. It should based based on the maximum OOBI to allow the transmitter to be as slow as possible (largest OOBI) and still have a change to transmit 512 x 40 bits, which yields 13.68610816 --- HPQ comment number 52 Page=282 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= 1 310 720 OOBI should be a time value (in us) since this is a receiver timeout value, not a transmitter value. It should be based on the maximum OOBI, allowing the other transmitter the longest legal time to send 32768x40 bits. --- HPQ comment number 53 Page=287 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= us (micro) s/b ns (nano) --- HPQ comment number 54 Page=287 Subtype=Text Subj=Note Author=hpq-relliott Comment= Values used in the state machine (COMSAS Detect timeout, AWAIT ALIGN timeout, Hot-Plug Timeout, RCDT, SNLT, SNTT, TLT, and MTT), should be normatively expressed in time values, not OOBIs. If this phy has a short OOBI and is receiving from another phy which has a long OOBI, this phy needs to allow enough time for the other phy to transmit the desired number of bits. --- HPQ comment number 55 Page=294 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= reword sentence as: forms training patterns using ... --- HPQ comment number 56 Page=294 Subtype=Text Subj=Note Author=hpq-relliott Comment= The phy shall not perform pattern comparison on the incoming TRAIN pattern and TRAIN_DONE pattern to train and acquire dword synchronization. --- HPQ comment number 57 Page=295 Subtype=Text Subj=Note Author=hpq-relliott Comment= If a phy A that only supports SNW-1 is attached to a phy B that only supports SNW-3, phy A runs: OOB, SNW-1 (yes) SNW-2 (no), and back to OOB while phy B runs: OOB, SNW-1 (no), SNW-2 (no), SNW-3 (yes), and back to OOB. Since the SNW-3 involves COMWAKE, phy A interprets this as receiving a COMWAKE in response to its COMINIT, which falsely identifies a SATA port selector. Phy A's ATTACHED SATA PORT SELECTOR bit will be set incorrectly in the SMP DISCOVER response. When phy B runs SNW-1 again and sends COMINIT, that should cause phy A to realize that a SAS device is attached, not a SATA device. However, they may keep repeating this forever. In 7.11, rule d) causes a Broadcast (Change) when that bit toggles from 0 to 1, so infinite Broadcast (Changes) will result at the hot-plug timeout intervals. --- HPQ comment number 58 Page=296 Subtype=Text Subj=Note Author=hpq-relliott Comment= Failure to find any supported speed (either by row a) or by row c)B)) is not supposed to be a phy reset problem; that just means two incompatible devices are attached, which is not the same as a broken device being attached or the link having reliability problems (the original meaning). That could be counted with a new counter. --- HPQ comment number 59 Page=331 Subtype=Text Subj=Note Author=hpq-relliott Comment= SP_DWS doesn't send Dword Received confirmations upstream until the phy reset sequence is completed. Some feedback from SP is needed to know when this happens. --- HPQ comment number 60 Page=386 Subtype=Text Subj=Note Author=hpq-relliott Comment= Mentioning Broadcast (Change) in 7.9.2 and 7.9.3 is not ideal, since 7.9 is the identification and hard reset sequence section. The general application client rules for handling direct attached resets as well as Broadcast (Changes) belongs elsewhere. --- HPQ comment number 61 Page=388 Subtype=Text Subj=Note Author=hpq-relliott Comment= need to clarify how SP works with two SL_IRs in multiplexing. Does each one send Stop SNTT upon receiving its IDENTIFY address frame? --- HPQ comment number 62 Page=458 Subtype=Text Subj=Note Author=hpq-relliott Comment= If there is no affiliation established when a SATA_X_RDY arrives, define what happens. The initial register FIS is normal and expected; anything else is not. --- HPQ comment number 63 Page=469 Subtype=Text Subj=Note Author=hpq-relliott Comment= PL_OC should be the sole recipient of HARD_RESET Received confirmations from the link layer. PL_PMs should not look at that confirmation from all the phys in the port (as it is implied they are doing, as written). PL_OC should distribute it as a message to all the PL_PMs in the port. --- HPQ comment number 64 Page=478 Subtype=Text Subj=Note Author=hpq-relliott Comment= After receiving a Connection Opened message, if credit is granted during the connection, the state may delete a pending Tx Open if it no longer needs to open its own connection. No need for unnecessary connection requests later on. --- HPQ comment number 65 Page=528 Subtype=Text Subj=Note Author=hpq-relliott Comment= this wording should parallel ST_TTS5:Receive_Data_Out. Items d) and e) in particular are different. --- HPQ comment number 66 Page=546 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= vender s/b vendor --- HPQ comment number 67 Page=562 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= Consider deleting "NAK was received" since it's covered by the ST_IFR reference. --- HPQ comment number 68 Page=575 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= PAGE LENGTH (0Dh) [13] s/b PAGE LENGTH (0Eh) [14] --- HPQ comment number 69 Page=587 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= global change PHY TEST PATTERN PHYSICAL LINK RATE to PHY TEST FUNCTION PHYSICAL LINK RATE, PHY TEST PATTERN SATA to PHY TEST FUNCTION SATA, and PHY TEST PATTERN TX SSC to PHY TEST FUNCTION TX SSC Other phy test functions in the future may also use these fields. --- HPQ comment number 70 Page=588 Subtype=Highlight Subj=Highlight Author=hpq-relliott Comment= be set to transmit the s/b perform the transmit pattern phy test function (see 4.10.2) using the [after adding section 4.10.2 per other comment] --- HPQ comment number 71 Page=588 Subtype=StrikeOut Subj=Cross-Out Author=hpq-relliott Comment= Delete: and set to ignore its receiver. If the selected phy receives data while transmitting the pattern, then the selected phy shall ignore the received data. after adding section 4.10.2, which will contain that rule (in more detail). --- HPQ comment number 72 Page=606 Subtype=Text Subj=Note Author=hpq-relliott Comment= The fields Allocated Response Length, Request Length, and Response Length all have maximum values of FFh=255, meaning 255*4=1020 bytes, not 1024. So, the statements in the SMP transport layer that the maximum SMP request bytes size (excluding the CRC field) is 1024 bytes is untrue. Since the size including CRC is indeed 1024, it's still a convenient number. Change the SMP transport layer section to match this limit. Add a NOTE that in SAS-1.1, a vendor-specific frame might have been defined that had 1024 bytes of data. --- HPQ comment number 73 Page=644 Subtype=Text Subj=Note Author=hpq-relliott Comment= Incorporate 08-183 SAS-2 Add device slot numbering fields to DISCOVER, which adds 3 new fields to fully describe the device slot (i.e., drive bay) in a variety of system topologies. --- HPQ comment number 74 Page=644 Subtype=Text Subj=Note Author=hpq-relliott Comment=Add a field indicating drive presence (if known) --- HPQ comment number 75 Page=665 Subtype=Text Subj=Note Author=hpq-relliott Comment= Require the phy event descriptors be in ascending order sorted by the phy event source. Require that only one entry be present per phy event source. (or, treat this as a log, where events are added as they occur) --- HPQ comment number 76 Page=669 Subtype=Text Subj=Note Author=hpq-relliott Comment= add d) sorted in ascending order based on phy identifier; --- HPQ comment number 77 Page=676 Subtype=Text Subj=Note Author=hpq-relliott Comment= Require the REPORT EXPANDER ROUTE TABLE descriptor list be sorted in ascending order based on routed SAS address (internally it need not be sorted, but for reporting purposes some order is helpful) --- HPQ comment number 78 Page=684 Subtype=Text Subj=Note Author=hpq-relliott Comment= Require the broadcast source zone group list to be sorted in ascending order. --- HPQ comment number 79 Page=691 Subtype=Text Subj=Note Author=hpq-relliott Comment= The expander device should be allowed to prohibit use of DISABLED (policy choice). If so, define which function result to return if it is attempted. --- HPQ comment number 80 Page=693 Subtype=Text Subj=Note Author=hpq-relliott Comment= Require the zone phy configuration descriptor list to be sorted in ascending order based on phy identifier --- HPQ comment number 81 Page=721 Subtype=Text Subj=Note Author=hpq-relliott Comment= (Leon Krantz, Marvell) In dword 118, 79C211AAh should be swapped with 44EF682Eh --- HPQ comment number 82 Page=729 Subtype=Text Subj=Note Author=hpq-relliott Comment=add more shading on figures in chapter B --- HPQ comment number 83 Page=737 Subtype=Text Subj=Note Author=hpq-relliott Comment=shalls in informative annex --- HPQ comment number 84 Page=790 Subtype=Text Subj=Note Author=hpq-relliott Comment= Changes to the .h and .cpp code are necessary to remove edge/fanout and edge expander device set handling. Delete "edge" and "fanout" from commands. Replace "edge expander device set" with a term for all the expanders beyond an S-S link. Otherwise, code should work as is. ************************************************************** Comments attached to No ballot from Kevin Butt of IBM Corp.: Comments on sas2r14_IBM.fdf IBM comment number 1 Page=1 Subtype=Text Author=Paul Cashman Comment= At the enterprise level there is a need to have an attached SAS device perform a deep reset, where all device software or firmware is re-initialised. [Typically in this scenario, enterprise would ask for a debug dump to be taken for future analysis too.] This would equate to a reset at the protocol level. This reset should apply to all devices, expanders, drives etc. I don't see how is this done in SAS? IBM comment number 2 Page=1 Subtype=Text Author=Paul Cashman Comment= At the enterprise level and possibly for other environments, there is also a need to specify behaviour for EPOW. SAS seems to have no method of indicating EPOW to devices, potentially leaving disk systems with 'damaged' sectors that will then fail on array rebuilds, causing data loss. This is unacceptable for the enterprise market and some method of signalling EPOW is required. IBM comment number 3 Page=1 Subtype=Text Author=Sandy Shirk-Heath Comment= Proposal posted with items that need to be covered: 08-186r0.pdf IBM comment number 4 Page=171 Subtype=Text Author=Ted Vojnovich Comment= Section 5: Lots of good math there. However, I am concerned about the following scenario: Somebody has a SAS 1.1 device (disk for example) and uses a SAS 2.0 cable (I understand that SAS supports up to 10M while SAS 1.1 supports 5M). If the distance limit for SAS 2.0 is longer than SAS 1.1, how does the system behave (I would think SAS 1.1 transceiver would have a hard time working with a cable that is farther in distance). I may be off base here (have not watched the analog side that closely) but would think there needs some way to help the admin trouble shoot this (connector/cable color matching, some impedance sensing, etc). Should that not be specified in the std? IBM comment number 5 Page=211 Subtype=Highlight Author=Jay Diepenbrock Comment= The mated connector end/backplane impedance conditions are nominal values only. Tolerances need to be specified. The intra-pair skew requirements have been dropped. They should be added back in. The inter symbol interference (i.e., jitter) requirements should also be added back in. IBM comment number 6 Page=222 Subtype=Highlight Author=Jay Diepenbrock Comment= Include limits on insertion loss for the cables as a function of frequency. Maybe not this section, but somewhere. IBM comment number 7 Page=240 Subtype=Highlight Author=Jay Diepenbrock Comment=Separate budgets need allocated for cards and cables. IBM comment number 8 Page=240 Subtype=Highlight Author=Jay Diepenbrock Comment= I don't see an allocation of in-pair skew for the cable separate from the rest of the system. How does a cable supplier know if his cable meets the spec. or not since he has no knowledge of the amount of skew on cards, etc.? Please allocate separate portions of the skew and jitter budget to the cards and the cables and insertion loss. Cable suppliers are having difficulty meeting the specs - even using the entire budget. They don't want to sign up to meet the spec'ed limits. IBM comment number 9 Page=337 Subtype=Text Author=Ted Vojnovich Comment= Section 7: Hard resets create real problems in expander solutions. For example, the following has been seen (and worked around with some vendor specific functions/broadcast async functions): 4 initiators ==>EXP A==>RAID controller. When initiator 1 sends a hard reset to the RAID controller, the port is reset...this, in turn, filters up to initiators 2,3,4 who intern issue their own hard resets...and so on and so on. This hard reset storm is a problem that may need some thinking from a fabric paradigm view. ie...would think at least some description of behavior or approach should be used for hard resets in a fabric paradigm. IBM comment number 10 Page=337 Subtype=Text Author=Ted Vojnovich Comment= Section 7: Broadcast change may need to think about the following: 4 initiators==>EXP A==> 4 disks such that initiator 1 is zoned to disk 1, 2 to 2, 3 to 3.. Now assume some initiator specific info on each disk (ie OS for server 1, different OS for server 2, etc). If the admin, inadvertently rearranges the disks (because needed to service expander or whatever), the SAS fabric would say all is fine even though there was an actual change. This leads to data corruption issues or, at the very least, an usuable system until admin figures out the problem (brute force, assuming admin even thought this was the issue, of 16 disk configuratons until finding the correct one). I think some method of scoreboarding the SAS address of targets to PHYs (present anyway since routing tables need to know this) would allow a broadcast change event if the table changed (currently does not). I am NOT talking about address based zoning..that is much more complicated I think. I view this one as a big deal!!! I dont think this can be deferred to SES and I don't think one can assume this will not happen. I could be had in forcing the initiator to track this table since they do discovery anyway. Anyway, think there needs to be some discussion on this front!!!! Routing behavior "perception" seems to vary from vendor to vendor. In essence, when an expander is has a subtractive port, some initiator vendors believe (either have seen or FUD) that the routing table will be rearranged on the fly and thus get them confused when they update their entries. Would think some clarification is in order on what the behavior should be. Zone group present in the open frame seems way to complicated and, frankly, turns this into an "implicit context protocol" which has not been used in 15 years on the networking side (TCP/IP, UDP, etc). Specifically, since the end point transmitter (initiator) transmits zone group =0 and the last expander before the receiver (target) transmits zone group=0, basically the end points have no clue what the zone group is. Therefore any artifical processing involves the receiver to go and look at the routing and permissions tables to figure what zone group the transmitter was in to figure out what the receiver should do with information. Seems real convoluted!!!! Since the receiver typically ignores the field why not use the following on page 332 A) May be set to 0 or may have source zone group when transmitted by end point (aka entering the zone domain because end point) B) Set to zone group when transmitted by expander with inside ZPDS = 0 (aka leaving the zone domain because expander is at the boundary) C) Set to zone group when transmitted by expande with inside ZPDS=1 (aka staying within zone domain because expander and link is still in zone domain) D)May be ignored or acted on by receiver end point (aka leaving the zone domain because end point) E)May be ignored or acted on by receiving expander with inside ZPDS=0 (aka arriving from another zone domain) F) Acted on by receiving expander with inside ZPDS=1 (aka staying within zone domain because link and expander is still in zone domain) This allows the end points to have the zone group info available if needed. Aka if transmitter does not support....set to 0...if receiver wants to act on it...notes 0 and treat as if one be zone domain (ZG=0 means all can see all) or not valid and take some default action. I view this as pretty important This then puts the burden on the implementation to support...perhaps over time....but the point is that the approach is defined in the standard. IBM comment number 11 Page=393 Subtype=Highlight Author=Steve Wallace Comment= SSP target ports also open a connection to transfer an XFER_RDY (request write data). IBM comment number 12 Page=402 Subtype=Highlight Author=Steve Wallace Comment= This cannot be supported on some older devices which do not have the capability to send BREAK_REPLY. So, some older devices may never be able to support this level of SAS. IBM comment number 13 Page=494 Subtype=Highlight Author=Steve Wallace Comment= This check is not sufficient to determine that the I_T_L nexus does support the TLR CONTROL field. The TLR CONTROL field is replacing part of a reserved field. The definition of reserved states that the recipients are not required to check reserved fields for zero. If the target device does not check this field, then the initiator must use the VPD page to determine if the target supports TLR CONTROL. Otherwise, the initiator may think the TLR CONTROL field is valid when the target is ignoring the field. IBM comment number 14 Page=557 Subtype=Text Author=Ted Vojnovich Comment= Section 10: This might be more an implementation point but from what I have seen (and in no way have I seen alot), the queing approach for a SAS 4X link seems to have HOL blocking issues. I believe the following has been done and illustrates the problem. Assume 5 IOs outbound from initiator and initiator has a SAS 4X link. IO1 to link 1, IO2 to link 2, etc Now IO5 appears, in some implementation pinned to link 1. However, if IO 1 is moving 1KB and IO 2,IO3,IO4 are moving 100 bytes, link 2, 3, 4 are freed up quickly. However since IO 5 is pinned to link 1, it needs to wait for link 1 to finish transmitting IO 1 even though links 2,3,4 are freed up way earlier. This becomes an even bigger issue when the target is a RAID controller with lotsof disk behind (ie it could potentially receive that much more traffic and better utilize the 4X link). Obviously, 4 SAS 1X links tied to a common target need to be treated as separate links and, thus, this optimization would not apply. Perhaps some discussion on the queuing model that should be used with any nX SAS ports might be in order. IBM comment number 15 Page=571 Subtype=Highlight Author=Steve Wallace Comment=This text should probably be on the next line (not part of item b). ************************************************************** Comments attached to No ballot from Mark Seidel of Intel Corp.: Intel 1: page iii [Abstract] Is SAS always intended to be compatible with SATA physical interconnect? There are issues of keying, and perhaps there are conditions for some blocks that don't support SATA 6G that may not meet their performance. It is a goal, but SATA 6G is a moving target. Intel 2: pages v - xxvi [Table of Contents] Fix long section names so that the wrap-around does not clutter the page number portion. Intel 3: pages xxvii - xxxviii [Tables and Figures] Fix long table and figure names so that the wrap-around does not clutter the page number portion or the table/figure number portion. Intel 4: page xxviii [Tables] Fix the format on the page number for Table 70 to be the same font size as the rest of the page numbers. Intel 5: page xxxv [Figures] Fix the format on the page number for Figure 107 to be the same font size as the rest of the page numbers. Intel 6: page 5 [3.1] "jitter, bounded uncorrellated (BUJ)" should appear in the list of definitions. Intel 7: page 5 [3.1.4] The definition for ALT does not conform to that in Table 95. Table 95 is correct. Intel 8: page 6 [3.1.21] The directive "See MJSQ." is not well-defined in this context. It should point to a section number ("See MJSQ in 2.2."). There are other occurrences of this phrase in the standard. Intel 9: page 7 [3.1.51] A dB is ten times the common log of the power ratio, not one-tenth. It also should incorporate Note 6. Intel 10: page 7 [3.1.52, 3.1.53] Notes 7 and 8 should be incorporated into the definitions of dBmv and dBm. Intel 11: page 10 [3.1.93] "SATA-2" is not defined in this standard, but is in the list of abbreviations. The pointer should be to a section number (2.4). There may be other occurrences of this phrase in the standard. Intel 12: page 17 [3.1.228] The listing of "SATA-2" is in 2.4, not 2.3. Intel 13: page 18 [3.1.249] The definition for SNTT does not conform to that in Table 95. Table 95 is correct. Intel 14: page 61 [4.3.2, Figure 31] The Speed Negotiation primitives (e.g., TRAIN, TRAIN_DONE, random scrambled data) should be included with the SP transmitter box. Intel 15: page 116 [4.10] "provide" in first sentence s/b "provides". Intel 16: page 116 [4.10] If a phy does not support SEND DIAGNOSTIC function, then how does it respond? It is supposed to send a function resulot of UNKNOWN PHY TEST FUNCTION in the RESPONSE frame. But if it sends a RESPONSE frame and then gets an ACK, it "shall begin the specified phy test function". The wording should be clarified here and in 10.4.3.29. The same is true for the wording concerned with the SMP PHY TEST FUNCTION. Intel 17: page 163 [5.3.1] The ITs and CTs compliance points only appear with reference to the Tx test load. It should therefore be indicated that these points are only for Gen3 phys. Intel 18: page 179 [5.3.2.5] Note 22 indicates several dependencies outside the standard. It would be better to include the s-parameter model om some concrete way, perhaps as text in an appendix. I assume that all Notes and Editor's Notes must be addressed in the Letter Ballot process (and edited into the text or out of the document). Intel 19: page 181 [5.3.3.3.1] Second paragraph, third sentence: "that the over TxRx connection requirements" s/b "that over the TxRx connection all requirements" Intel 20: page 185 [5.3.5.2] The 3-dB corner frequency of the JTF originally came from Fbaud/500 for 3Gbps, which is 6 MHz (lowpass). The corresponding highpass corner frequency was found to be approximately 2.5 MHz, depending upon the particular characteristics of the tracking PLL filter. Doubling the baud rate should correspondingly increase the JTF corner frequency. Intel 21: page 196 [5.3.6.5.4] Note 25 points to documents outside the standard; this standard should be made more stand-alone by incorporating needed information. Intel 22: page 204 [5.3.7.4.4.1, Table 72; also Table 61 in 5.3.6.5.1] It would be better to relax the RJ number of 0.15UI, since this number is on the edge for today's leading-edge process technologies. Future technologies (implementing SAS-2 as legacy) will have increasing difficulty to meet this RJ number. Past versions of this and other phy standards have specified TJ and DJ; going to RJ and TJ in this standard makes the game a little different looking ahead. 0.18 or 0.20 UI would be better. Intel 23: page 204 [5.3.7.4.4.1, Table 72] The Tx bounded uncorrelated jitter number is extremely small, and should be increased at least two orders of magnitude. Also, "BUJ" should be indicated here, and a definition should be added. Intel 24: page 204 [5.3.7.4.4.1, Table 72] All references here and elsewhere to Link Dispersion Penalty (LDP) and WDP must either be defined and explained, migrated into aother already-explained concept, or removed. Intel 25: page 210 [5.3.8.3, Table 78] In Note (c), there is no reason to require a transmitter to support both types of SSC modulation if it supports any type, since it could be designed for a particular application. Change Note (c): "both shall be supported" s/b "both should be supported". Intel 26: page 232 [6.7.3] Third sentence: "SAS phy or expander phy" s/b "SAS initiator phy or expander phy" Intel 27: page 232 [6.7.3] Upcoming SATA phys may have the capability to train their receiver circuitry, especially the new eSATA. In order to exploit this capability, SAS-2 should delay sending COMSAS in order to have time to receive a new OOB pattern (to be defined) that indicates it is talking with a trainable SATA phy. The reception of this new OOB pattern would then trigger a speed and capabilities information exchange with the SATA phy similar to what is done for SAS-2 phys. This is a difficult topic to address, because it has to be accomplished in concert with the SATA specification development. But if we do not make this allowance, then we miss the window of opportunity. Delaying the COMSAS signal by some amount of time will not seriously affect the timeliness of completing the SAS speed negotiation, especially considering the 20 ms of each Train-SNW. Intel 28: page 237 [6.7.4.2.2, Table 95] The values in Notes f and h should end in "72", not "719(9 repeating)". Intel 29: page 237 [6.7.4.2.2, Table 95] The calculation in Note l is incorrect. It should be 1.46(6 repeating) microseconds, not 1466.6(6 repeating). Intel 30: page 237 [6.7.4.2.2, Table 95] The letter superscripts for Notes ought to proceed alphabetically as one goes down the Table. Note l is out of order. Intel 31: page 238 [6.7.4.2.3.1] Itemized list element (b) should not dictate that the phy is not to receive, since the state machine transitions are not consistent with a phy possibly being in SP1:Await_COMX while the other phy is transmitting COMWAKEs to indicate its capabilities during SNW-3. See related Intel comments in 6.7.4.2.3. Intel 32: page 239 [6.7.4.2.3.2] The last sentence is a serious issue for common-clock architectures. They ought to be able to use SSC especially if it has been negotiated on previously and there has not been a hot-plug event, since the other phys on the common clock have it on and the phy that is connected to it has handled SSC previously. It should also be OK to utilize SSC during SNW-1/2/Final; an attached receiver that responds with ALIGN(1) can obviously handle the SSC in the datastream. Intel 33: page 240 [6.7.4.2.3.3] Sentence starting with "If the phy does not support SNW-3,..." does not fit with the SP state machine. If such a phy follows the state machine transitions and is talking with a 6G-only phy then it may enter SP1:Await_COMX and identify the incoming SNW-3 COMWAKE as a SATA port selector. Intel 34: page 244 [6.7.4.2.3.4] The training sequence is not unique due to an unknown initial running disparity and an unspecified treatment of the random scrambled data during the TRAIN and TRAIN_DONE primitives. The paragraph following Table 103 should add something like "The scrambler shall not run during TRAIN or TRAIN_DONE primitives; the bit pattern produced during the Train-SNW window shall be the same as a continuous scrambled data pattern with TRAIN and TRAIN_DONE primitives inserted at the proper positions." In addition, the next paragraph (second sentence) should change "pattern may have either starting disparity" to "pattern shall start with positive running disparity". Intel 35: page 245 [6.7.4.2.4, Figure 146] This figure should indicate where the phy reset problems occur, and an additional decision diamond should be added between the Final-SNW box and the End circle. Intel 36: page 247 [6.7.4.2.4, Figures 147 through 152] There should be a SAS speed negotiation sequence diagram indicating how the SAS-2 protocol interacts with legacy SAS-1.1 devices. It could also indicate the interaction with legacy phys. Intel 37: page 253 [6.7.5] "table 93" s/b "Table 93". All such instances of "table" and "figure" that indicate a particular object should be capitalized. Intel 38: page 259 [6.8.3.3.1] There is potential for a phy to become confused during Speed Negotiation during this state. Consider Phy1 supporting only 6G talking with Phy2 supporting only 1.5G, 3G, and SATA, or 1.5G and SATA. Phy2 will transmit ALIGN during SNW-1 and SNW-2, while Phy1 will transmit D.C. idle. During SNW- 3, Phy1 will transmit COMWAKEs as part of the phy capabilities data, but Phy2 will have transitioned to SP1:OOB_AwaitCOMX from SP14:SAS_Fail, since the maximum SAS speed negotiation window has been attempted and there have not been any successful negotiated physical link rates. Once in the SP1:Await_COMX state, Phy2 will detect COMWAKE and (if it supports SATA port selectors) then decide that the attached phy is a SATA port selector. Phy2 would then run the TRANSMIT SATA PORT SELECTION SIGNAL phy operation, which sends a sequence of five COMINIT OOB signals. There should be a note in the standard explaining this interaction, and also we should ensure that the state machines don't do anything funny under all combinations of SAS/SATA Gen1/2/3 support. For example, when the Gen1-only phy decides it is connected to a SATA port selector, it can send a SATA port selection signal consisting of several COMINITs. These COMINITs can reset the Gen3 phy, causing an endless cycle. Intel 39: page 313 [7.3.1] Second paragraph, third sentence: ""Phy receivers add deletable" s/b "Phy receivers may add deletable" Intel 40: page 315 [7.3.2, Table 127] Notes a and b should include short explanation why insertion requirement is now so different, something like: "The different requirement in this version is due to the worst-case presence of different types of SSC in the datastream." Intel 41: page 671 [A.4] It is not necessary to require that a phy receiving JTPAT inside a connection to treat the data dwords as idle dwords and ignore them; "inside or outside" in the first sentence s/b "outside". Intel 42: page 61 [4.3.2, Figure 31] The diagram should make clear that TRAIN and AIN_DONE primitives are among the last ones to enter the datastream. If they are not, then the training patterns can be incorrect and not determiistic. ************************************************************** Comments attached to Yes ballot from Dennis Moore of KnowledgeTek, Inc.: KnowledgeTek comment number 1 Page=54 Subtype=Highlight Author=Dennis Moore Comment= SATA-2 s/b SATA rev 2.6 Global change. The SATA-IO organization says there is no such thing as SATA-2 and does not want the term used. Maybe a definition of "SATA" equals "Serial ATA 2.6" in this standard and make a global change of SATA-2 to SATA. KnowledgeTek comment number 2 Page=92 Subtype=Highlight Author=Dennis Moore Comment= number of phys contained Is it necessary to indicate logical? KnowledgeTek comment number 3 Page=106 Subtype=Highlight Author=Dennis Moore Comment= Reported in the IDENTIFY address frame (see 7.8.2) for SAS ports. Isn't this also in VPD 83h? KnowledgeTek comment number 4 Page=115 Subtype=Highlight Author=Dennis Moore Comment= SL_IRM s/b: SL_IR or SL_IR_TIR KnowledgeTek comment number 5 Page=118 Subtype=Highlight Author=Dennis Moore Comment= SL State Machine[0..1] SL_IR State Machine[0..1] I don't understand, shouldn't there be at least one of each of these and two if muxing is enabled? KnowledgeTek comment number 6 Page=118 Subtype=Highlight Author=Dennis Moore Comment= PM State Machine[0..128] Shouldn't this be 1...128? If you have a port you must have at least one PM? KnowledgeTek comment number 7 Page=119 Subtype=Highlight Author=Dennis Moore Comment= SL_IR State Machine[1] If phy is muxing capable, is this [1..2]? What about the XL state machine? KnowledgeTek comment number 8 Page=124 Subtype=Highlight Author=Dennis Moore Comment= deasserted s/b negated Last time I checked Webster's 'deasserted' was not a word. KnowledgeTek comment number 9 Page=139 Subtype=Highlight Author=Dennis Moore Comment= Rate matching is used for 1.5 Gbps connections carried on 3 Gbps logical links. Isn't rate matching allowed on any speed link? If I choose to not enable rate matching, can't I talk to a 3Gbps device attached to an expander talking to a 6Gps HBA? KnowledgeTek comment number 10 Page=149 Subtype=Highlight Author=Dennis Moore Comment= access to zone group 2 This implies that zoning must already be enabled, an there are zone permission tables already in use. Should this be noted? KnowledgeTek comment number 11 Page=150 Subtype=Highlight Author=Dennis Moore Comment= target port s/b "destination port" KnowledgeTek comment number 12 Page=280 Subtype=Highlight Author=Dennis Moore Comment= COMINIT The d.c. idle line in the drawing directly below this word is not complete. KnowledgeTek comment number 13 Page=282 Subtype=Highlight Author=Dennis Moore Comment= 54,6 us I thought the decimal point was back and the comma was banished. This one and the next one over. KnowledgeTek comment number 14 Page=282 Subtype=Highlight Author=Dennis Moore Comment=54,6 us KnowledgeTek comment number 15 Page=290 Subtype=Highlight Author=Dennis Moore Comment= receive s/b receives KnowledgeTek comment number 16 Page=295 Subtype=Highlight Author=Dennis Moore Comment= transmit s/b "transmits" or "has transmitted" ************************************************************** Comments attached to No ballot from John Lohmeyer of LSI Corp.: LSI comment number 1 Page=1 Subtype=Text Author=Brad Besmer Comment= Global: I think we have a problem with the generic term "zone permission table". We have several "zone permission tables" defined: - Current - Shadow - Default - Saved Collectively, all 4 of these may be referred to "zone permission tables". I think most current usages are intended to be "current zone permission table". There are also 2 instance of "active zone permission table", which is undefined and I think really are "current zone permission table". This same concern applies to theterm "active values". The most obvious changes to me are: 1) Use "active" instead of "current" throughout when referring to zoning permission tables and zone manager password (I counted 25 occurrences that would need to be changed). 2) add "active" qualifier added to several instances of "zone permission table". LSI comment number 2 Page=1 Subtype=Text Author=Brad Besmer Comment= The CONFIGURING bit is (unfortunately) overloaded by both zoning and the self-discovery process. There are several cases like: ....shall set the CONFIGURING bit to zero when... That is not correct behavior when both processes are outstanding. LSI comment number 3 Page=39 Subtype=Text Author=George Penokie Comment=The revision information needs to be removed. LSI comment number 4 Page=51 Subtype=Highlight Author=Brad Besmer Comment= Should SAT be included in this? SAT-2 Figure 3 indicates how SAT fits in overall. LSI comment number 5 Page=52 Subtype=Highlight Author=George Penokie Comment= I don't think putting an unknown standard here is a good idea. It looks like a TBD. Either delete it or get a real number. IEC xxxxx-xxx LSI comment number 6 Page=52 Subtype=Highlight Author=George Penokie Comment= I don't think putting an unknown standard here is a good idea. It looks like a TBD. Either delete it or get a real number. ISO/IEC xxxxx-xxx LSI comment number 7 Page=53 Subtype=Highlight Author=George Penokie Comment= I don't think putting an unknown standard here is a good idea. It looks like a TBD. Either delete it or get a real number. ISO/IEC xxxxx-xxx, LSI comment number 8 Page=53 Subtype=Highlight Author=George Penokie Comment= I don't think putting an unknown standard here is a good idea. It looks like a TBD. Either delete it or get a real number. ISO/IEC xxxxx-xxx, LSI comment number 9 Page=53 Subtype=Highlight Author=Brian Day Comment=Should this table include the SATA IO organization? LSI comment number 10 Page=54 Subtype=Highlight Author=Brad Besmer Comment=Add SAT-2 to this list? LSI comment number 11 Page=54 Subtype=Highlight Author=Brian Day Comment= Serial ATA 2.6 (SATA-2). s/b Serial ATA Revision 2.6. LSI comment number 12 Page=55 Subtype=Highlight Author=George Penokie Comment= If you insist on all things be cross referenced then there needs to be one here . << An object that is >> LSI comment number 13 Page=55 Subtype=Text Author=George Penokie Comment= I have pointed out a few missing cross-references to other glossary entries. I question the benefits of adding in cross-references to within section 3.1.xx as is see on way to get them all. I recommend removing them all. LSI comment number 14 Page=55 Subtype=Highlight Author=Brian Day Comment= Train-SNW s/b SNW-1, SNW-2, or Final-SNW LSI comment number 15 Page=55 Subtype=Highlight Author=Brian Day Comment= (see 6.7.4.2.3.4). s/b 6.7.4.2.3.2 LSI comment number 16 Page=56 Subtype=Highlight Author=George Penokie Comment= If you insist on all things be cross referenced then there needs to be one here . << An object within an >> LSI comment number 17 Page=57 Subtype=Highlight Author=George Penokie Comment= I have no clue what this statement is trying to tell me << and sometimes relaying a response (see 3.1.189) from a peer higher layer state machine. >> and there is nothing in section 3.6 that would help. I suggest it be deleted. LSI comment number 18 Page=57 Subtype=Highlight Author=George Penokie Comment= If you insist on all things be cross referenced then there needs to be one here .<< SAS target port >> LSI comment number 19 Page=57 Subtype=Highlight Author=George Penokie Comment= If you insist on all things be cross referenced then there needs to be one here . <> LSI comment number 20 Page=57 Subtype=Highlight Author=George Penokie Comment= If you insist on all things be cross referenced then there needs to be one here . << SAS target phy >> LSI comment number 21 Page=57 Subtype=Highlight Author=George Penokie Comment=This << one-twentieth >> should be expressed mathematically. LSI comment number 22 Page=58 Subtype=Highlight Author=George Penokie Comment= This << electronics/electrical equipment. >> should be << electronics or electrical equipment. >> LSI comment number 23 Page=58 Subtype=Highlight Author=Brad Besmer Comment= This implies dword is only on the receive path. Also applies prior to 8b10b encoding (ie. when transmitting a dword). LSI comment number 24 Page=61 Subtype=Highlight Author=George Penokie Comment= Is there any case in this standard when it is expressed in something other than dB? I think not so the << usually >> term should be deleted. LSI comment number 25 Page=61 Subtype=Highlight Author=George Penokie Comment=This should be << data dependent jitter >> LSI comment number 26 Page=61 Subtype=Highlight Author=George Penokie Comment=This should be << deterministic jitter >> LSI comment number 27 Page=61 Subtype=Highlight Author=George Penokie Comment= This should be << random jitter >> and the second , should be deleted. LSI comment number 28 Page=61 Subtype=Highlight Author=George Penokie Comment=This should be << sinusoidal jitter >> LSI comment number 29 Page=61 Subtype=Highlight Author=George Penokie Comment=This should be << total jitter >> LSI comment number 30 Page=61 Subtype=Text Author=George Penokie Comment= If I'm going to the glossary to look for any of these types of jitter I would not look in the j's I would look in d, r, or s and not find it. LSI comment number 31 Page=61 Subtype=Highlight Author=George Penokie Comment= The term << task >> in most cases should be changed to << command >> LSI comment number 32 Page=63 Subtype=Highlight Author=George Penokie Comment= This is not a good definition for nexus. How about << When referring to SAS devices, a relationship between SAS ports. When referring to SCSI devices, a relationship between a SCSI ports that may extend to a logical unit and a command. LSI comment number 33 Page=65 Subtype=Highlight Author=George Penokie Comment= Is there any case in this standard when it is expressed in something other than dB? I think not so the << usually >> term should be deleted. LSI comment number 34 Page=65 Subtype=Highlight Author=George Penokie Comment= There should be no such thing as a << SAS target/initiator device >> delete it here and everywhere else where it appears. LSI comment number 35 Page=66 Subtype=Highlight Author=George Penokie Comment= There should be no such thing as a << SAS target/initiator port >> delete it here and everywhere else where it appears. LSI comment number 36 Page=66 Subtype=StrikeOut Author=George Penokie Comment=There should be no such thing LSI comment number 37 Page=66 Subtype=StrikeOut Author=George Penokie Comment=There should be no such thing LSI comment number 38 Page=66 Subtype=Highlight Author=George Penokie Comment= You have to ways of stating this, one in ()s and the other in a sentence. Change all ()s to sentences so there read << SATA. Analogous to a SCSI thing. >>. LSI comment number 39 Page=66 Subtype=Highlight Author=George Penokie Comment= This << port (see 3.1.201), SAS target port >> should be << port (see 3.1.201) or SAS target port >> LSI comment number 40 Page=67 Subtype=StrikeOut Author=George Penokie Comment=There is no such thing. LSI comment number 41 Page=67 Subtype=StrikeOut Author=George Penokie Comment=There is not such thing. LSI comment number 42 Page=67 Subtype=Highlight Author=George Penokie Comment= This should be << through which requests, indications, responses, and confirmations are routed. >> LSI comment number 43 Page=68 Subtype=StrikeOut Author=George Penokie Comment= There is no such thing as a << SMP target/initiator port >> LSI comment number 44 Page=68 Subtype=StrikeOut Author=George Penokie Comment=The is no such thing. LSI comment number 45 Page=68 Subtype=StrikeOut Author=George Penokie Comment=This should be deleted as there is not such thing. LSI comment number 46 Page=69 Subtype=StrikeOut Author=George Penokie Comment=This should be deleted as there is no such thing. LSI comment number 47 Page=69 Subtype=Highlight Author=George Penokie Comment= This should be << state machine that may contain status from one state that is used in another state LSI comment number 48 Page=69 Subtype=StrikeOut Author=George Penokie Comment=No such thing exists. LSI comment number 49 Page=69 Subtype=StrikeOut Author=George Penokie Comment=There should be no such thing. LSI comment number 50 Page=71 Subtype=Highlight Author=Brad Besmer Comment= active s/b current (unless global comment to change current to active is accepted) LSI comment number 51 Page=85 Subtype=Text Author=Brad Besmer Comment= I suggest we increase the number of allowed expander phys to 255. Note: We need to reserve PhyIdentifier 0xFF (255) for SMP REPORT BROADCASTS special usage. Changes needed: Figure 10 Figure 16 Section 4.2.8 Phy identifiers shall be greater than or equal to 00h and less than 80h Table 8 (7-bit value) Table 50 LSI comment number 52 Page=87 Subtype=Square Author=George Penokie Comment=This should be fixed so the line merge with no hop. LSI comment number 53 Page=90 Subtype=Highlight Author=Brian Day Comment= are s/b is LSI comment number 54 Page=91 Subtype=Highlight Author=George Penokie Comment=Should be << detail is not shown. However, each port LSI comment number 55 Page=101 Subtype=Highlight Author=George Penokie Comment= Is this still true in SAS-2? Even it is, this does not seem like the correct place to specify it as there a many more words in the physical sections. LSI comment number 56 Page=101 Subtype=Highlight Author=Brad Besmer Comment= another partial pathway s/b another pathway or partial pathway or perhaps another connection or partial pathway LSI comment number 57 Page=101 Subtype=Highlight Author=Brad Besmer Comment= Not all dwords are necessarily forwarded (ie. all Deletable Primitives, Broadcast Primitives, etc). LSI comment number 58 Page=101 Subtype=Highlight Author=Brian Day Comment= dwords Does this sentence need a small caveat to allow for deletable primitives to not be forwarded? LSI comment number 59 Page=103 Subtype=Highlight Author=Brad Besmer Comment= logical phys?? ports?? LSI comment number 60 Page=104 Subtype=Highlight Author=Brad Besmer Comment= Ignored by SAS target ports. s/b SAS target ports shall ignore this Broadcast. (Same as Broadcast(SES)) LSI comment number 61 Page=104 Subtype=Text Author=Brad Besmer Comment= Should this also have this text? SAS target ports shall ignore this Broadcast. LSI comment number 62 Page=105 Subtype=Highlight Author=George Penokie Comment=This is a << or >> as both cases can't be true at the same time. LSI comment number 63 Page=105 Subtype=Text Author=Brad Besmer Comment= This paragraph should be located after the counters themselves are described (ie. just before the See 4.11 paragraph). LSI comment number 64 Page=105 Subtype=Text Author=Brad Besmer Comment= This does not specify the special broadcast zoning rules specified in 4.9.5 LSI comment number 65 Page=106 Subtype=Text Author=Brad Besmer Comment=Also used in SMP Phy Control request. LSI comment number 66 Page=107 Subtype=Highlight Author=George Penokie Comment= This << device, SAS target device, and SAS target/initiator device shall include >> should be << device, and SAS target device shall include >> LSI comment number 67 Page=108 Subtype=Highlight Author=George Penokie Comment= This << SAS initiator port, SAS target port (e.g., including the STP target port in each STP/SATA bridge), and SAS target/initiator port shall >> should be << SAS initiator port and SAS target port (e.g., including the STP target port in each STP/SATA bridge) shall >> LSI comment number 68 Page=108 Subtype=Text Author=Brad Besmer Comment= Need to explain why this statement is being made? (because they use device name instead). LSI comment number 69 Page=111 Subtype=Highlight Author=Brian Day Comment= Not a deletable primitive This isn't true from the earlier rate matching insertion in the path. LSI comment number 70 Page=112 Subtype=Highlight Author=Brian Day Comment= ACK/ NAK/RRDY needs to include CREDIT_BLOCKED LSI comment number 71 Page=114 Subtype=Highlight Author=Brad Besmer Comment= FISs s/b FISes (FISes used in several other locations) LSI comment number 72 Page=121 Subtype=Text Author=Brad Besmer Comment=Should BROADCAST(ASYNC) be mentioned here? LSI comment number 73 Page=122 Subtype=Highlight Author=Brad Besmer Comment=maximum number of phys is not specified in 4.1.7 LSI comment number 74 Page=122 Subtype=StrikeOut Author=Brad Besmer Comment=closest to and LSI comment number 75 Page=124 Subtype=Highlight Author=George Penokie Comment= This << device, and thus have SAS addresses different >> should be << device, and shall have a SAS addresses different >> LSI comment number 76 Page=124 Subtype=Highlight Author=George Penokie Comment=This looks like it should not be in a note. LSI comment number 77 Page=124 Subtype=Highlight Author=George Penokie Comment= This << deasserted for n dwords, the SATA device >> should be << deasserted for n dwords, then the SATA device >> LSI comment number 78 Page=124 Subtype=Highlight Author=Brad Besmer Comment= physical s/b logical LSI comment number 79 Page=124 Subtype=Highlight Author=Brad Besmer Comment= physical s/b logical LSI comment number 80 Page=124 Subtype=Highlight Author=Brad Besmer Comment= physical s/b logical LSI comment number 81 Page=125 Subtype=Highlight Author=George Penokie Comment=This is a missing << ( >>. It should << ALIGN (0) be sent >> LSI comment number 82 Page=125 Subtype=Highlight Author=Brian Day Comment= 0) s/b (0) LSI comment number 83 Page=131 Subtype=Highlight Author=George Penokie Comment= Change all the << because ... ed...>> terms to << as a result of .... ing...>> in this table. For example << Broadcast (Change) as a result of the expander phy detecting that a SATA port LSI comment number 84 Page=131 Subtype=Highlight Author=George Penokie Comment= This << are not described. See >> should be << are not described by this standard. See >> LSI comment number 85 Page=132 Subtype=Highlight Author=Brad Besmer Comment= REPORT GENERAL adds a rule that table-to-table attachment is ONLY allowed in a self-configuring expander: A TABLE TO TABLE SUPPORTED bit set to one indicates that the expander device is a self-configuring expander device that supports its table routing phys being attached to table routing phys in other expander devices. The TABLE TO TABLE SUPPORTED bit shall only be set to one if the EXTERNALLY CONFIGURABLE ROUTE TABLE bit is set to zero. A TABLE TO TABLE SUPPORTED bit set to zero indicates that the expander device is not a self-configuring expander device that supports its table routing phys being attached to table routing phys in other expander devices. LSI comment number 86 Page=133 Subtype=Highlight Author=George Penokie Comment=Change to << as a result of >> LSI comment number 87 Page=133 Subtype=Highlight Author=George Penokie Comment= This is an << or >> as you cannot route to all. Only one of the items will be valid. LSI comment number 88 Page=134 Subtype=Highlight Author=George Penokie Comment=This << SAS>> is in regular caps when it should be in small caps. LSI comment number 89 Page=135 Subtype=Highlight Author=George Penokie Comment= Change to << one >> to be consistent with how we talk about bit settings. LSI comment number 90 Page=135 Subtype=Highlight Author=George Penokie Comment= Change to << zero >> to be consistent with how we talk about bit settings. LSI comment number 91 Page=135 Subtype=Highlight Author=Brian Day Comment= Broadcast (Expander) it shall: s/b/ Broadcast (Expander) to indicate reduced functionality it shall: Don't want the following actions to take place for the PVD phy event threshold case. Maybe just being in this section is sufficient? LSI comment number 92 Page=136 Subtype=Highlight Author=Brad Besmer Comment= an end device s/b a SAS initiator device or self-configuring expander device LSI comment number 93 Page=136 Subtype=Highlight Author=Brad Besmer Comment= end s/b SAS initiator device or self-configuring expander device LSI comment number 94 Page=138 Subtype=Highlight Author=Brad Besmer Comment= device s/b device with the CONFIGURES OTHERS bit set to one in the REPORT GENERAL response (see 10.4.3.4) LSI comment number 95 Page=138 Subtype=StrikeOut Author=Brian Day Comment= If the discover process occurs and any phy within the expander device is in the process of a link reset sequence resulting from an SMP PHY CONTROL function (see 10.4.3.28) phy operation of LINK RESET or HARD RESET, then the management device server shall set the NEGOTIATED PHYSICAL LINK RATE field (see table 279) to RESET_IN_PROGRESS in the SMP DISCOVER response (see 10.4.3.10). This statement is not entirely accurate. Al the rules are listed in the SP state machine. For example, if previous value was UNSUPPORTED_PHY_ATTACHED, the SMP PHY CONTROL will not change that value to RESET_IN_PROGRESS. LSI comment number 96 Page=139 Subtype=Text Author=Brad Besmer Comment= Several permutations are not specified: 6 3 1.5 0 0 0 N/A 0 0 1 Rule 3 0 1 0 Rule 2 0 1 1 Not Specified -> Rule 2? 1 0 0 Rule 1 1 0 1 Not Specified -> Rule 1? 1 1 0 Not Specified -> Rule 1? 1 1 1 Not Specified -> Rule 1? Rule 1 = No MP Rule 2 = MP 6 to 3, No MP for 3 Rule 3 = MP 6 to 3, 3 to 1.5 LSI comment number 97 Page=139 Subtype=Highlight Author=Brad Besmer Comment= RM is also used for: - 3 Gbps connections on 6 Gbps logical links - 1.5 Gbps connections on 6 Gbps logical links Perhaps more generic note: Rate matching is used for lower rate connections across higher rate logical links. LSI comment number 98 Page=139 Subtype=Text Author=Brad Besmer Comment= This seems to be written from the perspective of a single SAS initiator device, however consider the case of Self Config Expanders performing this, then these rules need to consider both target phys and intiator phys. Another case to consider is multiple SAS Initiator devices with mixed rates (ie. 1 at 3G another at 6G). LSI comment number 99 Page=139 Subtype=Highlight Author=Brad Besmer Comment= it discovers externally s/b the management application client discovers an externally LSI comment number 100 Page=139 Subtype=Highlight Author=Brad Besmer Comment= two levels s/b two levels or more LSI comment number 101 Page=139 Subtype=Text Author=Brad Besmer Comment=Conflicts with Table to Table supported in REPORT GENERAL LSI comment number 102 Page=141 Subtype=Highlight Author=George Penokie Comment= Global - There needs to be consistency here. I other places an << _ >> is used. Here a space is used << 00000000 00000000h >> one or the other needs to be selected and used throughout the standard. LSI comment number 103 Page=141 Subtype=Highlight Author=Brad Besmer Comment=What about PHY VACANT? LSI comment number 104 Page=142 Subtype=Highlight Author=George Penokie Comment= This statement implies that all expander compliant with this standard will support table-to-table routing. That is not correct. So this << devices compliant with this standard (i.e., supporting table-to-table attachments) are >> should be << devices supporting table-to-table attachments are >> LSI comment number 105 Page=142 Subtype=Highlight Author=Brian Day Comment= Assuming the level 1... Suggest If the level 1... LSI comment number 106 Page=147 Subtype=Highlight Author=Brad Besmer Comment=may not be true if route table optimization is enabled LSI comment number 107 Page=150 Subtype=Highlight Author=George Penokie Comment= This << numbered 0 through 127 or 255. All phys >> should be << numbered 0 through 127 or 0 through 255. All phys >> LSI comment number 108 Page=150 Subtype=Highlight Author=George Penokie Comment= There should be << . >> at the end of the sentences in this table. That would add 3 periods. LSI comment number 109 Page=151 Subtype=Highlight Author=George Penokie Comment= This << describes the reasons for which a zoning expander device accepts the SMP >> should be << describes when a zoning expander device accepts the SMP >> LSI comment number 110 Page=151 Subtype=Square Author=George Penokie Comment= Center all the << yes >> and << no >> in these 3 columns and center the cell headings. LSI comment number 111 Page=151 Subtype=Highlight Author=Brad Besmer Comment= and/or s/b and I don't see the reason for the "or" case here, as all 4 settings need to be maintained. LSI comment number 112 Page=151 Subtype=Highlight Author=Brad Besmer Comment= This table does not seem to belong in the "zoning overview" section. LSI comment number 113 Page=151 Subtype=Highlight Author=Brad Besmer Comment= active s/b current? the term "active zone permission" only occurs twice in the doc, here and in the glossary. (unless global comment to change current to active is accepted) LSI comment number 114 Page=151 Subtype=Highlight Author=Brad Besmer Comment= support for several other Report General fields are also required: NUMBER OF ZONE GROUPS ZONE LOCKED LSI comment number 115 Page=152 Subtype=Highlight Author=Brad Besmer Comment= Could this not simply be replaced with: The ZPSDS is extended as shown below after the zone manager completes zone configuration (see 4.9.6). LSI comment number 116 Page=152 Subtype=Highlight Author=Brad Besmer Comment= both the expander s/b both of the expander or both expander LSI comment number 117 Page=153 Subtype=Highlight Author=Brad Besmer Comment= Could this not simply be replaced with: The ZPSDS is extended as shown below after the zone manager completes zone configuration (see 4.9.6). LSI comment number 118 Page=153 Subtype=Text Author=Brad Besmer Comment=This seems to be duplicate of below paragraph. LSI comment number 119 Page=154 Subtype=Square Author=George Penokie Comment= A slight adjustment to the column width or the left/right cell margins would put the footnote reference on the same line as the text. This should be done. LSI comment number 120 Page=154 Subtype=Highlight Author=Brad Besmer Comment= current what is the meaning of the word current in this context? 1) values defined "currently" in this standard? 2) current zone phy information (as opposed to saved/default) 3) something else LSI comment number 121 Page=155 Subtype=StrikeOut Author=Brian Day Comment=thus LSI comment number 122 Page=157 Subtype=Highlight Author=George Penokie Comment= Global - The conventions section defines [...] as << Brackets enclose optional or conditional parameters and arguments >> That definition does not seem to fit here. Either the definition needs to change or a new convention needs to be defined. LSI comment number 123 Page=157 Subtype=Highlight Author=Brad Besmer Comment= power loss. s/b there is no power loss and no expander device reduced functionality (see 4.6.8). LSI comment number 124 Page=158 Subtype=Highlight Author=George Penokie Comment=Should be << one >> LSI comment number 125 Page=158 Subtype=Highlight Author=George Penokie Comment=Should be << one >> LSI comment number 126 Page=158 Subtype=Highlight Author=George Penokie Comment=Should be << zero >> LSI comment number 127 Page=158 Subtype=Highlight Author=George Penokie Comment=Should be << zero >> LSI comment number 128 Page=158 Subtype=Highlight Author=George Penokie Comment= This << determination of which such SAS addresses to include is vendor-specific >> should be << determination of which SAS addresses to include is vendor-specific >> LSI comment number 129 Page=158 Subtype=Text Author=Brad Besmer Comment=Don't end-devices need to be in this list? LSI comment number 130 Page=159 Subtype=StrikeOut Author=Brian Day Comment= an OPEN_REJECT in response to the connection request as follows LSI comment number 131 Page=160 Subtype=Text Author=Brad Besmer Comment= This is a really cool diagram :), just don't understand what this has to do with "Source zone group and destination zone group determination". LSI comment number 132 Page=162 Subtype=Highlight Author=George Penokie Comment= Unless the BPP can get both of these messages at the same time this is an << or >>. LSI comment number 133 Page=162 Subtype=Highlight Author=Brian Day Comment= a hot-plug timeout So is this the correct thing to do if the very next COMINIT is not detected by the SATA device, and a hot plug time expires until the expander tries again to do the link reset sequence? LSI comment number 134 Page=163 Subtype=Square Author=George Penokie Comment= This does not appear to be an ordered list. Change it to an a,b,c list. LSI comment number 135 Page=163 Subtype=Highlight Author=Brad Besmer Comment= zoning expander devices are required s/b zoning expander devices within the ZPSDS are required LSI comment number 136 Page=163 Subtype=Highlight Author=Brad Besmer Comment= This requires 2 SMP requests to each expander: 1) Zone Lock 2) Report General The Lock state could change between these 2 states. Probably the easiest change here is to add a copy of the CONFIGURING Bit in the ZONE LOCK response. LSI comment number 137 Page=163 Subtype=Highlight Author=Brad Besmer Comment=shall only accept LSI comment number 138 Page=163 Subtype=Highlight Author=Brad Besmer Comment= Do we need to add REPORT GENERAL to this list, so other devices can determine if the expander is configuring. LSI comment number 139 Page=164 Subtype=Highlight Author=George Penokie Comment= This is a list of conditions of which any one could occur to it is an << or >> list. LSI comment number 140 Page=164 Subtype=Highlight Author=Brad Besmer Comment=See comment for 2) LSI comment number 141 Page=165 Subtype=Highlight Author=George Penokie Comment= This << If it receives an SMP ZONE >> should be << If the zone manager receives an SMP ZONE >> LSI comment number 142 Page=165 Subtype=Highlight Author=George Penokie Comment= This << If it receives an SMP ZONE >> should be << If the zone manager receives an SMP ZONE >> LSI comment number 143 Page=165 Subtype=Highlight Author=George Penokie Comment= This << The zone lock inactivity timer is supported by all zoning expander devices. The use of a timer ensures that if the zone manager disappears >> should be << The mandatory zone lock inactivity timer (see x.x.x) ensures that if the zone manager disappears >> LSI comment number 144 Page=165 Subtype=Highlight Author=Brad Besmer Comment= configuration s/b zone configuration LSI comment number 145 Page=165 Subtype=Highlight Author=Brad Besmer Comment= is s/b shall be LSI comment number 146 Page=166 Subtype=Highlight Author=George Penokie Comment= This << The optional Protocol-Specific diagnostic page >> should be << The Protocol-Specific diagnostic page >> LSI comment number 147 Page=166 Subtype=Highlight Author=George Penokie Comment= This << The optional SMP PHY TEST FUNCTION function >> should be << The SMP PHY TEST FUNCTION function >> LSI comment number 148 Page=166 Subtype=Highlight Author=George Penokie Comment= Remove note and change to << See tgable xx for a definition of wrapping counters that count those same events. >> LSI comment number 149 Page=167 Subtype=Highlight Author=George Penokie Comment= I cannot parse this so it makes any sense << but the SMP CONFIGURE PHY EVENT function (see 10.4.3.30) allows the events to count/record to be specified.>> this needs to be fixed and the << / >> removed. LSI comment number 150 Page=167 Subtype=Text Author=Brad Besmer Comment=Split this table into sections similar to Table 242. LSI comment number 151 Page=168 Subtype=StrikeOut Author=George Penokie Comment=Don't need this word. LSI comment number 152 Page=168 Subtype=Highlight Author=George Penokie Comment=Change to << as a result of >> LSI comment number 153 Page=169 Subtype=Highlight Author=George Penokie Comment= This << only bytes 2 and 3 of the PHY EVENT field are used >> should be << only byte 2 and byte 3 of the PHY EVENT field are used >> LSI comment number 154 Page=169 Subtype=Highlight Author=George Penokie Comment=Change to << as a result of >> LSI comment number 155 Page=170 Subtype=StrikeOut Author=George Penokie Comment=Don't need this word. LSI comment number 156 Page=170 Subtype=Highlight Author=George Penokie Comment=Change to << as a result of >> LSI comment number 157 Page=172 Subtype=Highlight Author=George Penokie Comment=Change to << one >> LSI comment number 158 Page=172 Subtype=Highlight Author=George Penokie Comment=Change to << two >> LSI comment number 159 Page=172 Subtype=Highlight Author=George Penokie Comment=Change to << two >> LSI comment number 160 Page=172 Subtype=Highlight Author=George Penokie Comment=Change to << two >> LSI comment number 161 Page=172 Subtype=Highlight Author=George Penokie Comment=Change to << two >> LSI comment number 162 Page=172 Subtype=Highlight Author=George Penokie Comment=Change to << two >> LSI comment number 163 Page=172 Subtype=Highlight Author=George Penokie Comment=Change to << one or two >> LSI comment number 164 Page=173 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 165 Page=173 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 166 Page=173 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 167 Page=173 Subtype=Highlight Author=George Penokie Comment=Change to << one to four >> LSI comment number 168 Page=173 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 169 Page=173 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 170 Page=173 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 171 Page=173 Subtype=Highlight Author=George Penokie Comment=Change to << one to four >> LSI comment number 172 Page=173 Subtype=Highlight Author=George Penokie Comment=Change to << one to four >> LSI comment number 173 Page=173 Subtype=Highlight Author=George Penokie Comment=Change to << one to four >> LSI comment number 174 Page=174 Subtype=Highlight Author=George Penokie Comment=Change to << one to four >> LSI comment number 175 Page=174 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 176 Page=174 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 177 Page=174 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 178 Page=174 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 179 Page=174 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 180 Page=174 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 181 Page=174 Subtype=Highlight Author=George Penokie Comment=Change to << one to four >> LSI comment number 182 Page=175 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 183 Page=175 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 184 Page=175 Subtype=Highlight Author=George Penokie Comment=Change to << one to four >> LSI comment number 185 Page=175 Subtype=Highlight Author=George Penokie Comment=Change to << one to four >> LSI comment number 186 Page=181 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 187 Page=181 Subtype=Highlight Author=George Penokie Comment=Change to << four >> LSI comment number 188 Page=195 Subtype=Highlight Author=George Penokie Comment= This << connection is vendor specific. >> should be << connection are vendor specific. >> LSI comment number 189 Page=196 Subtype=StrikeOut Author=George Penokie Comment=This is an extra one. LSI comment number 190 Page=197 Subtype=Highlight Author=George Penokie Comment= This << physical links, because one controller's physical links 0 and 1 are attached the other controller's physical links 3 and 2, respectively.>> should be << links, (i.e., one controller's physical link 0 and physical link 1 are attached to the other controller's physical link 3 and physical link 2, respectively). >> LSI comment number 191 Page=197 Subtype=Highlight Author=George Penokie Comment= This << use physical links 0, 1, and 2, then only >> should be << use physical link 0, physical link 1, and physical link 2, then only >> LSI comment number 192 Page=197 Subtype=Highlight Author=George Penokie Comment= This << over physical links 1 and 2 is possible >> should be << over physical link 1 and physical link 2 is possible >> LSI comment number 193 Page=199 Subtype=Highlight Author=George Penokie Comment= This << physical links, because the controller's physical links 0, 1, 2, and 3 are attached to the backplane's physical links 3, 2, 1, and 0, respectively. >> should be << physical links (i.e., the controller's physical link 0, physical link 1, physical link 2, and physical link 3 are attached to the backplane's physical link 3, physical link 2, physical link 1, and physical link 0, respectively. >> LSI comment number 194 Page=199 Subtype=Highlight Author=George Penokie Comment= This << physical links 0, 1, and 2, then only communication over physical links 1and 2 is possible >> should be << physical link 0, physical link 1, and physical link 2, then only communication over physical link 1and physical link 2 is possible >> LSI comment number 195 Page=202 Subtype=Highlight Author=George Penokie Comment= This is a missing << ) >> It should be << to an Rx + of the other connector). >> LSI comment number 196 Page=207 Subtype=Highlight Author=George Penokie Comment= This << may support one, two, three, or four physical links. SAS >> should be << may support one physical link, two physical links, three physical links, or four physical links. SAS >> LSI comment number 197 Page=212 Subtype=Highlight Author=George Penokie Comment= Move this << All NEXT values expressed in dB format in a passive transfer network shall have negative dB magnitude. >> to after the equation and add a period to the end. LSI comment number 198 Page=212 Subtype=Highlight Author=Mike Jenkins Comment= To avoid any ambiguity, this table should probably be entitled: "Maximum limits for s-parameters of cable assemblies and backplanes" LSI comment number 199 Page=213 Subtype=Highlight Author=George Penokie Comment= This << Because the 6 Gbps transmitter device S-parameter specifications do not include the mated connector, transmitter device >> should be << The 6 Gbps transmitter device S-parameter specifications do not include the mated connector, therefore the transmitter device >> LSI comment number 200 Page=213 Subtype=Highlight Author=George Penokie Comment= This << ends. One end of a TxRx connection is a ITS or CTS compliance point, and the other end of the TxRx connection is the corresponding IR or CR compliance point. >> should be << ends (i.e., one end of a TxRx connection is a ITS or CTS compliance point, and the other end of the TxRx connection is the corresponding IR or CR compliance point). >> LSI comment number 201 Page=219 Subtype=Highlight Author=George Penokie Comment= This << assembly combined with a backplane with a SAS Drive backplane receptacle >> should be << assembly combined with a backplane and a SAS Drive backplane receptacle >> LSI comment number 202 Page=219 Subtype=Highlight Author=George Penokie Comment= This << attached; SATA defines the signal characteristics that the SATA device delivers and that the SAS backplane is required to deliver to the SATA device. There >> should be << attached (i.e., SATA defines the signal characteristics that the SATA device delivers and that the SAS backplane is required to deliver to the SATA device). There >> LSI comment number 203 Page=219 Subtype=Highlight Author=George Penokie Comment=Move the << however >> to the beginning of the sentence. LSI comment number 204 Page=221 Subtype=Highlight Author=George Penokie Comment= This << specified probe points in specified test loads >> should be << specified probe points with specified test loads >> LSI comment number 205 Page=221 Subtype=Highlight Author=Brian Day Comment= For 6 Gbps SATA, see SATA-2 regarding Gen3 transmitter device and receiver device requirements. However, SATA-2 (referred as the 2.6 spec at beginning of this standard) does not define Gen3 requirements. LSI comment number 206 Page=228 Subtype=Highlight Author=George Penokie Comment= This << The reference transmitter test load is a 10 m Mini SAS 4x cable assembly. >> should be << The reference transmitter test load for 6 Gbps is a 10 m Mini SAS 4x cable assembly. >> LSI comment number 207 Page=229 Subtype=Highlight Author=George Penokie Comment= This is note is troubling for more than one reason. One is that it references a proposal. That is not going to fly at ISO and my be a problem at ANSI. I see two solutions- one would be to put it as an annex of this standard the other would be to create a technical report. The other problem is have a trademark. I don't have any good solution to that other than deleting it. LSI comment number 208 Page=229 Subtype=Highlight Author=Brian Day Comment= This model... This sentence appears to be larger font than rest of the note. LSI comment number 209 Page=229 Subtype=Highlight Author=Mike Jenkins Comment= The reference in 07-486r3 was to a "pulse response", not an "impulse response". The two are similar, but not the same. Pulse response can be mathematically derived from impulse response, but we need to be clear about which is which. LSI comment number 210 Page=230 Subtype=Highlight Author=George Penokie Comment= This << A.C. coupling requirements for transmitter devices are described in 5.3.6.1. A.C. coupling requirements for receiver devices are described in 5.3.7.1. >> should be << See 5.3.6.1 for the A.C. coupling requirements for transmitter devices. See 5.3.7.1 for the A.C. coupling requirements for receiver devices. >> LSI comment number 211 Page=231 Subtype=Highlight Author=George Penokie Comment= This << such that the over TxRx connection requirements are >> should be << such that the overall TxRx connection requirements are >> I think. LSI comment number 212 Page=231 Subtype=Highlight Author=George Penokie Comment= This << A passive equalizer network, if present, shall >> should be << A equalizer network, if present, shall >> as the current wording implies that an active equalizer would not be considered part of the TxRx connection. LSI comment number 213 Page=231 Subtype=Highlight Author=George Penokie Comment= This << error ratio (BER) that is less than 10-12 (i.e., fewer >> contradicts the following statement in section 5.3.3.3.3 that states << error ratio (BER) that is less than 10-15 (i.e., fewer than one bit error per 1015 bits) >>. The solution is to move the 10-12 wording into section 5.3.3.3.2 which applies to 1.5 and 3 Gbps. LSI comment number 214 Page=231 Subtype=Highlight Author=George Penokie Comment= This << an actual BER that is less than 0-12. >> is a really bad thing to state. It should be << an actual BER that is less that 10-15 >> LSI comment number 215 Page=232 Subtype=Highlight Author=George Penokie Comment= I don't understand what this is stating as it does not read as a complete sentence << TxRx connections defined in this standard for 1.5 Gbps and 3 Gbps (see 5.3.3.3.2), and TxRx connections supporting SATA. >> It needs to be fixed. LSI comment number 216 Page=233 Subtype=Highlight Author=George Penokie Comment= From what connector ?? This << made from that connector >> should be << made from the connector nearest the receiver device >> I think. LSI comment number 217 Page=233 Subtype=Highlight Author=George Penokie Comment= This << The amplitude is defined as >> should be << Where the amplitude is defined as >> LSI comment number 218 Page=234 Subtype=Highlight Author=George Penokie Comment= This << Annex A defines the required pattern on the physical link and provides information regarding >> should be << See annex A for the required pattern on the physical link and for information regarding >> LSI comment number 219 Page=234 Subtype=Highlight Author=George Penokie Comment= This << the actual jitter and thus may overstate the transmitter device jitter. To >> should be << the actual jitter and as a result the transmitter device jitter may be overstated. To >> LSI comment number 220 Page=242 Subtype=Highlight Author=Mike Jenkins Comment= Change to 84 mV. ref 08-146r1. LSI comment number 221 Page=246 Subtype=Highlight Author=George Penokie Comment= This is note is troubling for more than one reason. One is that it references a proposal. That is not going to fly at ISO and my be a problem at ANSI. I see two solutions- one would be to put it as an annex of this standard the other would be to create a technical report. The other problem is have a trademark. I don't have any good solution to that other than deleting it. LSI comment number 222 Page=246 Subtype=Text Author=Mike Jenkins Comment= Change to 850 & delete note b. ref: 08-144r1, 08-146r1 LSI comment number 223 Page=246 Subtype=Highlight Author=Mike Jenkins Comment= Change DJ to BUJ with value of 0.10 (16.7 ps) ref: 08-144r1, 08-146r1 LSI comment number 224 Page=247 Subtype=Highlight Author=George Penokie Comment= Figure 127 needs to have the correct capitalization, spelling, add spaces to numbers for ISO style, etc. LSI comment number 225 Page=248 Subtype=Highlight Author=George Penokie Comment= This << points is illustrated in figure >> should be << points is defined in figure >> LSI comment number 226 Page=249 Subtype=Highlight Author=George Penokie Comment= What is the term << imply >> doing in this standard? It has no valid definition and can only add to confusion. Either << These are the required signal tolerance characteristics of the receiver device. >> Or not. Or perhaps you mean << The required signal tolerance characteristics of the receiver device may be derived from the delivered signal characteristic defined in table 68. >> But that is only marginally better. There should be a table with the receiver device characteristics, not this unclear vague definition.. LSI comment number 227 Page=250 Subtype=Highlight Author=George Penokie Comment=<< set up >> should be << setup >> LSI comment number 228 Page=250 Subtype=Highlight Author=George Penokie Comment= This << signals. Intra-pair skew is defined as the time difference between the me >> should be << signals. Where intra-pair skew is the time difference between the me >> LSI comment number 229 Page=252 Subtype=Highlight Author=George Penokie Comment= This is note is troubling for more than one reason. One is that it references a proposal. That is not going to fly at ISO and my be a problem at ANSI. I see two solutions- one would be to put it as an annex of this standard the other would be to create a technical report. The other problem is have a trademark. I don't have any good solution to that other than deleting it. LSI comment number 230 Page=253 Subtype=Square Author=George Penokie Comment= This equation should be centered on the page and it looks like it is not used the default fonts for equations. And where is the <> that tells the reader what y, x, d, and k are> LSI comment number 231 Page=253 Subtype=Highlight Author=George Penokie Comment= This << A receiver device shall satisfy the stressed receiver sensitivity test >> should be << A receiver device shall pass the stressed receiver sensitivity test >> LSI comment number 232 Page=253 Subtype=Highlight Author=George Penokie Comment= This << The receiver device under test must demonstrate a BER that >> shall be << The receiver device under test shall meet a BER that >> LSI comment number 233 Page=253 Subtype=Highlight Author=George Penokie Comment= Global All the << (IR or CR) >> in this section need to changed to << (i.e., IR or CR) >>. LSI comment number 234 Page=254 Subtype=Highlight Author=George Penokie Comment= This << representative of the SAS-2 reference channel while subjected to the budgeted >> should be << representative of the reference channel defined in this standard for 6 Gbps channels while subjected to the budgeted >> LSI comment number 235 Page=254 Subtype=Highlight Author=George Penokie Comment= This << This specification pertains to the delivered signal >> should be << This standard pertains to the delivered signal >> LSI comment number 236 Page=254 Subtype=Highlight Author=George Penokie Comment= This term << WDP >> is used no were else in the standard what the heck is it? Define it or delete it. LSI comment number 237 Page=254 Subtype=Highlight Author=George Penokie Comment= This term << Palloc >> is used no were else in the standard what the heck is it? Define it or delete it. LSI comment number 238 Page=254 Subtype=Highlight Author=George Penokie Comment=<< least 1 000 hits. >> of what? Snowballs, baseballs, rocks? LSI comment number 239 Page=254 Subtype=Highlight Author=Mike Jenkins Comment= The last 5 lines in table 72 have nothing to do with point A. Change "A" to "IR or CR". LSI comment number 240 Page=254 Subtype=Highlight Author=Mike Jenkins Comment= LSI comment number 241 Page=254 Subtype=Highlight Author=Mike Jenkins Comment= LSI comment number 242 Page=254 Subtype=Highlight Author=Mike Jenkins Comment= Change to 0.09(min), 0.10(typ), 0.11(max) ref 08-144r1 & 08-146r1 LSI comment number 243 Page=254 Subtype=Highlight Author=Mike Jenkins Comment= Change 800(max) to 830(min), 850(typ), 870(max). All these values need to be bounded above & below. ref 08-144r1 & 08-146r1. LSI comment number 244 Page=254 Subtype=Highlight Author=Mike Jenkins Comment=Change to 0.135(min), 0.150(typ), 0.165(max) LSI comment number 245 Page=254 Subtype=Highlight Author=Mike Jenkins Comment= LSI comment number 246 Page=254 Subtype=Highlight Author=Mike Jenkins Comment= Change to 100(min), 107(typ), 115(max) and add note to measure at center of vertical histogram at crossing point. ref 08-144r1 & 08-146r1 LSI comment number 247 Page=255 Subtype=Highlight Author=George Penokie Comment=<< he >> should be <>. LSI comment number 248 Page=255 Subtype=StrikeOut Author=George Penokie Comment=This << impact of >> should be deleted as it adds nothing. LSI comment number 249 Page=255 Subtype=Highlight Author=George Penokie Comment= This << representative of and at least as stressful as the reference >> should be << representative of, and at least as stressful as, the reference >> LSI comment number 250 Page=255 Subtype=Highlight Author=George Penokie Comment= This << point (IR or CR) per the specification in table 72. >> should be << point (IR or CR) as defined in table 72. >> LSI comment number 251 Page=255 Subtype=Highlight Author=George Penokie Comment= This << than that budgeted and an |SDD21| comparable >> should be << than that budgeted with an |SDD21| comparable >> LSI comment number 252 Page=255 Subtype=Highlight Author=George Penokie Comment= This << device shall satisfy the jitter tolerance test >> should be << device shall, at a minimum, meet the jitter tolerance test >> LSI comment number 253 Page=255 Subtype=StrikeOut Author=George Penokie Comment= This << The jitter tolerance test leverages the receiver device physical test hardware. >> provides no useful information and should be deleted. LSI comment number 254 Page=255 Subtype=Highlight Author=Mike Jenkins Comment= LSI comment number 255 Page=255 Subtype=Text Author=Mike Jenkins Comment= section 5.3.7.6 discusses only 1.5 & 3Gb/s testing. The only reference to 6G is a reference back to this section. 08-144r1, slide 9, recommends a reasonable solution for this. LSI comment number 256 Page=256 Subtype=Highlight Author=George Penokie Comment= Besides the term << can >> needing to be removed, the reference to a proposal is not allowed. LSI comment number 257 Page=256 Subtype=Highlight Author=George Penokie Comment= This << SSC shall be enabled if supported by the receiver device and shall not disabled if the not supported by the receiver device. >> has so many things wrong with it I don't know were to start. For example: Does it apply to 1.5, 3, and 6 or just 1.5 and 3? What does << shall not disabled if the not supported by the receiver device >> this mean? Aside from a missing <>. It appears to be saying that you shall not disable SSC if SSC is not supported. How can you not disable something that is notthere to be disabled? LSI comment number 258 Page=256 Subtype=Highlight Author=Mike Jenkins Comment= The replacement to figure 132, below, as proposed in 08-144r1, still shows an RJ input. To avoid any misunderstanding, I want to assert that the solutions discussed in committee did still have RJ (and BUJ other than SJ) minimized. That is, this line remains as is. LSI comment number 259 Page=257 Subtype=Highlight Author=George Penokie Comment= In this << (generation - 1) >> it is not clear what the exponent is supposed to be. LSI comment number 260 Page=257 Subtype=Highlight Author=George Penokie Comment= In this << (generation - 1) >> it is not clear what the exponent is supposed to be. LSI comment number 261 Page=258 Subtype=Highlight Author=George Penokie Comment= This << vendor-specific, but is intended to provide the >> should be << vendor-specific, but should provide the >> LSI comment number 262 Page=259 Subtype=Highlight Author=George Penokie Comment= This << standard were only allowed to transmit with an >> should be << standard only transmitted an >> LSI comment number 263 Page=259 Subtype=Highlight Author=George Penokie Comment= This << standard were only allowed to transmit with an >> should be << standard only transmitted an >> LSI comment number 264 Page=259 Subtype=Highlight Author=George Penokie Comment= This << However, it may implement a common >> should be << However, a SAS device or expander device may implement a common >> LSI comment number 265 Page=260 Subtype=Highlight Author=George Penokie Comment= this << spreading is supported, both shall be supported. >> should be << spreading is implemented, both shall be implemented. >> LSI comment number 266 Page=260 Subtype=Highlight Author=George Penokie Comment= This << size defined in table 79 to hold any dwords >> should be << size defined in table 79 that is large enough to hold any dwords >> LSI comment number 267 Page=260 Subtype=Highlight Author=Brian Day Comment= Minimum buffer size With the addition of the SSC slope requirement of 1200 ppm/us, is the calculation accurate, or can these values be reduced? LSI comment number 268 Page=263 Subtype=StrikeOut Author=George Penokie Comment= This << greatly >> adds nothing to the standard and should be deleted. LSI comment number 269 Page=264 Subtype=Highlight Author=George Penokie Comment= This << the order that would be indicated by the >> should be << the order indicated by the >> LSI comment number 270 Page=265 Subtype=Highlight Author=George Penokie Comment= This << disparity (current RD - or current RD +) >> should be << disparity (i.e., current RD - or current RD +) >> LSI comment number 271 Page=265 Subtype=Highlight Author=George Penokie Comment= This << represent two (not necessarily different) characters, >> should be << represent two, not necessarily different, characters, >> LSI comment number 272 Page=265 Subtype=Highlight Author=George Penokie Comment= The sentence leading into the a,b,c list has no connecting words that indicate what the relationship between the sentence and the a.b.c list is. This needs to be fixed. LSI comment number 273 Page=271 Subtype=Highlight Author=George Penokie Comment= This note << NOTE 35 - K28.1, K28.5 >> seems like it should be a footnote in the above table. I say make it that way. LSI comment number 274 Page=275 Subtype=Highlight Author=George Penokie Comment= This note << NOTE 36 - Previous versions of >> should not be a note. It should be normative text. LSI comment number 275 Page=275 Subtype=Text Author=George Penokie Comment= There appears to be conflicting requirements on OOB signals containing SSC. The table appears to require SSC but SSC is optional and not all devices are required to support it. That is correctly stated in the note. The wording in the table has to change to allow SSC to be optional. Perhaps moving the note into the table as a footnote and deleting the sentence << Based on 1.5 Gbps clock tolerance with center-spreading SSC (see table 53 in 5.3.3 and table 75 in 5.3.8.1). >> and replacing it with a reference to that footnote would solve the problem. LSI comment number 276 Page=276 Subtype=StrikeOut Author=George Penokie Comment= Since when did we gain the ability to predict the future? This note << NOTE 37 - Transmitter devices compliant with future versions of this standard may not transmit OOB bursts consisting of ALIGN [0] primitives. >> should be deleted. LSI comment number 277 Page=278 Subtype=Highlight Author=George Penokie Comment= This << and may but should not detect an OOB signal >> should at least be changed to << and may, but should not, detect an OOB signal >> but I would rather see if restated as << and should not detect an OOB signal >> LSI comment number 278 Page=280 Subtype=Highlight Author=George Penokie Comment= This << attached phy (one of the port select >> should be << attached phy (i.e., one of the port select >> LSI comment number 279 Page=280 Subtype=Highlight Author=George Penokie Comment= This << in figure 138 causes the attached SATA port selector to select the >> should be << in figure 138 results in the attached SATA port selector selecting the >> LSI comment number 280 Page=281 Subtype=Highlight Author=George Penokie Comment= This should be an << or >> as any one of the items in the list will cause a reset sequence. LSI comment number 281 Page=282 Subtype=Highlight Author=George Penokie Comment= This << defined by SATA; see SATA-2 for detailed requirements. >> should be << defined by SATA (see SATA-2). >> LSI comment number 282 Page=282 Subtype=Highlight Author=Brian Day Comment= 54,6 s/b 54.6 same elsewhere in diagram LSI comment number 283 Page=283 Subtype=Highlight Author=George Penokie Comment=Add a reference here to the SP state machine section. LSI comment number 284 Page=284 Subtype=Highlight Author=George Penokie Comment= This note << NOTE 39 - If the receiving phy >> should be normative text. LSI comment number 285 Page=287 Subtype=Highlight Author=Brian Day Comment=us s/b ns LSI comment number 286 Page=288 Subtype=Highlight Author=George Penokie Comment=This note <> should be normative text LSI comment number 287 Page=289 Subtype=Highlight Author=George Penokie Comment=This should be a << or >> as it is a or b but not both a and b. LSI comment number 288 Page=289 Subtype=Text Author=George Penokie Comment=This would be clearer if it was changed into a 1,2,3 list. LSI comment number 289 Page=290 Subtype=Highlight Author=George Penokie Comment= This << and shall receive a 32-bit phy capabilities value from the attached phy. >> should be the 4th entry in the list. LSI comment number 290 Page=290 Subtype=Highlight Author=Brian Day Comment= receive s/b receives LSI comment number 291 Page=290 Subtype=Highlight Author=Brian Day Comment= is s/b are LSI comment number 292 Page=290 Subtype=Highlight Author=Brian Day Comment= is s/b shall be LSI comment number 293 Page=290 Subtype=Highlight Author=Brian Day Comment= The receiver shall use the START bit to detect the beginning of the phy capabilities bits.... add "...and establish the timing for the subsequent bits." LSI comment number 294 Page=290 Subtype=StrikeOut Author=Brian Day Comment= The START bit shall be set to one. The phy's receiver shall use this bit to establish the timing for the subsequent bits. LSI comment number 295 Page=296 Subtype=StrikeOut Author=George Penokie Comment= This << and >> should be deleted as right now it reads << and: or >> LSI comment number 296 Page=296 Subtype=Highlight Author=Brian Day Comment= settings s/b setting LSI comment number 297 Page=296 Subtype=StrikeOut Author=Brian Day Comment= there are no commonly supported settings This case is an UNSUPPORTED_PHY_ATTACHED in SP state machine now. So not a reset problem. LSI comment number 298 Page=297 Subtype=Highlight Author=George Penokie Comment= This << and proceed to Final-SNW negotiating 3 Gbps. >> should be item d in the above a,b,c list. LSI comment number 299 Page=298 Subtype=Highlight Author=George Penokie Comment= This << and proceed to Train-SNW negotiating based on SNW-3 phy capabilities bits. >> should be item d in the above a,b,c list. LSI comment number 300 Page=298 Subtype=StrikeOut Author=Brian Day Comment=negotiating LSI comment number 301 Page=300 Subtype=Highlight Author=Brian Day Comment= This figure doesn't show several training windows. Suggest: ... within the MTT interval. This figure illustrates when only a single commonly supported setting was exchanged in SNW-3. LSI comment number 302 Page=302 Subtype=Highlight Author=Brian Day Comment= Train-SNWs, if s/b Train-SNWs. If LSI comment number 303 Page=303 Subtype=Highlight Author=George Penokie Comment= This should be an << or >> as any one of the items in the list could be happen not all have to happen. LSI comment number 304 Page=305 Subtype=Highlight Author=George Penokie Comment= This << a power on, or a hard reset >> should be << a power on or a hard reset >>. Delete the comma. LSI comment number 305 Page=315 Subtype=Highlight Author=Brian Day Comment= a) list is not incrementing correctly. LSI comment number 306 Page=316 Subtype=Highlight Author=George Penokie Comment= This << supported, send a Set >> should be << supported, then send a Set >> LSI comment number 307 Page=316 Subtype=StrikeOut Author=Brian Day Comment= initialize and start the RCDT timer Not needed here, since this is already listed upon entry into this state. LSI comment number 308 Page=316 Subtype=Highlight Author=Brian Day Comment= the Physical Link Rate argument set to 1.5 Gbps. Is 1.5G operation required? If not, then setting to 1.5 isn't a requirement here, since OOB signalling with "effective" 1.5G OOB signal can happen with transmitter being set to something higher. I think item E can be deleted, since the appropriate Set Rate will happen prior to training. LSI comment number 309 Page=319 Subtype=StrikeOut Author=George Penokie Comment= This <> add nothing to the standard and should be deleted. LSI comment number 310 Page=319 Subtype=StrikeOut Author=George Penokie Comment= This << to indicate that the physical link has been brought up successfully in SAS mode >> adds nothing to the standard and should be deleted. LSI comment number 311 Page=319 Subtype=Highlight Author=George Penokie Comment= This << This transition may but should not occur after >> should at least be changed to << This transition may, but should not, occur after >> but I would rather see if restated as << This transition should not occur after l >> LSI comment number 312 Page=319 Subtype=Highlight Author=George Penokie Comment= This note <> contains as least 2 requirements. One requirement << If multiplexing is enabled and this state receives a DWS Lost message, this state does not send a Start DWS message >> should be in this section. The other << If multiplexing is enabled and this state receives a DWS Lost message, the state machine transitions to SP0:OOB_COMINIT. >> should be in the transition to OOB_COMINIT section. LSI comment number 313 Page=319 Subtype=Highlight Author=Brian Day Comment= layer s/b layer(s) could be multiple link layers if muxxing. LSI comment number 314 Page=319 Subtype=Highlight Author=Brian Day Comment= parity good s/b good parity LSI comment number 315 Page=320 Subtype=Highlight Author=Brian Day Comment= parity bad; s/b bad parity; LSI comment number 316 Page=320 Subtype=Highlight Author=Brian Day Comment= parity bad, s/b bad parity, LSI comment number 317 Page=321 Subtype=Highlight Author=George Penokie Comment= This << This transition shall occur if a) the MTT timer expires; and b) the Commonly Supported Settings state machine variable does not contain additional commonly supported settings. This is a phy reset problem. >> should be << This transition shall occur if there is a phy reset problem as a result of: a) the MTT timer expiring; and b) the Commonly Supported Settings state machine variable not containing additional commonly supported settings. >> LSI comment number 318 Page=321 Subtype=Highlight Author=Brian Day Comment= this state receives a Training Completed message before the TLT timer expires; and b) dword synchronization is acquired. s/b a) The TLT timer has not expired, b) this state receives a Training Complete message; and c) dword synchronization is acquired. (We do not want to make this transition if dword sync is aquired after the TLT time.) LSI comment number 319 Page=322 Subtype=Highlight Author=George Penokie Comment= This << This transition shall occur if: a) TRAIN_DONE Received message is not received before the MTT timer expires; and b) the Commonly Supported Settings state machine variable does not contain additional commonly supported settings. This is a phy reset problem. >> should be << This transition shall occur if there is a phy reset problem as a result of: a) the TRAIN_DONE Received message not being received before the MTT timer expires; and b) the Commonly Supported Settings state machine variable not containing additional commonly supported settings. >> LSI comment number 320 Page=322 Subtype=Highlight Author=George Penokie Comment= This << support SATA; expander devices >> should be << support SATA. Expander devices >> LSI comment number 321 Page=324 Subtype=Highlight Author=Brian Day Comment= Need to include new list item to send a Set Rate to the transmitter. a) Send a Set Rate to the SP transmitter with a Physical Link Rate argument set to the lowest supported link rate, and either an SSC On argument or an SSC Off argument. Also update figure to have the "Set Rate" arrow from this state. LSI comment number 322 Page=326 Subtype=Highlight Author=George Penokie Comment= This << This transition may but should not occur after >> should at least be changed to << This transition may, but should not, occur after >> but I would rather see if restated as << This transition should not occur after >> LSI comment number 323 Page=330 Subtype=Text Author=George Penokie Comment= This appears to be the last of the state machine drawings that contain meaningless information on the state transitions. Delete this. LSI comment number 324 Page=331 Subtype=Highlight Author=George Penokie Comment= In this << SP_DWS receiver. and the DWS Reset >> it looks like the comma is really a period. LSI comment number 325 Page=331 Subtype=StrikeOut Author=Brian Day Comment= If this state is entered from SP_DWS1:Valid1 or SP_DWS2:Valid2 and the DWS Reset Timeout timer has expired, this state may send a DWS Reset message to the SP state machine (e.g., if the phy chooses to initiate a new link reset sequence because dword synchronization has been lost for too long). Redundant with last sentence in this section. LSI comment number 326 Page=336 Subtype=Highlight Author=George Penokie Comment= This << to delay spin-up; this is called SATA spinup hold. This >> should be << to delay spin-up (i.e., SATA spinup hold). This >> LSI comment number 327 Page=337 Subtype=Highlight Author=George Penokie Comment= This << little-endian; they are just interpreted as first, >> should be << little-endian, they are interpreted as first, >> LSI comment number 328 Page=338 Subtype=StrikeOut Author=Brian Day Comment= SAS physical links, SATA also uses ALIGN(0) for speed negotiation. LSI comment number 329 Page=341 Subtype=Highlight Author=Brian Day Comment= passing s/b forwarding dwords same comment applies in other tables. LSI comment number 330 Page=352 Subtype=StrikeOut Author=Brian Day Comment= NOTE 45 - SATA devices are allowed to decode every dword starting with a K28.5 as an ALIGN, since ALIGN is the only primitive defined starting with K28.5. This is specifically discouraged in SATA 2.6, and so SAS should not encourage it. LSI comment number 331 Page=352 Subtype=Highlight Author=Brian Day Comment= substituted suggest periodically substituted (see 6.10) LSI comment number 332 Page=353 Subtype=Highlight Author=Brian Day Comment= A specific NOTIFY shall not be transmitted in more than three consecutive dwords until at least three other dwords have been transmitted. Why is this a requirement? Suggest deleting it. A little bit in conflict with the POWER LOSS EXPECTED description that says "at least 3 times" LSI comment number 333 Page=354 Subtype=Highlight Author=Brian Day Comment= stop writing data s/b if a block device, stop writing data... LSI comment number 334 Page=354 Subtype=StrikeOut Author=Brian Day Comment= If any frames are received by the SAS target device after receiving NOTIFY (POWER LOSS EXPECTED) before a connection is closed, then the SAS target device shall discard the received frames. I think the requirement to issue BREAK or CLOSE above is sufficient. LSI comment number 335 Page=358 Subtype=Highlight Author=George Penokie Comment= This << requested initiator/target role, >> should be << requested initiator role, target role, >> . LSI comment number 336 Page=358 Subtype=Highlight Author=George Penokie Comment= This << because it has reached its >> should be << the STP target port has reached its >> LSI comment number 337 Page=359 Subtype=Highlight Author=George Penokie Comment= This << continues running; if it is not already running, it is >> should be << continues running. If the I_T Nexus Loss timer is not already running, it is >> LSI comment number 338 Page=363 Subtype=Highlight Author=George Penokie Comment= This << internal buffer; this is called an overrun >> should be << internal buffer (i.e., an overrun) >> LSI comment number 339 Page=363 Subtype=Highlight Author=George Penokie Comment= This << internal buffer; this is called an underrun >> should be << internal buffer (i.e., an underrun) >> LSI comment number 340 Page=365 Subtype=Highlight Author=George Penokie Comment=Set up frame to prevent a line brake on a << / >>. LSI comment number 341 Page=365 Subtype=Highlight Author=George Penokie Comment= Tihs << NOTE 51 - These numbers >> should be made into a table footnote c in the above table. LSI comment number 342 Page=371 Subtype=Highlight Author=George Penokie Comment= This << transmitted or received; the next output of the generator is applied to the upper 16 bits >> should be << transmitted or received with the next output of the generator applied to the upper 16 bits >> LSI comment number 343 Page=371 Subtype=Highlight Author=George Penokie Comment= This note << NOTE 55 - Scrambling is not based >> should be made into normative text. LSI comment number 344 Page=378 Subtype=Highlight Author=George Penokie Comment= This note << NOTE 57 - In expander devices, the >> should be made into normative text. LSI comment number 345 Page=378 Subtype=Text Author=Brad Besmer Comment= Clarification needed on what to set REASON to for wide-ports? For example, if have 4-wide port (Phys 0-3), and receive HR on Phy 0, is REASON set to 2 for all 4 phys, or just Phy 0? Proposed wording from George: Hard reset (e.g., the port containing this phy received a HARD_RESET primitive during the hard reset sequence)(see 4.4.2), or SMP PHY CONTROL function HARD RESET phy operation (see 10.4.3.28) LSI comment number 346 Page=379 Subtype=Highlight Author=Brad Besmer Comment= DEVICE TYPE field, s/b DEVICE TYPE field, BREAK_REPLY CAPABLE bit, LSI comment number 347 Page=380 Subtype=Highlight Author=George Penokie Comment= This << If a SAS target/initiator port sets the INITIATOR PORT bit to one >> should be << If a SAS port sets the INITIATOR PORT bit to one >> LSI comment number 348 Page=380 Subtype=Highlight Author=George Penokie Comment= This << If a SAS target/ initiator port sets the INITIATOR PORT bit to >> should be << If a SAS port sets the INITIATOR PORT bit to >> LSI comment number 349 Page=380 Subtype=Highlight Author=George Penokie Comment= This << If a SAS target/initiator port accepts an >> should be << If a SAS port accepts an >> LSI comment number 350 Page=380 Subtype=Highlight Author=George Penokie Comment= This << If a SAS target/initiator port accepts >> should be << If a SAS port accepts >> LSI comment number 351 Page=381 Subtype=Highlight Author=George Penokie Comment= This << frame it intends to transmit >> should be << frame the SAS target port intends to transmit >> LSI comment number 352 Page=382 Subtype=Highlight Author=George Penokie Comment= This << connection that it intended to send at the >> should be << connection that the SAS port intended to send at the >> LSI comment number 353 Page=382 Subtype=Highlight Author=George Penokie Comment= This << unique value per SAS target port >> should be << unique value for each SAS target port >> LSI comment number 354 Page=382 Subtype=Highlight Author=George Penokie Comment= This << value when it has no >> should be << value when that SAS target port has no >> LSI comment number 355 Page=382 Subtype=Highlight Author=George Penokie Comment=This << and >> should be << or >> as only one case is true not all. LSI comment number 356 Page=382 Subtype=StrikeOut Author=Brad Besmer Comment= Zone group values between 128 and 255, inclusive, are reserved. Proposal 07-017r2 SAS-2 SAS-2 More zone groups (Steve Johnson, LSI Logic) LSI comment number 357 Page=383 Subtype=Highlight Author=Brian Day Comment= begin s/b is preceded by Muxxing sequence is not part of (begins) the id or hard reset sequence.. it's part of the phy reset sequence. LSI comment number 358 Page=390 Subtype=Highlight Author=George Penokie Comment= It seems like this << or >> should be << and >> but that would be a different requirement in that the state would do both a and b rather that have to pick either a or b. I'm not sure which was intended. LSI comment number 359 Page=390 Subtype=StrikeOut Author=Brian Day Comment= send an Address Frame Failed confirmation to the management application layer. This confirmation isn't used elsewhere in the spec. With potential for multiple IDENTIFY frames now, it's possible to reach the normal completion after this Address Frame Failed has already been sent. Suggest remove this confirmation, and just rely on either reaching Identification Sequence Complete or Identify Timeout. LSI comment number 360 Page=392 Subtype=Highlight Author=George Penokie Comment= This << not open, it shall not forward >> should be << not open, the expander device shall not forward >> LSI comment number 361 Page=392 Subtype=Highlight Author=George Penokie Comment= This << connection is open, it may forward the >> should be << connection is open, the expander device may forward the >> LSI comment number 362 Page=392 Subtype=Highlight Author=George Penokie Comment= This << phy operations (see 10.4.3.28) as well as when dword >> should be << phy operations (see 10.4.3.28) and when dword >> LSI comment number 363 Page=392 Subtype=Highlight Author=Brian Day Comment= SP0:OOB_COMINIT state s/b SP0:OOB_COMINIT or SP25:SATA_PortSel state LSI comment number 364 Page=392 Subtype=Highlight Author=Brian Day Comment= d) and e) Suggest simplifying language to just: d) after an expander phy's SP state machine sends a SATA Port Selector Change confirmation (see 6.8.3); LSI comment number 365 Page=393 Subtype=Highlight Author=George Penokie Comment=This << be 01h; >> should be << be 01h; and>> LSI comment number 366 Page=393 Subtype=Highlight Author=George Penokie Comment= This << the following reasons: >> should be << the following reason: >> LSI comment number 367 Page=393 Subtype=Highlight Author=George Penokie Comment= This << (NO DESTINATION), the expander >> should be << (NO DESTINATION), then the expander >> LSI comment number 368 Page=393 Subtype=Highlight Author=George Penokie Comment= This << process, but should not be sent by >> should be << process, but a Broadcast (Change) should not be sent by >> LSI comment number 369 Page=393 Subtype=Highlight Author=Brian Day Comment=This section should indicate logical phys. LSI comment number 370 Page=394 Subtype=Highlight Author=Brad Besmer Comment= physical s/b logical LSI comment number 371 Page=394 Subtype=Text Author=Brad Besmer Comment=This paragraph does not take multi-plexing into consideration. LSI comment number 372 Page=394 Subtype=Highlight Author=Brian Day Comment= physical s/b logical LSI comment number 373 Page=394 Subtype=Highlight Author=Brian Day Comment= physical s/b logical LSI comment number 374 Page=395 Subtype=Highlight Author=Brian Day Comment= In figure 179 This needs statement somewhere saying no multiplexxing in this example. LSI comment number 375 Page=396 Subtype=Highlight Author=George Penokie Comment= This << equal to 8000h; this limits the amount of unfairness and helps >> should be << equal to 8000h to limit the amount of unfairness and help>> LSI comment number 376 Page=397 Subtype=Highlight Author=George Penokie Comment= This note<< NOTE 61 - Connection >> should be modified be deleting the 1st sentence and change << receives one of the following connection responses >> to << receives one of the following connection responses from a destination phy (see ... ):>>. LSI comment number 377 Page=397 Subtype=Highlight Author=George Penokie Comment= This << it has forwarded a >> should be << the expander phy has forwarded a >> LSI comment number 378 Page=398 Subtype=Highlight Author=George Penokie Comment= This << The Arbitration Wait Time, Source SAS Address, and Connection Rate arguments are filled >> should be << The Arbitration Wait Time argument, Source SAS Address argument, and Connection Rate argument are filled >> LSI comment number 379 Page=398 Subtype=Highlight Author=George Penokie Comment= This << (Blocked On Partial) (see 7.12.4.2.2); >> should be << (Blocked On Partial) (see 7.12.4.2.2); and >> LSI comment number 380 Page=400 Subtype=Highlight Author=George Penokie Comment= This << a Phy Status (Partial Pathway), Phy Status (Blocked Partial Pathway), or Phy Status (Connection) response unless >> should be << a Phy Status (Partial Pathway) response, Phy Status (Blocked Partial Pathway) response, or Phy Status (Connection) response unless >> LSI comment number 381 Page=400 Subtype=Highlight Author=George Penokie Comment= This << and >> should be an << or >> as only one of the two conditions exist as any time. LSI comment number 382 Page=400 Subtype=Highlight Author=George Penokie Comment= This << and >> should be an << or >> as only one of the two conditions exist as any time. LSI comment number 383 Page=400 Subtype=Highlight Author=George Penokie Comment= This << and >> should be an << or >> as only one of the two conditions exist as any time. LSI comment number 384 Page=400 Subtype=Text Author=George Penokie Comment= All the << Arb Reject (...) >> should be << Arb Reject (...) confirmation >> LSI comment number 385 Page=401 Subtype=Highlight Author=George Penokie Comment= This note << NOTE 64 - The Partial Pathway >> should be made into normative text. LSI comment number 386 Page=402 Subtype=Highlight Author=George Penokie Comment= This << or if it chooses to abort its request >> should be << or if the source phy chooses to abort its request >> LSI comment number 387 Page=403 Subtype=StrikeOut Author=George Penokie Comment=Extraneous words that add nothing. LSI comment number 388 Page=405 Subtype=Highlight Author=Brian Day Comment= except for BREAKs and BREAK_REPLYs s/b except for BREAKs, BREAK_REPLYs, MUXs, and NOTIFYs. LSI comment number 389 Page=407 Subtype=Text Author=Brad Besmer Comment=Shouldn't these be logical link rates & logical links? LSI comment number 390 Page=411 Subtype=Highlight Author=George Penokie Comment=This << EOAF; then >> should be << EOAF; and >> LSI comment number 391 Page=411 Subtype=Highlight Author=George Penokie Comment= This << following messages to the SL >> should be << following message to the SL >> LSI comment number 392 Page=412 Subtype=Highlight Author=George Penokie Comment= It seems like this << or >> should be << and >> but that would be a different requirement in that the state would do both a and b rather that have to pick either a or b. I'm not sure which was intended. LSI comment number 393 Page=414 Subtype=Highlight Author=Brian Day Comment= transmitter. Suggest adding the following sentence: See 7.13 for details on rate matching when opening a connection. LSI comment number 394 Page=416 Subtype=Highlight Author=Brian Day Comment= Transition SL_CC1:ArbSel to SL_CC6:Break This transition also needs to include a Power Loss Expected argument to the SL_CC6:Break state. Use same wording as the transition to the SL_CC5 state above. This is to handle case where it receives BREAK, then immediately followed by the NOTIFY, while this state is still sending the OPEN address frame. LSI comment number 395 Page=420 Subtype=Highlight Author=Brian Day Comment= If this state receives a NOTIFY Received (Power Loss Expected) message Dependent on earlier comment. Change beginning of sentence to: If this state is entered with a Power Loss Expected arguement, or if this state receives... LSI comment number 396 Page=425 Subtype=Highlight Author=George Penokie Comment= This << following messages to the XL state machine >> should be << following message to the XL state machine >> LSI comment number 397 Page=426 Subtype=Highlight Author=George Penokie Comment= It seems like this << or >> should be << and >> but that would be a different requirement in that the state would do both a and b rather that have to pick either a or b. I'm not sure which was intended. LSI comment number 398 Page=427 Subtype=Highlight Author=George Penokie Comment= This << Arbitrating (Waiting On Partial) or Arbitrating (Blocked On Partial) confirmation is received >> should be << Arbitrating (Waiting On Partial) confirmation or Arbitrating (Blocked On Partial) confirmation is received >> LSI comment number 399 Page=427 Subtype=Highlight Author=George Penokie Comment= This << send Transmit AIP (Waiting On Partial) and Transmit Idle Dword messages to >> should be << send Transmit AIP (Waiting On Partial) message and Transmit Idle Dword message to >> LSI comment number 400 Page=427 Subtype=Highlight Author=George Penokie Comment= This << send Transmit AIP (Waiting On Connection) and Transmit Idle Dword messages >> should be << send Transmit AIP (Waiting On Connection) message and Transmit Idle Dword message >> LSI comment number 401 Page=429 Subtype=Text Author=George Penokie Comment= All the << Transmit AIP (...) >> should be << Transmit AIP (...) message >> LSI comment number 402 Page=429 Subtype=Highlight Author=Brian Day Comment= BREAK s/b BREAK, MUX, or NOTIFY or deletable primitive? LSI comment number 403 Page=430 Subtype=Highlight Author=George Penokie Comment= It seems like this << or >> should be << and >> but that would be a different requirement in that the state would do both a and b rather that have to pick either a or b. I'm not sure which was intended. LSI comment number 404 Page=430 Subtype=Highlight Author=George Penokie Comment= It seems like this << or >> should be << and >> but that would be a different requirement in that the state would do both a and b rather that have to pick either a or b. I'm not sure which was intended. LSI comment number 405 Page=431 Subtype=StrikeOut Author=George Penokie Comment=Extra item LSI comment number 406 Page=433 Subtype=Highlight Author=George Penokie Comment= This << circuit >> should be << logical link >> as circuit is not defined and logical link is. LSI comment number 407 Page=433 Subtype=Highlight Author=George Penokie Comment= It seems like this << or >> should be << and >> but that would be a different requirement in that the state would do both a and b rather that have to pick either a or b. I'm not sure which was intended. LSI comment number 408 Page=433 Subtype=Highlight Author=Brian Day Comment= BREAK s/b BREAK, MUX, NOTIFY, or deletable primitive? LSI comment number 409 Page=434 Subtype=Highlight Author=George Penokie Comment= It seems like this << or >> should be << and >> but that would be a different requirement in that the state would do both a and b rather that have to pick either a or b. I'm not sure which was intended. LSI comment number 410 Page=434 Subtype=StrikeOut Author=George Penokie Comment= The term << path >> is not defined and could be deleted without loosing anything. LSI comment number 411 Page=434 Subtype=Highlight Author=George Penokie Comment= It seems like this << or >> should be << and >> but that would be a different requirement in that the state would do both a and b rather that have to pick either a or b. I'm not sure which was intended. LSI comment number 412 Page=434 Subtype=Highlight Author=Brian Day Comment= BREAK s/b BREAK, MUX, NOTIFY, or deletable primitive? LSI comment number 413 Page=435 Subtype=Highlight Author=George Penokie Comment= It seems like this << or >> should be << and >> but that would be a different requirement in that the state would do both a and b rather that have to pick either a or b. I'm not sure which was intended. LSI comment number 414 Page=436 Subtype=Highlight Author=George Penokie Comment= This << including because the SAS port containing >> should be << including the case were the SAS port containing >> LSI comment number 415 Page=436 Subtype=Highlight Author=George Penokie Comment= This << following primitives: CREDIT_BLOCKED, RRDY, ACK, or NAK. >> should be made into an a,b,c list. LSI comment number 416 Page=436 Subtype=Highlight Author=Brian Day Comment= not too short suggest: a valid length LSI comment number 417 Page=437 Subtype=Highlight Author=George Penokie Comment= This note << NOTE 73 - It is not required >> should be normative text. LSI comment number 418 Page=437 Subtype=Highlight Author=George Penokie Comment= This << reason, including because it needs to transmit >> should be << reason, including the case were it needs to transmit >> LSI comment number 419 Page=437 Subtype=Highlight Author=George Penokie Comment= This << interlocked frame; >> should be << interlocked frame, >>. The semicolon should be a comma. LSI comment number 420 Page=438 Subtype=Highlight Author=George Penokie Comment= This << interlocked frame; >> should be << interlocked frame, >>. The semicolon should be a comma. LSI comment number 421 Page=438 Subtype=Highlight Author=George Penokie Comment= This << interlocked frame it transmitted to >> should be << interlocked frame the SSP phy transmitted to >> LSI comment number 422 Page=439 Subtype=Text Author=George Penokie Comment= Global This standard uses the convention that a.b.c lists should not have the first word capitalized unless it would capitalized to other reasons. This list does not comply to that convention and should be fixed. LSI comment number 423 Page=439 Subtype=Highlight Author=George Penokie Comment= This << completion; the transmitter has no more SSP frames to transmit >> should be << completion (i.e., the transmitter has no more SSP frames to transmit) >> LSI comment number 424 Page=439 Subtype=Highlight Author=George Penokie Comment= This << There are several versions of the DONE primitive indicating >> should be << The follow is a list of versions of the DONE primitive that indicate >> LSI comment number 425 Page=446 Subtype=Highlight Author=George Penokie Comment= This << connection within 1 ms; other DONE Received >> should be << connection within 1 ms. Other DONE Received >> LSI comment number 426 Page=449 Subtype=Highlight Author=George Penokie Comment= It seems like this << or >> should be << and >> but that would be a different requirement in that the state would do both a and b rather that have to pick either a or b. I'm not sure which was intended. LSI comment number 427 Page=452 Subtype=Highlight Author=George Penokie Comment= This << and >> should be an << or >> as you can only have one connection rate at a time. LSI comment number 428 Page=452 Subtype=Highlight Author=George Penokie Comment= This << connection rate. >> should be << connection rate, >> That's a comma instead of a period. LSI comment number 429 Page=452 Subtype=Highlight Author=George Penokie Comment= This << it does not place any data >> should be << The STP phy does not place any data >> LSI comment number 430 Page=452 Subtype=Highlight Author=George Penokie Comment= This << dwords, it shall stop transmitting >> should be << dwords, the STAT phy shall stop transmitting >> LSI comment number 431 Page=452 Subtype=Highlight Author=George Penokie Comment=This << it >> should be << the STP phy >>. LSI comment number 432 Page=452 Subtype=Highlight Author=George Penokie Comment=This << it >> should be << the STP phy >>. LSI comment number 433 Page=452 Subtype=Highlight Author=George Penokie Comment=This << It >> should be << The STP phy >>. LSI comment number 434 Page=452 Subtype=Highlight Author=George Penokie Comment=This << it >> should be << the STP phy >>. LSI comment number 435 Page=454 Subtype=Highlight Author=Brad Besmer Comment= physical s/b logical LSI comment number 436 Page=454 Subtype=Highlight Author=Brad Besmer Comment= physical s/b logical LSI comment number 437 Page=455 Subtype=Highlight Author=George Penokie Comment= I can't figure out what this << it >> is referring to, this needs to be fixed. LSI comment number 438 Page=455 Subtype=Highlight Author=George Penokie Comment= I can't figure out what this << it >> is referring to, this needs to be fixed. LSI comment number 439 Page=455 Subtype=Highlight Author=George Penokie Comment= I can't figure out what this << its >> is referring to, this needs to be fixed. LSI comment number 440 Page=455 Subtype=Highlight Author=George Penokie Comment=This << it >> should be << thie STP initiator phy >> LSI comment number 441 Page=456 Subtype=Highlight Author=George Penokie Comment= This << which it maintains an ATA >> should I think be << which the STP target port maintains an ATA >> LSI comment number 442 Page=456 Subtype=Highlight Author=George Penokie Comment= This << connections. It may use affiliations to limit >> should I think be << connections. The STP target port may use affiliations to limit >> LSI comment number 443 Page=456 Subtype=Highlight Author=George Penokie Comment= Not sure what this << where it refuses >> is referring to. This needs to be fixed. LSI comment number 444 Page=456 Subtype=Highlight Author=George Penokie Comment= This << STP target ports implement one of the affiliation >> should be << STP target ports shall implement one of the affiliation >> LSI comment number 445 Page=456 Subtype=Highlight Author=Brad Besmer Comment= multiple affiliations s/b no or multiple affiliations LSI comment number 446 Page=456 Subtype=Text Author=Brad Besmer Comment= need another rule: ensure that a non-queued command received in one affiliation context is not issued to the SATA device while another affiliation context has a non-queued command outstanding to the drive (e.g., the STP target port shall allow the non-queued command in the SATA device to complete prior to issuing the non-queued command); LSI comment number 447 Page=457 Subtype=Highlight Author=George Penokie Comment= This << in a SAS device; >> should be << in a SAS device, >> That's a comma rather than a semicolon. LSI comment number 448 Page=457 Subtype=Highlight Author=George Penokie Comment= This << STP initiator ports may keep affiliations for longer tenures, but this is discouraged. >> should be << STP initiator ports should not keep affiliations for longer tenures. >> or << STP initiator ports may keep affiliations for longer tenures. >> LSI comment number 449 Page=458 Subtype=Highlight Author=George Penokie Comment= I do not think putting a shall in a example is a good idea. This << device server shall report the affiliation contexts as described >> should be << device server reports the affiliation contexts as described >> LSI comment number 450 Page=458 Subtype=Highlight Author=George Penokie Comment= This note << NOTE 80 - If there is a problem >> should be normative text. LSI comment number 451 Page=458 Subtype=Highlight Author=George Penokie Comment=This << it >> should be << the STP/SATA bridge >> LSI comment number 452 Page=458 Subtype=Highlight Author=George Penokie Comment=This << it >> should be << the STP/SATA bridge >> LSI comment number 453 Page=458 Subtype=Highlight Author=George Penokie Comment=This << it >> should be << the STP/SATA bridge >> LSI comment number 454 Page=458 Subtype=Highlight Author=George Penokie Comment= This << (RETRY) because the SAS port containing that SAS phy needs an outgoing >> should be << (RETRY) as a result of the SAS port containing that SAS phy needing an outgoing >> LSI comment number 455 Page=458 Subtype=Highlight Author=George Penokie Comment=This << it >> should I think be << the STP initiator port >> LSI comment number 456 Page=458 Subtype=Highlight Author=George Penokie Comment=This << it >> should I think be << the STP initiator port >> LSI comment number 457 Page=458 Subtype=Highlight Author=George Penokie Comment=This << it >> should I think be << the STP target port >> LSI comment number 458 Page=459 Subtype=Highlight Author=George Penokie Comment= This << including because the SAS port containing that SAS phy needs an outgoing connection request >> should be << including as a result of the SAS port containing that SAS phy needing an outgoing connection request >> LSI comment number 459 Page=459 Subtype=Highlight Author=George Penokie Comment=This << than 1 connection >> should be << than one connection >> LSI comment number 460 Page=459 Subtype=Highlight Author=George Penokie Comment=This << than 2 connections >> should be << than two connections >> LSI comment number 461 Page=459 Subtype=Highlight Author=George Penokie Comment=This << than 1 connection >> should be << than one connection >> LSI comment number 462 Page=459 Subtype=Highlight Author=George Penokie Comment=This << than 1 connection >> should be << than one connection >> LSI comment number 463 Page=459 Subtype=Highlight Author=George Penokie Comment=This << than 2 connections >> should be << than two connections >> LSI comment number 464 Page=459 Subtype=Highlight Author=George Penokie Comment= This << than 3 connections >> should be << than three connections >> LSI comment number 465 Page=459 Subtype=Highlight Author=George Penokie Comment=This << than 5 connections >> should be << than five connections >> LSI comment number 466 Page=459 Subtype=Highlight Author=George Penokie Comment=This << than 4 connections >> should be << than four connections >> LSI comment number 467 Page=459 Subtype=Highlight Author=George Penokie Comment=This << together mean >> should be << together specify >> LSI comment number 468 Page=459 Subtype=Highlight Author=George Penokie Comment=This << 2 connections >> should be << two connections >> LSI comment number 469 Page=459 Subtype=Highlight Author=Brian Day Comment= In figure 200, Need comment that multiplexing not enabled in this example. LSI comment number 470 Page=460 Subtype=Highlight Author=George Penokie Comment=This << together mean >> should be << together specify >> LSI comment number 471 Page=460 Subtype=Highlight Author=George Penokie Comment=This << together mean >> should be << together specify >> LSI comment number 472 Page=460 Subtype=Highlight Author=George Penokie Comment=This << 2 connections >> should be << two connections >> LSI comment number 473 Page=460 Subtype=Highlight Author=George Penokie Comment=This << 4 connections >> should be << four connections >> LSI comment number 474 Page=460 Subtype=Highlight Author=George Penokie Comment=This << 1 connection >> should be << one connection >> LSI comment number 475 Page=460 Subtype=Highlight Author=George Penokie Comment=This << 1 connection >> should be << one connection >> LSI comment number 476 Page=463 Subtype=Highlight Author=George Penokie Comment= This note << NOTE 81 - Unlike SSP, there >> should be normative text. LSI comment number 477 Page=463 Subtype=Highlight Author=George Penokie Comment= This << including because the SAS port containing that SAS phy needs an >> should be << including as a resutle of the SAS port containing that SAS phy needing an >> LSI comment number 478 Page=464 Subtype=Highlight Author=George Penokie Comment= This << the following messages to the SMP >> should be << the following message to the SMP >> LSI comment number 479 Page=466 Subtype=Highlight Author=George Penokie Comment= It seems like this << or >> should be << and >> but that would be a different requirement in that the state would do both a and b rather that have to pick either a or b. I'm not sure which was intended. LSI comment number 480 Page=468 Subtype=Highlight Author=George Penokie Comment= It seems like this << or >> should be << and >> but that would be a different requirement in that the state would do both a and b rather that have to pick either a or b. I'm not sure which was intended. LSI comment number 481 Page=474 Subtype=Highlight Author=George Penokie Comment= This << SAS address, this state shall >> should be << SAS address, then this state shall >> LSI comment number 482 Page=474 Subtype=Highlight Author=George Penokie Comment= This << initiator port, the port shall >> should be << initiator port, then the port shall >> LSI comment number 483 Page=474 Subtype=Highlight Author=George Penokie Comment= This << In a vendor-specific manner, this state selects PL_PM state machines on which connections are established to transmit frames. >> should be << This state selects PL_PM state machines on which connections are established to transmit frames in a vendor-specific manner. >> LSI comment number 484 Page=476 Subtype=Highlight Author=George Penokie Comment=This note << NOTE 82 - If a co >> should be normative text. LSI comment number 485 Page=477 Subtype=Highlight Author=George Penokie Comment= This << page (see 10.2.7.4), a Retry >> should be << page (see 10.2.7.4), then a Retry >> so as not to confuse this with the then on the next line. LSI comment number 486 Page=477 Subtype=Highlight Author=George Penokie Comment= This << count received with the argument is FFh. >> should be << count received with the argument is FFh in which case the pathway blocked count shall not be changed. >> LSI comment number 487 Page=477 Subtype=Highlight Author=George Penokie Comment= This << page (see 10.2.7.4), a Retry Open (Retry) message >> should be << page (see 10.2.7.4), then a Retry Open (Retry) message >> so as not to confuse this with the then on the next line. LSI comment number 488 Page=477 Subtype=Highlight Author=Brian Day Comment= If a pending... This whole section adds the Reject To Open Limit timer after the Retry Open has been converted to a pending Tx Open. Since you can't have more Tx Opens than PL_PM state machines, this means you can't do new connections to other devices while this pending Tx Open is timing out. Change to be suggested in seperate proposal. LSI comment number 489 Page=478 Subtype=Highlight Author=George Penokie Comment= This << stop the I_T Nexus Loss timer for the SAS address, if the timer has been running >> should be << if the I_T Nexus Loss timer has been running, then stop the I_T Nexus Loss timer for the SAS address, >> LSI comment number 490 Page=480 Subtype=Highlight Author=George Penokie Comment= This << because it has an outgoing connection request on >> should be << as a result of the port having an outgoing connection request on >> LSI comment number 491 Page=480 Subtype=Highlight Author=George Penokie Comment=This note << NOTE 83 - The PL_PM >> should be normative text. LSI comment number 492 Page=481 Subtype=Highlight Author=Brian Day Comment= ...the same I_T_L_Q nexus... suggest ...the same I_T_L_Q nexus for a bidirectional command... LSI comment number 493 Page=488 Subtype=Highlight Author=George Penokie Comment= This << and >> should be << or >> as only one of the list can occur at a time. LSI comment number 494 Page=488 Subtype=Highlight Author=George Penokie Comment= This << and >> should be << or >> as only one of the list can occur at a time. LSI comment number 495 Page=490 Subtype=Highlight Author=George Penokie Comment= This << SMP connection, this state >> should be << SMP connection, then this state >> LSI comment number 496 Page=490 Subtype=Highlight Author=George Penokie Comment= This << connection, this state shall >> should be << connection, then this state shall >> LSI comment number 497 Page=494 Subtype=Highlight Author=George Penokie Comment=This note << NOTE 85 - The TLR >> should be normative text. LSI comment number 498 Page=494 Subtype=Highlight Author=George Penokie Comment= This << and >> should be << or >> as it is one or the other not both. LSI comment number 499 Page=495 Subtype=Highlight Author=George Penokie Comment= This << and >> should be << or >> as it is one or the other not both. LSI comment number 500 Page=495 Subtype=Highlight Author=George Penokie Comment= This << initiator port does not reuse a tag until it >> should be << initiator port shall not reuse a tag until it >> LSI comment number 501 Page=497 Subtype=Highlight Author=George Penokie Comment= Global Change << TASK PRIORITY >> to << command priority >> LSI comment number 502 Page=501 Subtype=Highlight Author=George Penokie Comment= This << transport-layer retries >> should be << transport layer retries >> to be consistent with the other 99.9% time this term is used. LSI comment number 503 Page=502 Subtype=Highlight Author=George Penokie Comment= This << transport-layer retries >> should be << transport layer retries >> to be consistent with the other 99.9% time this term is used. LSI comment number 504 Page=508 Subtype=StrikeOut Author=George Penokie Comment=This is on the wrong item LSI comment number 505 Page=508 Subtype=Highlight Author=George Penokie Comment= This << same tag (see 10.2.2); >> should be << same tag (see 10.2.2); and >> LSI comment number 506 Page=510 Subtype=Highlight Author=George Penokie Comment= This << write DATA frames, the ST_IFR state >> should be << write DATA frames, then the ST_IFR state >> LSI comment number 507 Page=511 Subtype=Text Author=George Penokie Comment= Put << then >> in all the if statement in 9.2.5.2. SSP initiator port transport layer error handling summary and 9.2.5.3 SSP target port transport layer error handling summary LSI comment number 508 Page=518 Subtype=Highlight Author=Brian Day Comment= has received suggest has previously received LSI comment number 509 Page=518 Subtype=Highlight Author=Brian Day Comment= has not received suggest has not previously received LSI comment number 510 Page=522 Subtype=Highlight Author=George Penokie Comment=This note << NOTE 89 - If the number of d >> should be normative. LSI comment number 511 Page=526 Subtype=Highlight Author=George Penokie Comment=This << or >> should be a << and >>. LSI comment number 512 Page=527 Subtype=Highlight Author=George Penokie Comment=This << or >> should be a << and >>. LSI comment number 513 Page=528 Subtype=Highlight Author=George Penokie Comment=This << or >> should be a << and >>. LSI comment number 514 Page=538 Subtype=Text Author=George Penokie Comment= Global The descriptions in the tables are all over the place when it comes to if the is a period or not after the description. I suggest if the description is a complete sentence then it should have a period at the end. There are many cases where that is not the case and many cases where it is. This, at lease, should be consistent. LSI comment number 515 Page=542 Subtype=Highlight Author=George Penokie Comment=Change << RESPONSE frame >> to << RESPONSE frame. >>. Period added. LSI comment number 516 Page=545 Subtype=StrikeOut Author=George Penokie Comment=Delete extra << and >> LSI comment number 517 Page=545 Subtype=Highlight Author=George Penokie Comment=This << or >> should be a << and >>. LSI comment number 518 Page=546 Subtype=Highlight Author=George Penokie Comment=This << or >> should be a << and >>. LSI comment number 519 Page=549 Subtype=Highlight Author=George Penokie Comment=This << or >> should be a << and >>. LSI comment number 520 Page=549 Subtype=Highlight Author=George Penokie Comment= This << link reset sequence (see G.5 for exceptions to this). >> should be << link reset sequence except as defined in G.5. >> LSI comment number 521 Page=550 Subtype=StrikeOut Author=Brian Day Comment=in an expander device LSI comment number 522 Page=550 Subtype=StrikeOut Author=Brian Day Comment=Other SMP target ports may support these frames. LSI comment number 523 Page=550 Subtype=Highlight Author=Brian Day Comment= The SMP target port suggest SMP ports These frames are required by all SMP ports, regardless of initiator / target, and regardless of expander / end device. LSI comment number 524 Page=551 Subtype=Highlight Author=Brad Besmer Comment=Not possible to describe. See comment in 10.4.3.2.5. LSI comment number 525 Page=551 Subtype=Highlight Author=Brad Besmer Comment=Not possible to describe. See comment in 10.4.3.2.4. LSI comment number 526 Page=551 Subtype=StrikeOut Author=Brian Day Comment=ADDITIONAL LSI comment number 527 Page=551 Subtype=StrikeOut Author=Brian Day Comment=ADDITIONAL LSI comment number 528 Page=552 Subtype=Highlight Author=Brian Day Comment= source phy suggest SMP initiator port LSI comment number 529 Page=552 Subtype=Highlight Author=Brian Day Comment= destination phy suggest SMP target port LSI comment number 530 Page=555 Subtype=Highlight Author=Brian Day Comment= 1 900 us I don't think there is reason anymore to not just change this to 2ms, since it's not enforced on the SMP Initiator side. LSI comment number 531 Page=556 Subtype=Highlight Author=George Penokie Comment= This << the following arguments >> should be << the following argument >> LSI comment number 532 Page=559 Subtype=Highlight Author=George Penokie Comment= Global Change << task priority >> to << command priority >> LSI comment number 533 Page=562 Subtype=StrikeOut Author=George Penokie Comment=There is no need to this extra << or >> LSI comment number 534 Page=562 Subtype=StrikeOut Author=George Penokie Comment=There is no need to this extra << or >> LSI comment number 535 Page=568 Subtype=Highlight Author=George Penokie Comment= This statement << or a NAK was received for the TASK frame, or the length of the RESPONSE frame is incorrect. >> should be before the list and stated as << Indicates the response to the TASK frame, a NAK was received for the TASK frame, or the length of the RESPONSE frame is incorrect:. >> LSI comment number 536 Page=569 Subtype=Highlight Author=George Penokie Comment= This << Timeout, the application client >> should be << Timeout, then the application client LSI comment number 537 Page=569 Subtype=Highlight Author=George Penokie Comment= This << SUCCEEDED, the application >> should be << SUCCEEDED, then the application >> LSI comment number 538 Page=569 Subtype=Highlight Author=George Penokie Comment= This << processed), the application >> should be << processed), then the application >> LSI comment number 539 Page=569 Subtype=Highlight Author=George Penokie Comment= This << in any logical unit, the task >> should be << in any logical unit, then the task >> LSI comment number 540 Page=569 Subtype=Highlight Author=George Penokie Comment= This << in table 211, the device >> should be << in table 211, then the device >> LSI comment number 541 Page=570 Subtype=Highlight Author=George Penokie Comment= This << The vital product data returned by the INQUIRY command (see SPC-4) that shall be returned by a logical unit in a SAS device is described in 10.2.11. >> should be << The vital product data that shall be returned as a result of an INQUIRY command (see SPC-4) to a logical unit in a SAS device is described in 10.2.11. >> LSI comment number 542 Page=571 Subtype=Highlight Author=George Penokie Comment= This << not implemented, the value assumed for the functionality of the field shall be zero (i.e., as if the field is set to zero) >> should be << not implemented, the value of the field shall be assumed to be zero (i.e., as if the field is set to zero) >> LSI comment number 543 Page=571 Subtype=Highlight Author=George Penokie Comment= This << not implemented, the value assumed for the functionality of each field in that mode page that is: >> should be << not implemented, the value for each field in that mode page shall be assumed to be: >> LSI comment number 544 Page=571 Subtype=StrikeOut Author=George Penokie Comment=This << is >> seems to be an extra word. LSI comment number 545 Page=572 Subtype=Highlight Author=George Penokie Comment= This << shall only use the parameter fields defined below in this subclause. If a >> should be << shall only the parameter fields defined in table 214. If a >> LSI comment number 546 Page=572 Subtype=Highlight Author=George Penokie Comment= This << non-zero value, the device >> should be << non-zero value, then the device >> LSI comment number 547 Page=577 Subtype=Highlight Author=George Penokie Comment= This << (i.e., 4 + (the value of the NUMBER OF PHYS field) x (the length in bytes of the SAS phy mode descriptor)). >> needs another set of () so it is clear whether the + operation or the x operation is done first. LSI comment number 548 Page=579 Subtype=Highlight Author=George Penokie Comment= This << SCSI target device, it shall be implemented >> should be << SCSI target device, then it shall be implemented >> LSI comment number 549 Page=579 Subtype=StrikeOut Author=George Penokie Comment= This << that were first defined in SAS-2 >> is not a relevant statement and should be deleted. If you insist that it be in the standard it would have to be a note. LSI comment number 550 Page=586 Subtype=StrikeOut Author=George Penokie Comment=This tern << each >> adds nothing and should be deleted. LSI comment number 551 Page=589 Subtype=Highlight Author=George Penokie Comment= This << a SAS phy, then it only supports no SSC and >> should be << a SAS phy, only supports no SSC, and>> LSI comment number 552 Page=591 Subtype=Highlight Author=George Penokie Comment= This << Kxx.y)(see 6.3.3); each other byte shall be sent >> should be << Kxx.y)(see 6.3.3) and all other bytes shall be sent >> LSI comment number 553 Page=591 Subtype=Highlight Author=George Penokie Comment= This << character; each other byte shall be >> should be << character and all other bytes shall be >> LSI comment number 554 Page=591 Subtype=Highlight Author=George Penokie Comment= This << character; each other byte shall be >> should be << character and all other bytes shall be >> LSI comment number 555 Page=602 Subtype=Highlight Author=George Penokie Comment= This << features are defined. >> should be << features are defined by this standard. >> LSI comment number 556 Page=604 Subtype=Text Author=Brad Besmer Comment= We should consider adding the size of the all descriptors to the "header" of each SMP response that contains descriptors (similar to REPORT SELF-CONFIGURATION STATUS), if they do not already have such a field. LSI comment number 557 Page=606 Subtype=Text Author=Brad Besmer Comment= A non-zero value in ALLOCATED RESPONSE LENGTH limits additional response frame to be 1020 bytes. Including the SMP header, this leads to the entire SMP Frame Length maximum to be 1024 (not including CRC): (255 * 4) + 4 bytes header = 1024. LSI comment number 558 Page=607 Subtype=Highlight Author=George Penokie Comment= This << a non-zero number of dwords follow the REQUEST LENGTH field before the CRC field. This is for compatibility with previous versions of this standard >> should be << for compatibility with previous versions of this standard, a non-zero number of dwords follow the REQUEST LENGTH field before the CRC field. >> LSI comment number 559 Page=607 Subtype=Highlight Author=George Penokie Comment= How can this be 1024? The math does not seem to work. The largest value for the length field is FFh (255). 255 x 4 = 1020. So how can you get to 1024? LSI comment number 560 Page=607 Subtype=Text Author=Brad Besmer Comment= A REQUEST LENGTH maximum value of 255, leads to maximum additional request bytes value of (255 * 4) = 1020. Section 9.4.2 says: The REQUEST BYTES field definition and length is based on the SMP function (see 10.4.3.2). The maximum size of the REQUEST BYTES field is 1 024 bytes, making the maximum size of the frame 1 032 bytes (i.e., 1 024 bytes of data + 4 bytes of header + 4 bytes of CRC). 1020 <> 1024 Potential solutions: 1) Reduce maximum additional_request_length to 1020 (currently 1024) 2) additional_request_length = (REQUEST_LENGTH+1) * 4...this would be problem for a 4-byte request however. LSI comment number 561 Page=607 Subtype=Highlight Author=Brad Besmer Comment=Not possible to describe. See comment in 10.4.3.2.5 LSI comment number 562 Page=607 Subtype=Highlight Author=Brad Besmer Comment= allocated response length small caps? LSI comment number 563 Page=609 Subtype=Highlight Author=George Penokie Comment=This << function, but the >> should be << function, however the >> LSI comment number 564 Page=610 Subtype=Highlight Author=George Penokie Comment= This<< (e.g., because of zoning or >> should be << (e.g., as a result of zoning or for>> LSI comment number 565 Page=610 Subtype=Highlight Author=Brad Besmer Comment= NUMBER OF PHYS s/b (NUMBER OF PHYS - 1) LSI comment number 566 Page=616 Subtype=Highlight Author=George Penokie Comment= This << a non-zero number of dwords follow the RESPONSE LENGTH field before the CRC field. This is for compatibility with previous versions of this standard >> should be << for compatibility with previous versions of this standard, a non-zero number of dwords follow the RESPONSE LENGTH field before the CRC field.>> LSI comment number 567 Page=616 Subtype=Highlight Author=Brad Besmer Comment=Not possible to describe. See comment in 10.4.3.2.4. LSI comment number 568 Page=616 Subtype=Highlight Author=Brad Besmer Comment= eight s/b two units are in number of dwords, not number of bytes. LSI comment number 569 Page=617 Subtype=Text Author=Brad Besmer Comment= (global) this is recursive. perhaps add reference to ARL clause? b) return the response frame as specified by the ALLOCATED RESPONSE LENGTH field (see 10.4.3.2.4). LSI comment number 570 Page=620 Subtype=Highlight Author=George Penokie Comment=This note << NOTE 107 - If the CONFIGURES >> should be normative. LSI comment number 571 Page=620 Subtype=Highlight Author=Brad Besmer Comment= This seems to be the only place this rule is specified, namely that Table to Table is ONLY allowed on Self-configuring expanders. LSI comment number 572 Page=621 Subtype=Highlight Author=Brad Besmer Comment= number of zone groups small-caps LSI comment number 573 Page=622 Subtype=Highlight Author=Brad Besmer Comment= Need to clarify the usage of connector element index. Current usage assumes that CEI is the same value for all phys w/in a connector. LSI comment number 574 Page=626 Subtype=Highlight Author=Brian Day Comment= the original version suggest previous versions LSI comment number 575 Page=627 Subtype=Text Author=Brad Besmer Comment= The response for this request indicates that a value of zero has special meaning that is not described here. LSI comment number 576 Page=629 Subtype=Highlight Author=George Penokie Comment= Global (there are 16 other instances of this same statement that should also be changed) This << A RESPONSE LENGTH field set to 00h does not have a special meaning based on the ALLOCATED RESPONSE LENGTH field in the request frame. >> should be made into a note as the information is not normative. LSI comment number 577 Page=629 Subtype=Highlight Author=George Penokie Comment= This << start again because the status information >> should be << start again as the status information >> LSI comment number 578 Page=629 Subtype=Highlight Author=George Penokie Comment= This << field to the next index, in ascending order wrapping from FFFFh to 0001h, that contains a valid descriptor. >> should be << field to the next index that contains a valid descriptor in ascending order wrapping from FFFFh to 0001h. >> LSI comment number 579 Page=629 Subtype=Highlight Author=George Penokie Comment= This << field in ascending order, wrapping from FFFFh to 0001h, based on the self-configuration status descriptor index. >> should be << field in ascending order based on the self-configuration status descriptor index wrapping from FFFFh to 0001h. > LSI comment number 580 Page=629 Subtype=Highlight Author=George Penokie Comment= This << If the STARTING SELF-CONFIGURATION STATUS DESCRIPTOR INDEX field in the SMP request is set to 0000h, then the management device server shall set the STARTING SELF-CONFIGURATION STATUS DESCRIPTOR INDEX field to 0000h, set the TOTAL NUMBER OF SELF-CONFIGURATION STATUS DESCRIPTORS field to 0000h, and return no descriptors. >> would be easier to understand if it was made into an a,b,c list. LSI comment number 581 Page=629 Subtype=Highlight Author=Brad Besmer Comment= is s/b may be LSI comment number 582 Page=629 Subtype=Text Author=Brad Besmer Comment= Should this indicate that this value shall be 4 for expanders compliant w/this standard? LSI comment number 583 Page=631 Subtype=Highlight Author=George Penokie Comment= This << discover process because of the error indicated >> should be << discover process as a result of the error indicated >> LSI comment number 584 Page=634 Subtype=Highlight Author=George Penokie Comment= This << and is set to the same value as the >> looks like a requirement that should be stated as << and shall be set to the same value as the >> LSI comment number 585 Page=638 Subtype=Highlight Author=George Penokie Comment=This is not the correct table reference. It should be table 266. LSI comment number 586 Page=638 Subtype=Highlight Author=George Penokie Comment=This is not the correct table reference. It should be table 266. LSI comment number 587 Page=639 Subtype=Highlight Author=George Penokie Comment= This << it shall increment this field >> should be << the SAS device or expander device shall increment this field >> LSI comment number 588 Page=639 Subtype=Highlight Author=George Penokie Comment= This << It shall not increment >> should be << The SAS device or expander device shall not increment >> LSI comment number 589 Page=639 Subtype=Highlight Author=George Penokie Comment= This << This field shall >> should be << The BROADCAST COUNT field shall >> LSI comment number 590 Page=645 Subtype=StrikeOut Author=George Penokie Comment= This << after >> should be deleted as there is an <> in each item. No need to have << after .. after >>. LSI comment number 591 Page=646 Subtype=Highlight Author=Brian Day Comment= The phy is a physical phy and the attached phy is a SATA device phy. Since ATTACHED SATA DEVICE is set to one prior to actually getting a COMWAKE back from device, this row can be hit when no SATA device is present. LSI comment number 592 Page=647 Subtype=Highlight Author=George Penokie Comment= This << a) after the identification sequence completes, if a SAS phy or expander phy is attached; or b) after the COMSAS Detect Timeout timer expires (see 6.8.3.9), if a SATA phy is attached >> should be << a) if a SAS phy or expander phy is attached, then after the identification sequence completes; or b) if a SATA phy is attached, then after the COMSAS Detect Timeout timer expires (see 6.8.3.9). >> to make this a.b.c list consistent with the others. LSI comment number 593 Page=648 Subtype=Highlight Author=George Penokie Comment= This << a) after the identification sequence completes, if a SAS phy or expander phy is attached; or b) after the COMSAS Detect Timeout timer expires (see 6.8.3.9), if a SATA phy is attached. >> should be << a) if a SAS phy or expander phy is attached, then after the identification sequence completes; or b) if a SATA phy is attached, then after the COMSAS Detect Timeout timer expires (see 6.8.3.9). >> to make this a.b.c list consistent with the others. LSI comment number 594 Page=648 Subtype=Highlight Author=George Penokie Comment= This << sequence occurs (see 6.7) then the >> is missing a comma before the then. LSI comment number 595 Page=651 Subtype=Text Author=Brad Besmer Comment=Do we need to add what to report if nothing is attached? LSI comment number 596 Page=653 Subtype=Highlight Author=Brian Day Comment= detected a SATA device suggest: did not detect as SAS device LSI comment number 597 Page=665 Subtype=Highlight Author=George Penokie Comment= This << This function is intended to provide the necessary information in a single SMP response >> should be << This function provides the necessary information in a single SMP response >> LSI comment number 598 Page=667 Subtype=Highlight Author=George Penokie Comment= Should state here that this allows a maximum of 40 phys of information to be returned in with one function request. LSI comment number 599 Page=667 Subtype=Highlight Author=George Penokie Comment= Should state here that this allows a maximum of 9 phys of information to be returned in with one function request. LSI comment number 600 Page=667 Subtype=Text Author=Brad Besmer Comment=Need to clarify if this includes VACANT phys or not. LSI comment number 601 Page=667 Subtype=Highlight Author=Brad Besmer Comment=This example here is opposite of what this filters. LSI comment number 602 Page=669 Subtype=Text Author=George Penokie Comment= OK so what happens if the number of descriptors exceeds the maximum possible length of the response? LSI comment number 603 Page=673 Subtype=Text Author=George Penokie Comment= What happens if the number of phy events is too many to contain within the REPORT PHY EVENT LIST response? LSI comment number 604 Page=676 Subtype=Highlight Author=George Penokie Comment= This << request, it shall increment >> should be << request, the self-configuring expander device shall increment >> LSI comment number 605 Page=677 Subtype=Highlight Author=George Penokie Comment= This << (e.g., bit zero of byte 5 indicates the phy indicated by the starting phy identifier). >> does not compute. Byte 5 is in the middle of the ROUTED SAS ADDRESS field. LSI comment number 606 Page=679 Subtype=Highlight Author=George Penokie Comment= This << field that would be returned by >> should be << field that's returned by >> LSI comment number 607 Page=679 Subtype=Highlight Author=George Penokie Comment= This << time), the management >> should be << time), then the management >> LSI comment number 608 Page=679 Subtype=Highlight Author=George Penokie Comment= This << count, the management device >> should be << count, then the management device >> LSI comment number 609 Page=679 Subtype=Highlight Author=George Penokie Comment= This << is exceeded, the STP target >> should be << is exceeded, then the STP target >> LSI comment number 610 Page=686 Subtype=Highlight Author=George Penokie Comment= This << response(see 10.4.3.21). >> should be << response (see 10.4.3.21). >> there is a missing space. LSI comment number 611 Page=686 Subtype=Highlight Author=George Penokie Comment= This << This field specifies the number of 100 ms >> should be << The ZOND LOCK INACTIVITY TIME LIMIT field specifies the number of 100 ms >> LSI comment number 612 Page=695 Subtype=StrikeOut Author=George Penokie Comment=This << that follow >> is not needed. LSI comment number 613 Page=700 Subtype=StrikeOut Author=George Penokie Comment= Predicting the future in not a good idea so delete this note << NOTE 125 - Future versions of this standard may change the value defined in table 331. >> LSI comment number 614 Page=700 Subtype=Highlight Author=George Penokie Comment= This << one, the ECM shall not use >> should be << one, then the ECM shall not use >> LSI comment number 615 Page=702 Subtype=StrikeOut Author=George Penokie Comment= Predicting the future in not a good idea so delete this note << NOTE 126 - Future versions of this standard may change the value defined in table 335. >> LSI comment number 616 Page=702 Subtype=Highlight Author=George Penokie Comment= You should change the orphans on this table so that you don't get one row all be it's self on one page <> LSI comment number 617 Page=703 Subtype=Highlight Author=George Penokie Comment= This << expander phy, the link reset sequence >> should be << expander phy, then the link reset sequence >> LSI comment number 618 Page=703 Subtype=StrikeOut Author=Brian Day Comment= While the LINK RESET phy operation is in progress, the management device server sets the NEGOTIATED PHYSICAL LINK RATE field and the NEGOTIATED PHYSICAL LINK RATE field to RESET_IN_PROGRESS in the SMP DISCOVER response (see 10.4.3.10). This is only true for certain cases based on SP state machine ResetStatus variable. LSI comment number 619 Page=703 Subtype=StrikeOut Author=Brian Day Comment= While the HARD RESET phy operation is in progress, the management device server sets the NEGOTIATED PHYSICAL LINK RATE field and the NEGOTIATED PHYSICAL LINK RATE field to RESET_IN_PROGRESS in the SMP DISCOVER response (see 10.4.3.10). LSI comment number 620 Page=704 Subtype=StrikeOut Author=George Penokie Comment=This term << such >> adds nothing and should be deleted. LSI comment number 621 Page=704 Subtype=Highlight Author=George Penokie Comment= This << selectors, the phy shall transmit >> should be << selectors, then the phy shall transmit >> LSI comment number 622 Page=704 Subtype=Highlight Author=George Penokie Comment= This << is requested, the management >> should be << is requested, then the management >> LSI comment number 623 Page=705 Subtype=Highlight Author=George Penokie Comment= This << device is attached, it shall set the ATTACHED >> should be << device is attached, then the management application client shall set the ATTACHED >> LSI comment number 624 Page=705 Subtype=Highlight Author=George Penokie Comment= This << set to zero, set this field to the >> should be << set to zero, then set the ATTACHED DEVICE NAME field to the >> LSI comment number 625 Page=705 Subtype=Highlight Author=George Penokie Comment= This << set to zero, set this field to >> should be << set to zero, then set the ATTACHED DEVICE NAME field to >> LSI comment number 626 Page=705 Subtype=Highlight Author=George Penokie Comment= This << correct, set this field to >> should be << correct, then set the ATTACHED DEVICE NAME field to >> LSI comment number 627 Page=705 Subtype=Highlight Author=George Penokie Comment= This << HARD RESET, that phy operation >> should be << HARD RESET, then that phy operation >> LSI comment number 628 Page=705 Subtype=Highlight Author=George Penokie Comment= This << HARD RESET, that phy >> should be << HARD RESET, then that phy >> LSI comment number 629 Page=705 Subtype=Highlight Author=George Penokie Comment= This << the maximum), the management device >> should be << the maximum), then the management device >> LSI comment number 630 Page=705 Subtype=Highlight Author=George Penokie Comment= This << If it returns a function >> should be << If the management device server returns a function >> LSI comment number 631 Page=705 Subtype=Highlight Author=George Penokie Comment= This << FAILED, it shall not perform >> should be << FAILED, then the management device server shall not perform >> LSI comment number 632 Page=708 Subtype=StrikeOut Author=George Penokie Comment= Predicting the future in not a good idea so delete this note << NOTE 127 - Future versions of this standard may change the value defined in table 339. >> LSI comment number 633 Page=708 Subtype=Highlight Author=George Penokie Comment= This << connection, the management >> should be << connection, then the management >> LSI comment number 634 Page=708 Subtype=Highlight Author=George Penokie Comment= This << the phy, the management >> should be << the phy, then the management >> LSI comment number 635 Page=708 Subtype=Highlight Author=George Penokie Comment= This << test function, the selected phy >> should be << test function, then the selected phy >> LSI comment number 636 Page=708 Subtype=Highlight Author=George Penokie Comment= This << test function, the management >> should be << test function, then the management >> LSI comment number 637 Page=708 Subtype=Highlight Author=George Penokie Comment= This << TRANSMIT PATTERN), the PHY TEST PATTERN >> should be << TRANSMIT PATTERN), then the PHY TEST PATTERN >> LSI comment number 638 Page=710 Subtype=Circle Author=George Penokie Comment=This cell should have a << 19 >> in it. LSI comment number 639 Page=710 Subtype=Circle Author=George Penokie Comment=This cell should have a << n - 11 >> in it. LSI comment number 640 Page=710 Subtype=Text Author=Brad Besmer Comment=I don't see any method to clear Wrapping Counters. LSI comment number 641 Page=713 Subtype=Highlight Author=George Penokie Comment= Global in annex A tables This << sent 1 time >> should be << sent one time >> LSI comment number 642 Page=714 Subtype=Highlight Author=George Penokie Comment= This << of the pattern, the resulting 10b >> should be << of the pattern, then the resulting 10b >> LSI comment number 643 Page=715 Subtype=Highlight Author=George Penokie Comment= This << 6 data dwords containing >> should be << six data dwords containing >> LSI comment number 644 Page=715 Subtype=Highlight Author=George Penokie Comment= This << 1 data dword containing >> should be << one data dword containing >> LSI comment number 645 Page=715 Subtype=Highlight Author=George Penokie Comment= This << Because the SOF, EOF, and CRC are the same in SSP and SMP, CJTPAT >> should be << As a result of SOF, EOF, and CRC being the same in SSP and SMP, CJTPAT >> LSI comment number 646 Page=715 Subtype=Highlight Author=George Penokie Comment= This << It does not modify primitives >> should be << The phy does not modify primitives >> LSI comment number 647 Page=716 Subtype=Highlight Author=George Penokie Comment= This << scrambled again, the data in the >> should be << scrambled again, then the data in the >> LSI comment number 648 Page=721 Subtype=Highlight Author=George Penokie Comment= This << and >> should be << or >> as this is one or the other not both. LSI comment number 649 Page=721 Subtype=Highlight Author=George Penokie Comment= This << and >> should be << or >> as this is one or the other not both. LSI comment number 650 Page=722 Subtype=StrikeOut Author=George Penokie Comment=The << , etc. >> is redundant and should be deleted. LSI comment number 651 Page=722 Subtype=Highlight Author=George Penokie Comment= This << No standard mechanism is defined to configure a phy to expect to >> should be << This standard defines no mechanism for configuring a phy to expect to >> LSI comment number 652 Page=723 Subtype=Highlight Author=George Penokie Comment= This << such access would disturb the connector to the point that the measurement of the signal would be compromised >> should be << such access disturbs the connector to the point that the measurement of the signal is compromised >> LSI comment number 653 Page=724 Subtype=StrikeOut Author=George Penokie Comment= This << Examination of the details of the measurement methods described in this annex shows that the mated connector issue may not be as severe as it appears.>> is an editorial comment and should not be in a standard. LSI comment number 654 Page=724 Subtype=Highlight Author=George Penokie Comment= This << and >> should be << or >> as this list is one or the other but not all. LSI comment number 655 Page=725 Subtype=Highlight Author=George Penokie Comment= This << and >> should be << or >> as this list is one or the other but not all. LSI comment number 656 Page=725 Subtype=Highlight Author=George Penokie Comment= This << receiver sensitivity is problematic in common usage. This term is not used for interoperability in standards.>> should be << receiver sensitivity is not a well defined term and therefore is not used for interoperability in this standard. >> LSI comment number 657 Page=726 Subtype=StrikeOut Author=George Penokie Comment=Delete << also >> as it adds nothing. LSI comment number 658 Page=726 Subtype=Highlight Author=George Penokie Comment= This << It also forces the requirement for in >> should be << Interfacing with practical instruments also forces the requirement for in >> LSI comment number 659 Page=726 Subtype=Highlight Author=George Penokie Comment=What << specifications >> are being talked about here? LSI comment number 660 Page=726 Subtype=Highlight Author=George Penokie Comment=What << specifications >> are being talked about here? LSI comment number 661 Page=726 Subtype=Highlight Author=George Penokie Comment=What << specifications >> are being talked about here? LSI comment number 662 Page=727 Subtype=Highlight Author=George Penokie Comment=What << specifications >> are being talked about here? LSI comment number 663 Page=728 Subtype=Highlight Author=George Penokie Comment= In the statement << measured here >> it is not clear where << here >> is. This needs to be fixed. LSI comment number 664 Page=728 Subtype=Highlight Author=George Penokie Comment=This << this scheme is not >> should be << this method is not >> LSI comment number 665 Page=728 Subtype=StrikeOut Author=George Penokie Comment= This is an informative annex so the term << required >> is not allowed. LSI comment number 666 Page=729 Subtype=Highlight Author=George Penokie Comment= This << requirement but is included here >> should be << requirement but it is included here >> LSI comment number 667 Page=731 Subtype=Highlight Author=George Penokie Comment= This << are described in some detail. >> should be << are described in this subclause. >> LSI comment number 668 Page=733 Subtype=Highlight Author=George Penokie Comment= This << are all single-ended; the differential and common >> should be << are all single-ended. The differential and common >> LSI comment number 669 Page=734 Subtype=Highlight Author=George Penokie Comment= This << measurements partly because the connectors used on real physical link elements are different from those used on instrumentation>> should be << measurements as a result of the connectors used on real physical link elements being different from those used on instrumentation>> LSI comment number 670 Page=734 Subtype=Highlight Author=George Penokie Comment= This << device has to compensate for those >> should be << device should compensate for those >> LSI comment number 671 Page=735 Subtype=Highlight Author=George Penokie Comment= This << device has to compensate for those >> should be << device should compensate for those >> LSI comment number 672 Page=735 Subtype=Highlight Author=George Penokie Comment= This << connector, requires both the interconnect and the receiver device to be in place and the combination >> should be << connector, assumes both the interconnect and the receiver device are in place and that the combination>> LSI comment number 673 Page=735 Subtype=Highlight Author=George Penokie Comment= This << ideal load then S11 does >> should be << ideal load, then S11 does >> that's a missing comma. LSI comment number 674 Page=735 Subtype=Highlight Author=George Penokie Comment= This << very lossy then the effects >> should be << very lossy, then the effects >>. Missing comma. LSI comment number 675 Page=736 Subtype=Highlight Author=George Penokie Comment= This << that it requires both the interconnect >> should be << that it assumes both the interconnect >> LSI comment number 676 Page=736 Subtype=Highlight Author=George Penokie Comment= This << very lossy then the effects >> should be << very lossy, then the effects >> . Missing comma. LSI comment number 677 Page=737 Subtype=Highlight Author=George Penokie Comment= This << output is required for all S-parameters >> should be << output is used for all S-parameters >> LSI comment number 678 Page=737 Subtype=Highlight Author=George Penokie Comment= This << Complex, but tractable, methods are required to use single-ended instruments for differential and common-mode applications. Careful attention to test configuration details is required.>> should be << With complex, but tractable, methods it is possible to use single-ended instruments for differential and common-mode applications, however, careful attention to test configuration details is essential.>> LSI comment number 679 Page=737 Subtype=Highlight Author=George Penokie Comment= This << the system because some peaks and >> should be << the system as some peaks and >> LSI comment number 680 Page=737 Subtype=Highlight Author=George Penokie Comment= This << actually applied (which is measured independently) is the >> should be << actually applied, measured independently, is the >> LSI comment number 681 Page=737 Subtype=Highlight Author=George Penokie Comment= This is an informative annex and therefore is not allowed to contains requirements and the statement << and shall meet the requirement specified in 5.3.5.2. >> is a requirement. This has to be deleted or reworded to eliminate any notion that this is a requirement. LSI comment number 682 Page=738 Subtype=Highlight Author=George Penokie Comment= Make this <> into an a.b.c list. LSI comment number 683 Page=739 Subtype=Highlight Author=George Penokie Comment= This << simultaneously met, the peaking should >> should be << simultaneously met, then the peaking should >> LSI comment number 684 Page=739 Subtype=Highlight Author=George Penokie Comment= This << in the test system. This is important to insure the accuracy >> should be << in the test system to insure the accuracy >> LSI comment number 685 Page=739 Subtype=Text Author=George Penokie Comment= There are several << shall >> in this informative annex that have to be removed. There are also several boarder line statements that are very close to stating requirements that should be looked at to make sure no requirement is implied. LSI comment number 686 Page=739 Subtype=Highlight Author=George Penokie Comment=This << shall be >> should be << is set to >> LSI comment number 687 Page=739 Subtype=Highlight Author=George Penokie Comment=This << shall be >> should be << is set to >> LSI comment number 688 Page=739 Subtype=Highlight Author=George Penokie Comment=This << shall be >> should be << is set to >> LSI comment number 689 Page=739 Subtype=Highlight Author=George Penokie Comment=This << shall be measured >> should be << are measured >> LSI comment number 690 Page=739 Subtype=Highlight Author=George Penokie Comment=This << shall be measured >> should be << are measured >> LSI comment number 691 Page=739 Subtype=Highlight Author=George Penokie Comment= This << performance requirements: >> should be << performance settings: >> LSI comment number 692 Page=739 Subtype=Highlight Author=George Penokie Comment= This << Resource requirements: >> should be<< Calibration equipment: >> LSI comment number 693 Page=739 Subtype=Highlight Author=George Penokie Comment= This << the JMD (the reference clock is part of the JMD) is measured >> should be << the JMD (i.e., the reference clock is part of the JMD) is measured >> LSI comment number 694 Page=739 Subtype=Highlight Author=George Penokie Comment= This << SSC (full tracking); >> should be << SSC (i.e., full tracking); >> LSI comment number 695 Page=739 Subtype=Highlight Author=George Penokie Comment= This << jitter (no tracking) >> should be << jitter (i.e., no tracking) >> LSI comment number 696 Page=739 Subtype=Highlight Author=George Penokie Comment= This << separate means. This ensures the jitter >> should be << separate means to ensure the jitter >> LSI comment number 697 Page=739 Subtype=Highlight Author=George Penokie Comment= This << checks two conditions: the JTF attenuation and the JTF bandwidth. >> should be << checks the JTF attenuation condition and the JTF bandwidth condition. >> LSI comment number 698 Page=740 Subtype=Highlight Author=George Penokie Comment= Make this << for these two cases, DJ_MM = DJ_MON - DJ_MOFF. Calculate the -3dB value: DJ_3DB = DJ_MM x 0.707; >> into an a,b,c list. LSI comment number 699 Page=750 Subtype=Square Author=George Penokie Comment=These cells should all be centered. LSI comment number 700 Page=787 Subtype=Highlight Author=George Penokie Comment=This << distance of 8 >> should be << distance of eight >> LSI comment number 701 Page=787 Subtype=Highlight Author=George Penokie Comment=This << of at least 8. >> should be << of at least eight. >> LSI comment number 702 Page=789 Subtype=Highlight Author=George Penokie Comment= This << distances of 8 from the >> should be << distances of eight from the >> ************************************************************** Comments attached to Yes ballot from Gregory Tabor of Maxim Integrated Products: Maxim comment number 1 Page=54 Subtype=Text Author=Mahbubul.Bari Comment= Should StatEye (www.stateye.org) need to be added to the list of other references? Maxim comment number 2 Page=115 Subtype=Caret Author=Mahbubul.Bari Comment= SL_IRM is mentioned, but is not described anywhere. (SL_IR is through out the document) Maxim comment number 3 Page=211 Subtype=Text Author=Mahbubul.Bari Comment= Impedance value should have min, nom, and max value Or tolerance. TCTF test load in 5.3.2.3 (Page 173) refers back to this section for nominal value Maxim comment number 4 Page=211 Subtype=Caret Author=Mahbubul.Bari Comment=Minimum insertion loss for cables do not seem logical Maxim comment number 5 Page=212 Subtype=Text Author=Mahbubul.Bari Comment=Scd21 is not plotted in figure 126 Maxim comment number 6 Page=212 Subtype=Text Author=Mahbubul.Bari Comment= Needs to reference figure 124 for description of L,N,H,S,fmin, and fmax Maxim comment number 7 Page=221 Subtype=Text Author=Mahbubul.Bari Comment= I have looked at SATA Revision 2.6 specification. Could not find any Gen3 infofrmation. Maxim comment number 8 Page=229 Subtype=Text Author=KWitt Comment= Add Figures of (1) pulse response and (2) insertion loss from 08-144r1 page 3. Maxim comment number 9 Page=238 Subtype=Caret Author=KWitt Comment= FNOM = 6.0 x 109 for 6 Gbps Maxim comment number 10 Page=242 Subtype=Text Author=Mahbubul.Bari Comment= Text at the beginning of the section mention measured values. Note g mention simulation. Should this be measured? Maxim comment number 11 Page=242 Subtype=Text Author=Mahbubul.Bari Comment=Is this item better in Table 65 ? Maxim comment number 12 Page=244 Subtype=Text Author=Mahbubul.Bari Comment=From the plot I read this to be -2.5dB Maxim comment number 13 Page=246 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 14 Page=246 Subtype=Caret Author=KWitt Comment=BUJ Maxim comment number 15 Page=246 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 16 Page=246 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 17 Page=246 Subtype=Caret Author=KWitt Comment=850 Maxim comment number 18 Page=246 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 19 Page=246 Subtype=Caret Author=KWitt Comment=0.1 (16.6 ps) Maxim comment number 20 Page=247 Subtype=Text Author=KWitt Comment=Add updated figure from 08-144r1 Maxim comment number 21 Page=251 Subtype=Text Author=Mahbubul.Bari Comment=Can not locate these compliance points, IRs or CRs, in any figures. Maxim comment number 22 Page=251 Subtype=Text Author=Mahbubul.Bari Comment= This table do not match the Figures. The Table should be for Scc11, Sdd11, and Scd11. Maxim comment number 23 Page=251 Subtype=Text Author=Mahbubul.Bari Comment=Wrong value Maxim comment number 24 Page=251 Subtype=Text Author=Mahbubul.Bari Comment=Should be Figure 129 Maxim comment number 25 Page=253 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 26 Page=253 Subtype=Caret Author=KWitt Comment=3 Maxim comment number 27 Page=254 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 28 Page=254 Subtype=Caret Author=KWitt Comment= f Maxim comment number 29 Page=254 Subtype=Caret Author=KWitt Comment= Maxim comment number 30 Page=254 Subtype=Caret Author=KWitt Comment= d An SSC modulated source can be used instead of fixed offset frequency crosstalk. e Based on the centroid of the vertical histogram at 1 and 0 crossing see Figure xxx f Test setup is to be within this range and it is not required to show compliance across the range. Maxim comment number 31 Page=254 Subtype=Text Author=KWitt Comment=825-875 Maxim comment number 32 Page=254 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 33 Page=254 Subtype=Text Author=KWitt Comment=0.24 (41.6ps) Maxim comment number 34 Page=254 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 35 Page=254 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 36 Page=254 Subtype=Caret Author=KWitt Comment=2500 Maxim comment number 37 Page=254 Subtype=Caret Author=KWitt Comment= d Maxim comment number 38 Page=254 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 39 Page=254 Subtype=Caret Author=KWitt Comment=(c,e,f) Maxim comment number 40 Page=254 Subtype=Caret Author=KWitt Comment=f Maxim comment number 41 Page=254 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 42 Page=254 Subtype=Caret Author=KWitt Comment=6.6 Maxim comment number 43 Page=254 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 44 Page=254 Subtype=Caret Author=KWitt Comment=0.1 Maxim comment number 45 Page=254 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 46 Page=254 Subtype=Caret Author=KWitt Comment=16.6 Maxim comment number 47 Page=254 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 48 Page=254 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 49 Page=254 Subtype=Text Author=KWitt Comment=200-230 Maxim comment number 50 Page=254 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 51 Page=254 Subtype=Caret Author=KWitt Comment=1.7-2.3 Maxim comment number 52 Page=254 Subtype=Text Author=KWitt Comment=s/b just Clock source see 08-144r1 page 8 Maxim comment number 53 Page=254 Subtype=Text Author=KWitt Comment=modify per 08-144r1 to BUJ source Maxim comment number 54 Page=254 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 55 Page=255 Subtype=Text Author=KWitt Comment=Insert figure of D24.3 response from 08-144r1 page 4. Maxim comment number 56 Page=255 Subtype=Caret Author=KWitt Comment= The delivered eye opening is the difference of the "1" level centroid at the crossing, determined with a vertical histogram, minus the "0" level centroid at the crossing, also determined with a vertical histogram. Maxim comment number 57 Page=255 Subtype=StrikeOut Author=KWitt Comment= Maxim comment number 58 Page=255 Subtype=Caret Author=KWitt Comment= in Figure 122 as illustrated in Figure xxx, with the addition of fixed SJ of 0.022UI at 20MHz. Maxim comment number 59 Page=256 Subtype=Text Author=KWitt Comment=modify Figure 132 from page 9 of 08-144r2 Maxim comment number 60 Page=256 Subtype=StrikeOut Author=KWitt Comment= ************************************************************** Comments attached to No ballot from Tim Symons of PMC-Sierra: Tim Symons Comments: #1 Section 4.8.4 Expander route index order This section refers to table to table routing and provides examples abd figures that describe how a device that does NOT support table to table routing should operate. There is no balancing text and diagrams to show how a device that DOES support table to table routing should function. I have had several discussions on whether or not table to table routing is actually supported in SAS-2. I recommend that there needs to be additional text to state the general operation of table to table routing, and a complementary figure to figure 48 that shows how it should be done. The only supporting text apprear in section 10.4.3.4 REPORT GENERAL function that descirbes the "TABLE TO TABLE SUPPORTED" bit, but is lacking in examples and implementation description. #2 When a receiver detects either TRAIN or TRAIN_DONE the text is unclear whether the transmitter should complete transmitting an entire TRAIN or TRAIN_DONE pattern, or if it should immediately start to transmit the next state pattern (after transmitting only a partial TRAIN or TRAIN_DONE pattern). I believe that the intention is that a pattern should always be transmitted in it's entirety before transitioning to the next state. The following text includes suggested changes (in {Blue}) to clarify the text. 6.7.4.2.3.4 Train-SNW . The Train-SNW utilizes TRAIN and TRAIN_DONE (see 7.2) to create training patterns, defined in table 103. ------------------------Table 103 ---------------------------------- {Blue}Each pattern shall be completely transmitted before another pattern or primitive is started.{/Blue} The scrambler is the same as that defined for the link layer (see 7.6) and shall be initialized at the end of RCDT. The scrambler shall not be re-initialized for the remainder of the Train-SNW. The phy shall start transmitting TRAIN patterns at the end of RCDT. The first TRAIN pattern may have either starting disparity. The number of TRAIN patterns transmitted is determined by the time required for the phy's receiver to complete training and acquire dword synchronization. The phy shall transmit at least one TRAIN pattern. If the phy's receiver is trained and acquires dword synchronization before TLT, then the phy shall stop transmitting TRAIN patterns and start transmitting TRAIN_DONE patterns. The phy shall transmit a minimum of four TRAIN_DONE patterns. If the phy: a) transmits four or more TRAIN_DONE patterns; and b) receives a minimum of one TRAIN_DONE before MTT, then the phy shall: a) stop transmitting TRAIN_DONE patterns {Blue}when the current pattern is complete;{/Blue} b) start transmitting dwords from the link layer; and c) consider the Train-SNW to be valid. If the phy does not receive TRAIN_DONE before MTT and transmit four or more TRAIN_DONE patterns, then it shall consider the Train-SNW to be invalid. Comments from Guillaume Fortin regarding the physical layer and JTF calibration sections: PMC comment number 1 Page=231 Subtype=Highlight Author=fortingu Comment=overall PMC comment number 2 Page=233 Subtype=Highlight Author=fortingu Comment=Notes a, b, c & d should only apply to 1.5Gbps and 3Gbps PMC comment number 3 Page=235 Subtype=Highlight Author=fortingu Comment= This requirement is not strictly sufficient to get a realistic eye mask for devices with multiple channels, such as expanders. It is proposed include the impact of crosstalk from adjacent forward and reverse channels: "Verifying compliance with the limits represented by the transmitter device eye mask should be done with reverse channel traffic present on the channel-under-test and with forward and reverse traffic present on all other channels, in order that the effects of crosstalk are taken into account." PMC comment number 4 Page=236 Subtype=Highlight Author=fortingu Comment= This requirement is not strictly sufficient to get a realistic eye mask for devices with multiple channels, such as expanders. It is proposed include the impact of crosstalk from adjacent forward and reverse channels: "Verifying compliance with the limits represented by the receiver device eye mask should be done with reverse channel traffic present on the channel-under-test and with forward and reverse traffic present on all other channels, in order that the effects of crosstalk are taken into account." PMC comment number 5 Page=240 Subtype=Highlight Author=fortingu Comment= In section 5.3.7.5 (p. 206), the first paragraph states: "Table 73 defines the maximum jitter the system shall deliver to the receiver device at the receiver device compliance point (i.e., IR or CR) for 1.5 Gbps and 3 Gbps. SSC-induced high-frequency jitter is included in DJ and consequently TJ at the transmitter device output." This implies that the value of X1 in table 59 must be measured with SSC-enabled. If true, then a single pole high-pass filter may not be sufficient to reject jitter and note b should instead refer to the JTF. The reference to the single pole high-pass filter is also inconsistent with sections 5.3.5.3 and 5.3.5.4 that mandate usage of the JTF for jitter filtering. Proposed rewording: "The value for X1 shall behalf the value of TJ for maximum delivered jitter listed in table 73. The test or analysis shall include the effects of the JTF." PMC comment number 6 Page=242 Subtype=Highlight Author=fortingu Comment=Also apply note h PMC comment number 7 Page=242 Subtype=Highlight Author=fortingu Comment=Also apply note h PMC comment number 8 Page=242 Subtype=Highlight Author=fortingu Comment= It is proposed to add note h: "The test or analysis shall include the effects of the JTF." PMC comment number 9 Page=242 Subtype=Highlight Author=fortingu Comment= With the bandwidth of the JTF scaling as a function of transition density, a D10.2 pattern will result in a stronger rejection of low frequency jitter than would a pattern with low transition density, such as D30.3. As such, an RJ measurement performed with a D10.2 pattern may not be representative of the worst case residual RJ seen by a reference receiver having a CDR function matching the JTF. It is proposed to change the reference pattern to D30.3 to keep the jitter budget consistent with the worstcase pattern for the JTF, since a receiver that implements a CDR that matches the JTF along with a 3-taps DFE should be a valid receiver. "RJ is 14 times the RJ 1 sigma value, based on a BER of 10-12. This test shall be performed with a repeating D30.3 pattern (see table 235 in 10.2.9.2) on the physical link. If the transmitter device supports SSC, this measurement shall be performed with both SSC enabled and SSC disabled. For simulations based on a BER of 10-15, the RJ specified is 17 times the RJ 1 sigma value." PMC comment number 10 Page=242 Subtype=Highlight Author=fortingu Comment= No standard method is specified to record the transmitter signal and perform the required simulation. Implementation by different vendors may yield inconsistencies in what constitutes a compliant transmitter and may result in inter-operability issues. PMC comment number 11 Page=243 Subtype=Highlight Author=fortingu Comment=add note c as well PMC comment number 12 Page=243 Subtype=Highlight Author=fortingu Comment=note b should apply PMC comment number 13 Page=243 Subtype=Highlight Author=fortingu Comment=note b should apply PMC comment number 14 Page=251 Subtype=Highlight Author=fortingu Comment=Should be 129 PMC comment number 15 Page=251 Subtype=Highlight Author=fortingu Comment=11 PMC comment number 16 Page=251 Subtype=Highlight Author=fortingu Comment=11 PMC comment number 17 Page=251 Subtype=Highlight Author=fortingu Comment=11 PMC comment number 18 Page=254 Subtype=Highlight Author=fortingu Comment= Several objections to the table 72, which are addressed by Kevin Witt in proposal 08-144r1 PMC comment number 19 Page=254 Subtype=Highlight Author=fortingu Comment= It is proposed to clarify note 'b' to highlight that activity must be present on both receive and transmit phys: "This specification pertains to the delivered signal at IR or CR during the receiver device compliance test. All adjacent receive and transmit phys in the receiver device shall be active with representative traffic with their maximum amplitude and maximum frequency of operation. Additional pseudo-random crosstalk shall be added, if needed, to meet the total crosstalk amplitude specification." PMC comment number 20 Page=254 Subtype=Highlight Author=fortingu Comment= Add "SSC modulation frequency" units="kHz" min=30, max=33 "SSC modulation amplitude" units="ppm" typ=2200-2300, note f "SSC modulation profile" typ=triangular PMC comment number 21 Page=254 Subtype=Highlight Author=fortingu Comment=The SSC modulation source should be added. PMC comment number 22 Page=254 Subtype=Highlight Author=fortingu Comment= It is proposed to add: "If the receiver device under test includes a CJTPAT or disparity errors checker, it is recommended to perform this test with a triangular SSC modulation." PMC comment number 23 Page=255 Subtype=Highlight Author=fortingu Comment= Section 5.3.7.6 only specifies the sinusoidal jitter limit for 1.5Gb/s and 3Gb/s. It should be extended for 6Gb/s if the intent is to include a 0.1UI SJ margin for 6G SAS-2 jitter tolerance test. PMC comment number 24 Page=255 Subtype=Highlight Author=fortingu Comment= For inclusion of SSC in the test procedure, we should add: "If the receiver device is tested with an SSC modulated signal, the residual SSC jitter shall be accounted for when calibrating the transmit signal BUJ. The transmit BUJ shall be measured through the JTF using a D30.3 pattern, with ± 2300 ppm triangular SSC modulating the pattern generator clock source." PMC comment number 25 Page=256 Subtype=Highlight Author=fortingu Comment= Figure 132 (section 5.3.7.4.4.7, p. 204) does not include the RJ and BUJ jitter sources from figure 131 and table 72. These jitter sources should be added so that the SJ sweep test is a true JT margin test. The SSC modulation source should also be added. PMC comment number 26 Page=258 Subtype=Highlight Author=fortingu Comment= SSC-induced jitter is included in the deterministic jitter (DJ) and consequently in total jitter (TJ) at the transmitter output." should be "SSC-induced jitter is included in the deterministic jitter (DJ) and consequently in *the* total jitter (TJ) at the transmitter output.". "*" added for emphasis and not meant to be part of the text. PMC comment number 27 Page=258 Subtype=Highlight Author=fortingu Comment="in the total jitter" PMC comment number 28 Page=258 Subtype=Highlight Author=fortingu Comment= May need to change to "bounded un-correlated jitter (BUJ)" to stay in line with the proposed change to the tx jitter specs that was discussed at the March face-to-face meeting. PMC comment number 29 Page=738 Subtype=Text Author=fortingu Comment=Marked set by fortingu PMC comment number 30 Page=738 Subtype=Highlight Author=fortingu Comment= Section B.10 only mandates the use of a D24.3 pattern to adjust the -3dB bandwidth of the JTF and does not describe how to verify that the JTF -3dB corner varies proportionally to the transition density of the pattern. It is proposed to replace the highlighted text with: "Three tests are performed in the upper frequency band: a) the adjustment of the -3 dB bandwidth of the JTF; and b) the verification of the peaking (see 5.3.5.2); and c) the verification of the displacement of the -3 dB bandwidth of the JTF with varying pattern density." This will bring the JTF calibration procedure in line with the last paragraph of section 5.3.5.2 (page 185) that states: "A proportional decrease of the JTF -3 dB corner frequency should be observedfor a decrease in pattern transition density compared to a 0.5 transition density. If a JMD shifts the JTF -3 dB corner frequency in a manner that does not match this characteristic, or does not shift at all, measurements of jitter with patterns with transition densities different than 0.5 may lead to discrepancies in reported jitter levels. In the case of reported jitter discrepancies between JMDs, the JMD with the shift of the -3 dB corner frequency that is closest to the proportional characteristic of the reference channel shall be considered correct. This characteristic may be measured with the conditions defined above for measuring the -3 dB corner frequency, but substituting other patterns with different transition densities." Further comments target the same objective of consistency between B.10 and 5.3.5.2. PMC comment number 31 Page=738 Subtype=StrikeOut Author=fortingu Comment=To account for the addition of a 3rd test. PMC comment number 32 Page=739 Subtype=Highlight Author=fortingu Comment="five" PMC comment number 33 Page=739 Subtype=Highlight Author=fortingu Comment= It is proposed to add below this line: "d) a 900 MHz square wave with a sinusoidal phase modulation of 100 ps ± 10% peak to peak at 50 MHz ± 1 %; and e) a 900 MHz square wave with no modulation." PMC comment number 34 Page=740 Subtype=Highlight Author=fortingu Comment= It is proposed to add below this line: "15) adjust the pattern generator for a 6 Gbps D30.3 pattern (001111000111000011100) and modulation to produce a 50 MHz ±1 %, 0.3 ± 10 % UI peak-to-peak (100 ps) sinusoidal phase modulation (i.e., periodic jitter (PJ)); 16) verify the level of modulation meets the requirements and record the peak-to-peak level as DJ_M_LOWTD. The independent verification of the 50 MHz test signal is a jitter measurement by separate means from the JMD under calibration. This may be measured with: A) a time interval error plot with constant frequency clock on a real time oscilloscope; B) an equivalent time oscilloscope with histogram and constant frequency clock; C) a bit error rate tester (BERT) using a constant frequency clock; or D) a spectral analysis with the Bessel expansion of angle modulated sidebands; 17) apply the test signal to the JMD. Turn off the sinusoidal phase modulation. Record the reported DJ as DJ_MOFF_LOWTD; 18) turn on the sinusoidal phase modulation. Record the reported DJ as DJ_MON_LOWTD; 19) calculate the difference in reported DJ for these two cases, DJ_MM_LOWTD = DJ_MON_LOWTD - DJ_MOFF_LOWTD. Calculate the -3dB value: DJ_3DB_LOWTD = DJ_MM_LOWTD x 0.707; 20) adjust the frequency of the PJ source to 1.6 MHz ± 0.1 MHz. Measure the reported DJ difference between PJ on versus PJ off (i.e., DJ_LOWTD = DJ_ON_LOWTD - DJ_OFF_LOWTD) and compare DJ to DJ_3DB_LOWTD. Shift the frequency of the PJ source until the reported DJ difference between PJ on versus PJ off is equal to DJ_3DB_LOWTD. The PJ frequency is the -3 dB bandwidth of the JTF; record this value as F_3DB_LOWTD; F_3DB_LOWTD should be 1.6 MHz ± 0.3 MHz." PMC comment number 35 Page=740 Subtype=Highlight Author=fortingu Comment=DJ_3DB ************************************************************** Comments attached to No ballot from Gerald Houlder of Seagate Technology: Seagate comment number 1 Page=52 Subtype=Text Author=5497 Comment=ATA8-AAM and ATA8-ACS do not have correct ISO/IEC numbers. Seagate comment number 2 Page=53 Subtype=Highlight Author=5497 Comment=xxxxx-xxx This is incorrect ISO number. Seagate comment number 3 Page=53 Subtype=Highlight Author=5497 Comment=xxxxx-xxx, This is incorrect ISO number. Seagate comment number 4 Page=59 Subtype=Highlight Author=5497 Comment= Broadcast -- why is this capitalized but none of the other objects within an expander are capitalized? Seagate comment number 5 Page=59 Subtype=Highlight Author=5497 Comment= application layer should be "SCSI application layer". Seagate comment number 6 Page=61 Subtype=Highlight Author=5497 Comment= usually relaying a request (see 3.1.187) from a peer higher layer state machine. -- the "peer higher layer" phrase totally loses me. If you are a lower level machine passing a message to a higher layer machine, how can there be a peer higher layer machine to the lower layer machine? I think this entire phrase should be deleted. Seagate comment number 7 Page=70 Subtype=Highlight Author=5497 Comment= application layer should this be "SCSI application layer"? Seagate comment number 8 Page=71 Subtype=Highlight Author=5497 Comment= broadcast propagation processor -- why is the word Broadcast capitalized in all other occurrances of this phrase but not here? I actually think none should be capitalized unless it is the first word of a sentence. Seagate comment number 9 Page=75 Subtype=Highlight Author=5497 Comment= shall be s/b is usually ... there are cases where invalid dwords or frames are just counted or ignored rather than "reported as an error". Also SNW-final makes assumption of "non-support" rather than error for invalid SNW windows. Seagate comment number 10 Page=76 Subtype=Highlight Author=5497 Comment= vendor specific: Most references to "vendor specific" in this document use a hyphen (i.e. vendor-specific) but this instance and a handful of others don't. We should be consistent -- always use the hyphen or always use space. Seagate comment number 11 Page=82 Subtype=Highlight Author=5497 Comment= arguments s/b "argument" (not plural). Seagate comment number 12 Page=82 Subtype=Highlight Author=5497 Comment= those s/b 'the". Seagate comment number 13 Page=82 Subtype=Highlight Author=5497 Comment= those arguments s/b "the argument" Seagate comment number 14 Page=82 Subtype=Highlight Author=5497 Comment= values s/b "value" (not plural) Seagate comment number 15 Page=82 Subtype=Highlight Author=5497 Comment= different values s/b "a different value" (not plural) Seagate comment number 16 Page=94 Subtype=Highlight Author=5497 Comment= Figure 18 shows Figure 18 is the same as figure 15 except that it shows less detail in some respects. Why can't this figure be deleted and the reference changed to figure 15? Seagate comment number 17 Page=102 Subtype=Highlight Author=5497 Comment= A and B A and B seem to be examples of one initiator port attached to one target port (wide link). I think you mean B and C as an example of one initiator port attached to multiple target ports. Seagate comment number 18 Page=102 Subtype=Highlight Author=5497 Comment= A and C This seems to illustrate one SAS initiator port with connections to multiple SAS target ports. D and E illustrates connection to multiple initiator phys, but they might still the same initiator port. Seagate comment number 19 Page=111 Subtype=Highlight Author=5497 Comment= Not a deletable primitive 3 levels up, the SAS link layer inserts rate matching deletable primitives. Therefore there can be deletable primitives in this path when rate matching. Seagate comment number 20 Page=118 Subtype=Highlight Author=5497 Comment= SL_IR State Machine[0..1] It appear to me that every link layer shall include SL_IR state machine, so the brackets should be [1]. Seagate comment number 21 Page=118 Subtype=Highlight Author=5497 Comment= SL State Machine[0..1] It appear to me that every link layer shall include SL state machine, so the brackets should be [1]. Seagate comment number 22 Page=167 Subtype=Highlight Author=5497 Comment= WC = wrapping counter; b) PVD = peak value detector; and The WC and PVD abbreviations should be added to clause 3.2. Seagate comment number 23 Page=221 Subtype=Text Author=CoxA Comment= There needs to be a place holder here rather than referencing SATA-2 since there is no SATA 6Gbps specification available yet and we don't know what it will be called. Seagate comment number 24 Page=229 Subtype=Text Author=CoxA Comment=Why is this a note rather than text included in the specification? Seagate comment number 25 Page=229 Subtype=Text Author=CoxA Comment=Why is this a note rather than text included in the specification? Seagate comment number 26 Page=231 Subtype=Text Author=CoxA Comment=Why is this a note rather than text included in the specification? Seagate comment number 27 Page=235 Subtype=Text Author=CoxA Comment=First occurrence. jitter measurement device (JMD) Seagate comment number 28 Page=242 Subtype=Text Author=CoxA Comment= Shouldn't the maximum voltage (non-operational) be a minimum rather than nominal? For 1.5 and 3.0, it is not included in a min/nom/max line. Maybe this should be called non-operational withstanding voltage and be in the minimum column. Seagate comment number 29 Page=242 Subtype=Text Author=CoxA Comment= Drop minimum from rise/fall time since the minimum is what is specified in the table. Seagate comment number 30 Page=245 Subtype=Text Author=CoxA Comment= "none" is incorrect. A value was intentionally not supplied. This entry in the table should be left blank. Seagate comment number 31 Page=246 Subtype=Text Author=CoxA Comment=Why is this a note rather than text included in the specification? Seagate comment number 32 Page=246 Subtype=Text Author=CoxA Comment= This value should be closer to the minimum allowed transmitter output voltage. Seagate comment number 33 Page=247 Subtype=Text Author=CoxA Comment= The pk-pk is not a mode measurement and should indicate some point beyond what appears as a mode value. Seagate comment number 34 Page=248 Subtype=StrikeOut Author=CoxA Comment= Seagate comment number 35 Page=248 Subtype=Caret Author=CoxA Comment=with Seagate comment number 36 Page=251 Subtype=Text Author=CoxA Comment= Change from "Non-operational input voltage transient" to "Input voltage (non-operational)" Seagate comment number 37 Page=252 Subtype=Text Author=CoxA Comment=Why is this a note rather than text included in the specification? Seagate comment number 38 Page=315 Subtype=Highlight Author=5497 Comment= a) There are two item a's. The list should be itemized a through e. Seagate comment number 39 Page=339 Subtype=Highlight Author=5497 Comment= not specific to the type of connection. This seems to be an inappropriate title for Table 108. The table includes a "use" column which does specify a particular connection type in which the primitive is used, so they are specific to that type of connection. How about "not specific to SSP, SMP, or STP connection". Seagate comment number 40 Page=339 Subtype=Highlight Author=5497 Comment= Conn Why isn't this type of primitive in Table 109 (primitives only used within SSP and SMP connections)? The table description qualifies it to be. Seagate comment number 41 Page=339 Subtype=Highlight Author=5497 Comment= STP Why isn't this primitive in table 110 (primitives only used inside STP connections)? The description qualifies it for that table. Seagate comment number 42 Page=354 Subtype=Highlight Author=5497 Comment= I_T nexus loss, logical unit reset, and hard reset shall not cause a SAS target device to spin-up automatically on receipt of NOTIFY (ENABLE SPINUP). The point of this sentence is unclear. This clause specifies NOTIFY(ENABLE SPINUP) alone gives permission of device to spin up -- does this sentence mean that a reset just before a NOTIFY revokes the spinup permission? Seagate comment number 43 Page=356 Subtype=Highlight Author=5497 Comment= Description None of these descriptions provide useful information. The description column contents should be replaced with a reference to Table 7, which does have a useful description. Seagate comment number 44 Page=356 Subtype=Highlight Author=5497 Comment= ignored. Should this sentence be added? "A BROADCAST received inside a connection shall be ignored." Seagate comment number 45 Page=359 Subtype=Highlight Author=5497 Comment= is not configuring and Delete this phrase, it adds nothing useful and may have a confusing meaning to some readers. Seagate comment number 46 Page=364 Subtype=Highlight Author=5497 Comment= Dwords are discarded if the elasticity buffer overflows. This sentence is redundant with the previous sentence. Change this to "ALIGN primitives may be added to prevent buffer underflows" or just delete it. Seagate comment number 47 Page=385 Subtype=Highlight Author=5497 Comment= valid IDENTIFY address I have two questions: (1) What is a valid IDENTIFY address frame? If the frame contents are different from the last phy reset with no hard reset in between, does this make it invalid? (2) What should happen if an invalid IDENTIFY frame is received? Should hard reset be assumed? Seagate comment number 48 Page=392 Subtype=Highlight Author=5497 Comment= as well as replace with "or". Seagate comment number 49 Page=392 Subtype=Highlight Author=5497 Comment= b) This item seems redundant with Note 60. Can note 60 be reduced to a reference to "dword synchronization unexpectedly lost"? Seagate comment number 50 Page=398 Subtype=Highlight Author=5497 Comment= tear down Is there a better term for this? "release" perhaps? At the very least there should be a glossary entry for this if it stays. Seagate comment number 51 Page=400 Subtype=Highlight Author=5497 Comment= not configuring; Does this mean "not performing the configuration process"? Or does it mean the configuration process is complete but isn't possible to find a route between these two endpoints? I think this use of "configuring" (or not) needs a glossary entry. Seagate comment number 52 Page=402 Subtype=Highlight Author=5497 Comment= Ignore expand to "ignore the BREAK_REPLY." Seagate comment number 53 Page=405 Subtype=Highlight Author=5497 Comment= Ignore replace with "ignore the BREAK_REPLY." Seagate comment number 54 Page=411 Subtype=Highlight Author=5497 Comment= Retry Should be all CAPs. Seagate comment number 55 Page=425 Subtype=Highlight Author=5497 Comment= Normal) add the word "message" after this phrase. Seagate comment number 56 Page=425 Subtype=Highlight Author=5497 Comment= (No Destination) add the word "message" after this phrase. Seagate comment number 57 Page=425 Subtype=Highlight Author=5497 Comment= BREAK add the word "message" after this phrase. Seagate comment number 58 Page=425 Subtype=Highlight Author=5497 Comment= BREAK_REPLY add the word "message" after this phrase. Seagate comment number 59 Page=425 Subtype=Highlight Author=5497 Comment= (Change) Add "message" after this phrase. Seagate comment number 60 Page=425 Subtype=Highlight Author=5497 Comment= (Normal) Add "message" after this phrase. Seagate comment number 61 Page=425 Subtype=Highlight Author=5497 Comment= OPEN_ACCEPT Add "message" after this phrase. Seagate comment number 62 Page=425 Subtype=Highlight Author=5497 Comment= Frame Add "message" after this phrase. Seagate comment number 63 Page=425 Subtype=Highlight Author=5497 Comment= Dword Add "message" after this phrase. Seagate comment number 64 Page=425 Subtype=Highlight Author=5497 Comment= Dword add the word "message" after this phrase. Seagate comment number 65 Page=426 Subtype=Highlight Author=5497 Comment= (Normal Shouldn't this be all CAPs (i.e., NORMAL)? Seagate comment number 66 Page=427 Subtype=Highlight Author=5497 Comment= Normal add the word "message" after this phrase. Seagate comment number 67 Page=427 Subtype=Highlight Author=5497 Comment= Waiting On Partial add the word "message" after this phrase. Seagate comment number 68 Page=427 Subtype=Highlight Author=5497 Comment= Waiting On Connection) add the word "message" after this phrase. Seagate comment number 69 Page=429 Subtype=Highlight Author=5497 Comment= Normal Shouldn't this be all CAPs (i.e., NORMAL)? Seagate comment number 70 Page=429 Subtype=Highlight Author=5497 Comment= Waiting On Partial) add the word "message" after this phrase. Seagate comment number 71 Page=429 Subtype=Highlight Author=5497 Comment= Waiting On Connection add the word "message" after this phrase. Seagate comment number 72 Page=429 Subtype=Highlight Author=5497 Comment= (Waiting On Device) add the word "message" after this phrase. Seagate comment number 73 Page=429 Subtype=Highlight Author=5497 Comment= OPEN_ACCEPT add the word "message" after this phrase. Seagate comment number 74 Page=429 Subtype=Highlight Author=5497 Comment= OPEN_REJECT add the word "message" after this phrase. Seagate comment number 75 Page=431 Subtype=Highlight Author=5497 Comment= g) Delete the empty item g). Seagate comment number 76 Page=436 Subtype=Highlight Author=5497 Comment= shall not reject This "shall not" case is OK, but there doesn't seem to be any recommendation of what should be done in this situation. Shouldn't such a recommendation be added? Seagate comment number 77 Page=436 Subtype=Text Author=5497 Comment= Since I don't see this rule anywhere else, we should insert this sentence here: "Other primitives may be interspersed during the connection." Seagate comment number 78 Page=437 Subtype=Highlight Author=5497 Comment= tags This is an ambiguous tag reference. Seagate comment number 79 Page=437 Subtype=Highlight Author=5497 Comment= application layer Should be "SCSI application layer". Seagate comment number 80 Page=438 Subtype=Highlight Author=5497 Comment= tag Is this a reference to INITIATIOR CONNECTION TAG field, or TAG field, or combination of the values in the INITIATOR PORT bit, the PROTOCOL field, the INITIATOR CONNECTION TAG field, and/or the FEATURES field in the OPEN address frame? There are a number of other instances of "tag" that are similarly ambiguous and probably mean a different "tag". Some are arguments. The different tag uses should have a defined term for each or change to referencing a specific TAG field instead. Seagate comment number 81 Page=438 Subtype=Highlight Author=5497 Comment= tag This is an ambiguous tag reference. Seagate comment number 82 Page=438 Subtype=Highlight Author=5497 Comment= tag This is an ambiguous tag reference. Seagate comment number 83 Page=438 Subtype=Highlight Author=5497 Comment= tag This is an ambiguous tag reference. Seagate comment number 84 Page=439 Subtype=Highlight Author=5497 Comment= tag This is an ambiguous tag reference. Seagate comment number 85 Page=443 Subtype=Highlight Author=5497 Comment= (Normal) Add "message" after this phrase. Seagate comment number 86 Page=443 Subtype=Highlight Author=5497 Comment= CREDIT_BLOCKED Add "message" after this phrase. Seagate comment number 87 Page=443 Subtype=Highlight Author=5497 Comment= ACK Add "message" after this phrase. Seagate comment number 88 Page=444 Subtype=Highlight Author=5497 Comment= (CRC Error) Add "message" after this phrase. Seagate comment number 89 Page=444 Subtype=Highlight Author=5497 Comment= (Normal) Add "message" after this phrase. Seagate comment number 90 Page=446 Subtype=Highlight Author=5497 Comment= NOTE 75 - The DONE Timeout timer in one phy (e.g., phy A) may expire concurrently with the ACK/NAK Timeout timer in the other phy (e.g., phy B) in a connection. For this note, should the reader assume "phy A" is at one end of a link (e.g., target) and "phy B" is at the other end of the link (e.g., initiator), or can both phys be at the same end of a link (e.g., target phys that are part of a wide link). This needs to be clarified. Seagate comment number 91 Page=446 Subtype=Highlight Author=5497 Comment= application layer Should be "SCSI application layer". Seagate comment number 92 Page=449 Subtype=Highlight Author=5497 Comment= this state shall discard the Data Dword Received messages received before the subsequent SOF Received message. Should this state also discard the first SOF Received message? Seagate comment number 93 Page=450 Subtype=Highlight Author=5497 Comment= Transmitted Add "message" after this phrase. Seagate comment number 94 Page=463 Subtype=Text Author=5497 Comment= There should be a sentence here that says "An SMP initiator establishes an SMP connection by sending an OPEN address frame to to an SMP target ports" Seagate comment number 95 Page=469 Subtype=Highlight Author=5497 Comment= same SAS address. add "same SAS address if the ports are in different SAS domains (see 4.2.7)." Seagate comment number 96 Page=474 Subtype=Highlight Author=5497 Comment= SSP and SMP) Can't STP transport layer also generate Transmit Frame requests? Seagate comment number 97 Page=476 Subtype=Highlight Author=5497 Comment= Retry Open (Retry) Add "message" after this phrase. Seagate comment number 98 Page=477 Subtype=Highlight Author=5497 Comment= initiator connection tag This term should be defined in Definitions clause. Should this term be used in place of "tag" in some or all of the other places where the meaning of tag is ambiguous? Seagate comment number 99 Page=481 Subtype=Highlight Author=5497 Comment= tag This is an ambiguous tag reference. Seagate comment number 100 Page=482 Subtype=Highlight Author=5497 Comment= tag. This is an ambiguous tag reference. Seagate comment number 101 Page=489 Subtype=Highlight Author=5497 Comment= tag This is an ambiguous tag reference. Seagate comment number 102 Page=494 Subtype=Text Author=5497 Comment= I find the TLR CONTROL field description to be in an unconventional order and hard to follow. It would be better to describe what the 00, 01, 10, and 11 combinations mean before describing rules for when they shall or shall not be set. Currently the text tells the reader rules for when certain combinations are allowed before describing what the combinations mean. Seagate comment number 103 Page=495 Subtype=Highlight Author=5497 Comment= in 9.2.4 and clause reference should be 9.2.4.5. Seagate comment number 104 Page=496 Subtype=Highlight Author=5497 Comment= EOF Should be "the first byte of the CRC field". Seagate comment number 105 Page=496 Subtype=Highlight Author=5497 Comment= checked should be "generated and checked" Seagate comment number 106 Page=497 Subtype=Highlight Author=5497 Comment= or changeable; Delete this. If the FIRST BURST SIZE is changeable but set to zero the ENABLE FIRST BURST bit should still be set to zero. Seagate comment number 107 Page=498 Subtype=Highlight Author=5497 Comment= end of the CDB and the end of the two fields shall be ignored should be "last valid CDB byte and the end of the CDB field shall be ignored". Seagate comment number 108 Page=500 Subtype=Text Author=5497 Comment= Insert a paragraph: The TAG OF TASK TO BE MANAGED field indicates the TAG field value of the task that is to be managed. This field is only used for cases indicated in table 168; otherwise, it is ignored. Seagate comment number 109 Page=501 Subtype=Highlight Author=5497 Comment= The size of the DATA field (i.e., the data length) is determined by the NUMBER OF FILL BYTES field in the frame header (see 9.2.1) and the link layer reception of EOF (see 7.16.3). This description is insufficient. I suggest: "The size of the DATA field (i.e., the data length) is determined by counting the number of data dwords between SOF and EOF and subtracting 28 (to account for the 24 byte header information and the 4 byte CRC information). The number of valid data bytes is determined by ignoring the last NUMBER OF FILL BYTES bytes of the DATA field." Seagate comment number 110 Page=501 Subtype=Highlight Author=5497 Comment= (see 9.2.1). replace with "(see table 164)". Seagate comment number 111 Page=502 Subtype=Highlight Author=5497 Comment= RETRY DELAY TIMER field contains the retry delay timer code SAM-4 has renamed this field the STATUS QUALIFIER CODE field. SAS-2 needs to rename this accordingly. Seagate comment number 112 Page=507 Subtype=Highlight Author=5497 Comment= application layer, Should be "SCSI application layer". Seagate comment number 113 Page=508 Subtype=Highlight Author=5497 Comment= tag ambiguous meaning of tag. Later in this clause the term "tag of the COMMAND frame" is used, that would be better here. Perhaps we should define a term "command tag" that means the value of the TAG field in the command frame. This term could be used in a lot of places to clear up ambiguous use of 'tag". Seagate comment number 114 Page=508 Subtype=Highlight Author=5497 Comment= retransmit the COMMAND frame at least one time Need to add description of action if all retries are unsuccessful as well. Seagate comment number 115 Page=508 Subtype=Highlight Author=5497 Comment= QUERY TASK; Query Task support is supposed to be optional (i.e., only needed if transport layer retries are supported) but this wording seems to require Query Task support regardless. If Query Task is optional then an alternate recovery method is needed here. Seagate comment number 116 Page=508 Subtype=Highlight Author=5497 Comment= supports the QUERY TASK This implies Query Task is optional (ie only required if transport layer retries are enabled) but command frame error recovery in next clause seems to require Query Task regardless. Which statement is correct? Seagate comment number 117 Page=509 Subtype=Highlight Author=5497 Comment= at least one time. There should be discussion of action to take when retries are exhausted and transfer is still unsuccessful. Seagate comment number 118 Page=509 Subtype=Highlight Author=5497 Comment= transmits the TASK frame Need to add description of action after retries are exhausted and transfer is still unsuccessful. Seagate comment number 119 Page=510 Subtype=Highlight Author=5497 Comment= retransmits, in a new connection, all the read DATA frames This description doesn't indicate what should happen when it does give up on retries. Seagate comment number 120 Page=510 Subtype=Highlight Author=5497 Comment= retransmits, in a new connection, all the write DATA frames This case also doesn't indicate action when all retries are exhausted. Seagate comment number 121 Page=511 Subtype=Highlight Author=5497 Comment= The number of times it retransmits each RESPONSE frame is vendor-specific. There should be discussion of what the target does if all retransmissions also fail (i.e., NAK or ACK/NAK TIMEOUT occurrs). Seagate comment number 122 Page=513 Subtype=Highlight Author=5497 Comment= that does not contain first burst data replace with: "when first burst data is not permitted (e.g., ENABLE FIRST BURST is set to zero in the command frame)" Seagate comment number 123 Page=513 Subtype=Highlight Author=5497 Comment= (i.e. should be "e.g.". Another case is the target may not have received all the requested data but doesn't have and XFER_RDY frame outstanding. Seagate comment number 124 Page=513 Subtype=Highlight Author=5497 Comment= receives replace with: "is not using target port transfer tags and receives". Seagate comment number 125 Page=513 Subtype=Highlight Author=5497 Comment= may return should be "returns". Seagate comment number 126 Page=513 Subtype=Highlight Author=5497 Comment= ST_TTS state machine discards the frame The ST_TFR state machine also discards frames with this type of error (see 5 paragraphs earlier). Is this an unneeded overlap in responsibility or must both machines act together to make the discard happen? Seagate comment number 127 Page=513 Subtype=Highlight Author=5497 Comment= application layer Should be "SCSI application layer" like items a) and c), else there is more explaining to do. Seagate comment number 128 Page=513 Subtype=Highlight Author=5497 Comment= tag Is this the command tag? Seagate comment number 129 Page=513 Subtype=Highlight Author=5497 Comment= NOTE 88 - Although allowed by this standard, the ST state machines do not handle bidirectional commands that result in concurrent write DATA frames and read DATA frames. This seems like a requirement that should NOT be hidden away in a note. The statement also seems wrong -- if the ST state machines in this standard don't allow this feature, then "this standard" doesn't allow it. Is it trying to say that the feature is allowed by SAM but not by this standard? Seagate comment number 130 Page=516 Subtype=Highlight Author=5497 Comment= data-out buffer; Does this mean data-out buffer address, or data-out buffer contents? Why shouldn't there also be a data-in buffer argument? Seagate comment number 131 Page=516 Subtype=Highlight Author=5497 Comment= operations should be singular, not plural. Seagate comment number 132 Page=517 Subtype=Highlight Author=5497 Comment= may send a vendor-specific confirmation This is optional? If some do it and others don't, wouldn't this cause interoperability problems? Seagate comment number 133 Page=559 Subtype=Highlight Author=5497 Comment= Maximum of 232 Why this maximum? The maximum length specifiable in SCSI SDB is 2^32 blocks (not bytes), so can be larger than this. Seagate comment number 134 Page=569 Subtype=Highlight Author=5497 Comment= abort all task management functions received on that I_T nexus Overlapped commands should result in both commands (or maybe all commands) being aborted, not task management functions aborted. If a Task management function overlaps a command some different rules might apply. Seagate comment number 135 Page=570 Subtype=Highlight Author=5497 Comment= task router and task manager(s) shall: The previous clause says this error shall be handled as defined in SAM-4, but this clause specifies a particular handling that could be different than what SAM-4 says. Need to resolve this contradiction. Seagate comment number 136 Page=571 Subtype=Highlight Author=5497 Comment= not implemented, Rules a) and b) below make no sense to me for an unimplemented mode page. How can an unimplemented value be changable? how can a mode page structure exist if it isn't implemented? Seagate comment number 137 Page=572 Subtype=Highlight Author=5497 Comment= and shall be set to the value defined in table 214. This phrase in this sentence and the next 2 sentences can be deleted. Seagate comment number 138 Page=574 Subtype=Highlight Author=5497 Comment= and shall be set to the value defined in table 215. This phrase in this sentence and the next 2 sentences should be deleted. SPC-4 correctly and fully defines these fields and SAS should usurp those definitions. Seagate comment number 139 Page=575 Subtype=Highlight Author=5497 Comment= and shall be set to the value defined in table 216. Same comment as in earlier mode pages. Seagate comment number 140 Page=579 Subtype=Highlight Author=5497 Comment= phy In general, this should be plural. Also the sentence should be obvious since each phy has its own descriptor. The sentence should be deleted. Seagate comment number 141 Page=582 Subtype=Highlight Author=5497 Comment= SPC-4and Add a space before "and". Seagate comment number 142 Page=584 Subtype=Highlight Author=5497 Comment= 0 or 1 Replacing this with "any" would reinforce the idea that the value will be ignored. Seagate comment number 143 Page=584 Subtype=Highlight Author=5497 Comment= 0 or 1 Replacing this with "any" would reinforce the idea that the value will be ignored. Seagate comment number 144 Page=587 Subtype=Highlight Author=5497 Comment= Editor's Note 6: That field should be defined in SPC-4 for all protocols. Once done, add "is defined in SPC-4 and" This note must be resolved and deleted. Seagate comment number 145 Page=592 Subtype=Highlight Author=5497 Comment= Editor's Note 7: there are several more tables using D10.2 now... should they all be listed? Remove editors note. Seagate comment number 146 Page=593 Subtype=Highlight Author=5497 Comment= b) delay spin-ups requested by START STOP UNIT commands. Add bullet "c) delay spinups requested for recovery from Standby power state." Seagate comment number 147 Page=593 Subtype=Highlight Author=5497 Comment= 10.2.10 SCSI power conditions This entire clause seems to be written so that it is intended to be located in SBC (there are references to "SAS specific" and "SBC specific" states). If it were located in SBC and merged with requirements there, we would only have to manage two versions of power management instead of three versions like today. Seagate comment number 148 Page=594 Subtype=Highlight Author=5497 Comment= configured to start There is no mention in SAS-2 of a method to do this configuration. Shouldn't this be described? Seagate comment number 149 Page=594 Subtype=Highlight Author=5497 Comment= SBC-2 s/b SBC-3 Seagate comment number 150 Page=595 Subtype=Highlight Author=5497 Comment= SPC-4 Use SBC-3 as reference instead, since it includes START-STOP UNIT command details that SPC doesn't. Seagate comment number 151 Page=595 Subtype=Highlight Author=5497 Comment= expires s/b "is enabled and is zero". Seagate comment number 152 Page=595 Subtype=Highlight Author=5497 Comment= expires s/b "is enabled and is zero". Seagate comment number 153 Page=595 Subtype=Highlight Author=5497 Comment= SPC-4 Use SBC-3 as reference instead, since it includes START-STOP UNIT command details that SPC doesn't. Seagate comment number 154 Page=595 Subtype=Highlight Author=5497 Comment= expires s/b "is enabled and is zero". Seagate comment number 155 Page=596 Subtype=Highlight Author=5497 Comment= SPC-4 Use SBC-3 as reference instead, since it includes START-STOP UNIT command details that SPC doesn't. Seagate comment number 156 Page=597 Subtype=Highlight Author=5497 Comment= expires s/b "is enabled and is zero". Actually, I don't think it is possible to be in Active_Wait state unless the standby timer is either disabled (due to START STOP command entrance) or already zero. Seagate comment number 157 Page=597 Subtype=Highlight Author=5497 Comment= expires s/b "is enabled and is zero". Actually, I don't think it is possible to be in Active_Wait state unless the standby timer is either disabled (due to START STOP command entrance) or already zero. Seagate comment number 158 Page=598 Subtype=Highlight Author=5497 Comment= expires s/b "is enabled and is zero". Actually, I don't think it is possible to be in Idle_Wait state unless the standby timer is either disabled (due to START STOP command entrance) or already zero. Seagate comment number 159 Page=601 Subtype=Highlight Author=5497 Comment= information descriptors. Add this additional sentence: "A logical unit information descriptor should be included for each logical unit accessible to this target port." Seagate comment number 160 Page=608 Subtype=Highlight Author=5497 Comment= The management device server supports the SMP function. Does this also mean the function completed successfully? A sentence should be added to clarify this. Seagate comment number 161 Page=631 Subtype=Highlight Author=5497 Comment= application layer Shouldn't this be layers (plural)? Seagate comment number 162 Page=631 Subtype=Highlight Author=5497 Comment= application layer Should be layers (plural). Seagate comment number 163 Page=715 Subtype=Highlight Author=5497 Comment= B) an SMP frame header followed by 23 bytes; Are the 23 bytes random data bytes or is there a restriction on what they should be that needs to be stated here? Seagate comment number 164 Page=731 Subtype=Text Author=CoxA Comment=Should we use the term "return loss" here? Seagate comment number 165 Page=734 Subtype=Text Author=CoxA Comment=S22 or S11? Text and figure need to be consistent. Seagate comment number 166 Page=737 Subtype=StrikeOut Author=CoxA Comment= Seagate comment number 167 Page=737 Subtype=Caret Author=CoxA Comment=should Seagate comment number 168 Page=739 Subtype=Text Author=CoxA Comment= Add sentence here: " See 5.3.4.2 for actual specified values. The values given above are for reference purposes only and may not reflect the actual standard requirements. Seagate comment number 169 Page=739 Subtype=StrikeOut Author=CoxA Comment= Seagate comment number 170 Page=739 Subtype=Caret Author=CoxA Comment=should Seagate comment number 171 Page=739 Subtype=StrikeOut Author=CoxA Comment= Seagate comment number 172 Page=739 Subtype=Caret Author=CoxA Comment= should Seagate comment number 173 Page=740 Subtype=StrikeOut Author=CoxA Comment= Seagate comment number 174 Page=740 Subtype=Caret Author=CoxA Comment=should ************************************************************** Comments attached to Abs ballot from Roger Cummings of Symantec: Not with our organization's scope of expertise or concern ************************************************************** Comments attached to No ballot from Mark Evans of Western Digital: Summary of Comments on Serial Attached SCSI - 2 (SAS-2) Standard by Western Digital Corporation WDC 1 Page: xlix layer. It describes s/b layer, including definition of the WDC 2 Page: xlix defines [Delete this word.] WDC 3 Page: xlix layer. It describes s/b layer, including definition of the WDC 4 Page: xlix layer. It describes s/b layer, including definition of the WDC 5 Page: xlix layer. It describes s/b layer, including definition of the WDC 6 Page: xlix layer. It describes s/b layer, including definition of the WDC 7 Page: 3 the FC Port terminology used within MJSQ should be substituted with SAS phy terminology. s/b [There should be more about how to do this, at the very least a couple of oe.g.os would be helpful.] WDC 8 Page: 5 task file registers s/b fields [this is how they are defined in ATA8-ACS] WDC 9 Page: 6 bits, divided s/b bits divided WDC 10 Page: 6 domain, communicated s/b domain communicated WDC 11 Page: 7 from a peer higher layer state machine. s/b from a peer higher layer state machine in a different SCSI device. WDC 12 Page: 10 end to s/b end and to WDC 13 Page: 10 value. s/b value (see Annex E). WDC 14 Page: 10 that exists [Delete these words here or add them in the other nexus definitions.] WDC 15 Page: 11 device, or s/b device or WDC 16 Page: 11 interleaved with OOB burst (see 3.1.153). [Delete the unnecessary words.] WDC 17 Page: 11 from a peer higher layer state machine. s/b from a peer higher layer state machine in a different SCSI device. WDC 18 Page: 11 random, (RJ): s/b random (RJ): WDC 19 Page: 13 Global task s/b command [as based on the most recent changes in SAM-4] WDC 20 Page: 15 server, as s/b server as WDC 21 Page: 19 it s/b that the phy WDC 22 Page: 19 it s/b that the phy WDC 23 Page: 21 server, as s/b server as WDC 24 Page: 22 (1.5 s/b (i.e., 1.5 WDC 25 Page: 22 (3 s/b (i.e., 3 WDC 26 Page: 22 (6 s/b (i.e., 6 WDC 27 Page: 22 (1.5 s/b (i.e., 1.5 WDC 28 Page: 22 (1.5 s/b (i.e., 1.5 WDC 29 Page: 22 (3 s/b (i.e., 3 WDC 30 Page: 22 (3 s/b (i.e., 3 WDC 31 Page: 22 (10 s/b (i.e., 10 WDC 32 Page: 22 (cycles s/b (i.e., cycles WDC 33 Page: 22 (10 s/b (i.e., 10 WDC 34 Page: 23 (10 s/b (i.e., 10 WDC 35 Page: 23 (10 s/b (i.e., 10 WDC 36 Page: 23 (10 s/b (i.e., 10 WDC 37 Page: 23 (10 s/b (i.e., 10 WDC 38 Page: 23 (10 s/b (i.e., 10 WDC 39 Page: 23 (10 s/b (i.e., 10 WDC 40 Page: 23 (10 s/b (i.e., 10 WDC 41 Page: 23 (10 s/b (i.e., 10 WDC 42 Page: 23 (10 s/b (i.e., 10 WDC 43 Page: 23 (10 s/b (i.e., 10 WDC 44 Page: 24 s second (unit of time) s/b [This is a problematic abbreviation because oso is used in so many places in the draft as something like osource zone groupo. I could find only two places where oso is used in the draft to mean osecondo. Search for ogigasymbols/so and look in the table defining LED behavior. Because of this problematic nature, I recommend deleting this definition and replacing the occurrences of where oso is used to mean osecondo by using the words osecondo or osecondso as appropriate.] WDC 45 Page: 25 (Delta) s/b (i.e., Delta) WDC 46 Page: 25 (phi) s/b (i.e., phi) WDC 47 Page: 25 (pi) s/b (i.e., pi) WDC 48 Page: 25 (rho) s/b (i.e., rho) WDC 49 Page: 25 preference (equivalent to omay or may noto). s/b preference. oMayo is synonymous with the phrase omay or may noto. [see SAM-4] WDC 50 Page: 25 preference (equivalent to omay or may noto). s/b preference. oMay noto is synonymous with the phrase omay or may noto. [see SAM-4] WDC 51 Page: 26 alternative (equivalent to ois strongly recommendedo). s/b alternative. oShouldo is used in cases where the defined instance is strongly recommended. WDC 52 Page: 27 Lists s/b [Expand this paragraph to something more like the example shown in the SCSI style guide.] WDC 53 Page: 31 Figure 9 u State machine conventions s/b [Fix the squiggly lines on the right hand side of both inner boxes in the figure.] WDC 54 Page: 31 label, a s/b label, and may include a WDC 55 Page: 32 If the state transition leaves the page, the transition label goes to or from a state designator label with double underlines rather than to or from a state. s/b If a state transition shown in one figure goes to or comes from a state machine or state in a different figure, then the state machine name or state designator label is shown in the first figure including the state machine name or state designator label with double underlines. WDC 56 Page: 32 fully s/b [Delete the unnecessary word.] WDC 57 Page: 32 wholly s/b [Delete the unnecessary word.] WDC 58 Page: 32 it s/b then the state machine WDC 59 Page: 32 as a state machine arguments s/b [Delete the unnecessary words.] WDC 60 Page: 32 an argument s/b one or more state machine arguments WDC 61 Page: 32 the s/b an WDC 62 Page: 32 the s/b an WDC 63 Page: 32 s/b that argument WDC 64 Page: 32 the s/b an WDC 65 Page: 33 rows, with s/b rows with WDC 66 Page: 33 bit 31 and s/b bit 31, and WDC 67 Page: 33 left and s/b left, and WDC 68 Page: 35 simultaneously s/b at the same time WDC 69 Page: 40 there are more than one s/b there is more than one [I read it on the internet.] WDC 70 Page: 45 Each expander device contains one SMP target port and one management device server, contains one SMP initiator port and one management application client if it is self-configuring and may contain one SMP initiator port and one management application client if it is not self-configuring, and may contain SAS devices (e.g., an expander device may include an SSP target port for access to a logical unit with a peripheral device type set to 0Dh (i.e., enclosure services device) (see SPC-4 and SES-2)). s/b Each expander device: a) contains one SMP target port and one management device server; b) contains one SMP initiator port and one management application client, if the expander device is self-configuring; c) may contain one SMP initiator port and one management application client, if the expander device is not self-configuring; and d) may contain SAS devices (e.g., an expander device may include an SSP target port for access to a logical unit with a peripheral device type set to 0Dh (i.e., enclosure services device) (see SPC-4 and SES-2)). WDC 71 Page: 46 contain s/b also contain WDC 72 Page: 46 with s/b containing WDC 73 Page: 51 Global directly attached to a SAS target phy with a non-multiplexed physical link s/b attached to a SAS target phy via a non-multiplexed physical link (i.e., without any expander devices in the service delivery subsystem) [It might be best to put odirectly attachedo in the definitions clause. These terms are used often, and never clearly defined.] WDC 74 Page: 51 OPEN address frame s/b OPEN address frame (see [insert cross reference]) from a phy attempting to establish a connection (i.e., the source phy) WDC 75 Page: 51 destination phy s/b phy with which the source phy is attempting to establish a connection (i.e., the destination phy), WDC 76 Page: 51 OPEN_ACCEPT s/b OPEN_ACCEPT (see [insert cross reference]) transmitted from the destination phy WDC 77 Page: 51 through the connection request. s/b during the connection request (i.e., the connection rate value contained in the OPEN address frame)a WDC 78 Page: 52 Additionally s/b In addition: WDC 79 Page: 52 simultaneously s/b at the same time WDC 80 Page: 54 Global Ignored by SAS target ports. s/b SAS target ports shall ignore this primitive (i.e., a target port shall process the primitive the same as a deletable primitive). [There are several places in this table where it is defined that a port shall ignore a primitive when what is meant is that the port shall process the primitive the same as a deletable primitive. There are several solutions: a) add the oi.e.o as in this recommended change for each occurrence; b) replace oignoredo with oprocess the same as a deletable primitiveo; or c) add the keyword oignoredo and define it as oprocess the same as a deletable primitiveo. Item (b) is probably the safest as you wouldn't know how or where else oignoredo may be used without a big search, and item (b) would require fewer words overall.] WDC 81 Page: 54 temporarily going to have reduced s/b reducing WDC 82 Page: 55 it s/b that the device WDC 83 Page: 57 identifier or OUI) s/b identifier, or OUI) WDC 84 Page: 69 machine s s/b machines WDC 85 Page: 71 it shall be considered a reset event and initiate a hard reset of the port containing that phy. s/b then this shall be considered a reset event, and the port containing the phy shall process a hard reset. WDC 86 Page: 71 to the s/b to be sent to the WDC 87 Page: 71 it s/b the SAS port WDC 88 Page: 72 10.2.5) and s/b 10.2.5), and WDC 89 Page: 72 it reestablishes communication. s/b the initiator port next establishes a connection with that target port. WDC 90 Page: 72 expander s/b an expander WDC 91 Page: 72 expander s/b an expander WDC 92 Page: 72 Broadcast s/b a Broadcast WDC 93 Page: 74 source s/b [Delete this word, as the phy with the higher physical rate may be either the source or destination phy.] WDC 94 Page: 74 destination [Delete this word, as the phy with the higher physical rate may be either the source or destination phy.] WDC 95 Page: 74 destination s/b receiving WDC 96 Page: 78 specifically s/b [Delete the unnecessary word.] WDC 97 Page: 78 specifically s/b [Delete the unnecessary word.] WDC 98 Page: 80 specifically s/b [Delete the unnecessary word.] WDC 99 Page: 82 direct s/b a direct WDC 100 Page: 82 table s/b a table WDC 101 Page: 82 subtractive s/b a subtractive WDC 102 Page: 82 they s/b the phys in the expander device WDC 103 Page: 85 going to temporarily have reduced s/b reducing WDC 104 Page: 85 it s/b then the expander device WDC 105 Page: 85 it s/b the expander device WDC 106 Page: 86 to s/b with WDC 107 Page: 86 10.4.3.4) it s/b 10.4.3.4), then the management application client WDC 108 Page: 88 it s/b the result of the process WDC 109 Page: 88 all previously valid SAS addresses shall continue to be routable until they are determined to be no longer valid. s/b the expander device continues to be able to route requests to and responses from all SAS addresses in the expander's route table until the addresses are determined to no longer be valid. WDC 110 Page: 88 all unaffected SAS addresses shall continue to be routable. s/b the expander device continues to be able to route requests to and responses from all SAS addresses in the expander's route table that were not affected by the change.. WDC 111 Page: 89 it s/b then the management application client WDC 112 Page: 90 it s/b then the management application client WDC 113 Page: 90 it s/b then the management application client WDC 114 Page: 90 it s/b then the management application client WDC 115 Page: 90 it s/b that the management application client WDC 116 Page: 91 attached) and s/b attached), and WDC 117 Page: 92 the phy s/b a phy WDC 118 Page: 92 the phy s/b a phy WDC 119 Page: 92 repeat s/b be repeated WDC 120 Page: 102 Global physical presence is asserted [This is the first occurrence of this phrase, and it is used many times, particularly in clause 10. However, there is no definition for this phrase, and it is not possible to determine its meaning from the context. It is recommended that this phrase be defined in the definitions clause or replaced throughout the draft.] WDC 121 Page: 92 it s/b the zone manager WDC 122 Page: 103 or it s/b , or the zone manager WDC 123 Page: 104 while zoning is disabled and there is no power loss and no expander device reduced functionality (see 4.6.8). s/b while: a) zoning is disabled; b) no power loss occurs; and c) there is no reduction in expander device functionality (see 4.6.8). WDC 124 Page: 104 that the phy is attached to an end device, an expander device that does not support zoning, or a zoning expander device with zoning disabled, or a zoning expander device with zoning enabled that is outside the ZPSDS (i.e., is in another ZPSDS). s/b that: a) the phy is attached to an end device; b) the expander device does not support zoning; c) the expander device supports zoning, but zoning is disabled; or d) the expander device supports zoning, zoning is enabled, but the expander device is outside the ZPSDS (i.e., is in another ZPSDS). WDC 125 Page: 105 thus s/b [Delete the unnecessary word.] WDC 126 Page: 106 between s/b among [The rule is: use obetweeno for two items or more than two specified items (i.e., obetween phy a, phy b, and phy co), otherwise, for more than two unspecified items, oamongo is used.] WDC 127 Page: 106 between s/b among WDC 128 Page: 106 between s/b among WDC 129 Page: 107 that s/b whether or not WDC 130 Page: 107 it s/b then the zoning expander device WDC 131 Page: 108 phys s/b source and destination phys WDC 132 Page: 109 permitted and s/b permitted, and WDC 133 Page: 109 phys s/b source and destination phys WDC 134 Page: 113 manager and s/b manager, and WDC 135 Page: 114 successful and s/b successful, and WDC 136 Page: 114 devices and s/b devices, and WDC 137 Page: 114 response: s/b response as follows: WDC 138 Page: 114 it s/b the locked zoning expander WDC 139 Page: 114 it s/b the active zone manager WDC 140 Page: 114 it s/b the active zone manager WDC 141 Page: 115 expires and s/b expires, and WDC 142 Page: 115 fails then s/b fails, then WDC 143 Page: 115 it s/b the active zone manager WDC 144 Page: 115 it s/b the zoning expander device WDC 145 Page: 115 it s/b the active zone manager WDC 146 Page: 115 it s/b the active zone manager WDC 147 Page: 115 it s/b the active zone manager WDC 148 Page: 116 command s/b command (see SPC-4) WDC 149 Page: 116 it s/b the application client WDC 150 Page: 116 them s/b the events and peak values WDC 151 Page: 117 count/record s/b count and record WDC 152 Page: 117 least recently recorded s/b oldest WDC 153 Page: 121 Global SAS Drive cable, SAS Drive backplane, s/b SAS device cable, SAS device backplane [These terms came into the SAS 1.1 standard during the letter ballot process, rev 09c to be exact. I'm not aware of: a) why this became oDriveo in the first place; and b) the rationale for calling these oDriveo -- especially capitalized -- when none of the other related terms are capitalized. These terms -- especially SAS Drive backplane receptacle are counter intuitive. My recommended change is consistent with standard SCSI naming conventions.] WDC 154 Page: 144 assembly s/b assemblies WDC 155 Page: 144 assembly s/b assemblies WDC 156 Page: 145 SAS s/b assemblies with SAS WDC 157 Page: 146 Mini s/b assemblies with Mini WDC 158 Page: 146 a SAS s/b assemblies with a SAS WDC 159 Page: 146 a SAS s/b assemblies with a SAS WDC 160 Page: 146 a Mini s/b assemblies with a Mini WDC 161 Page: 156 SAS s/b assemblies with a SAS WDC 162 Page: 156 Mini s/b assemblies with a Mini WDC 163 Page: 157 and Mini s/b and a Mini WDC 164 Page: 157 SAS s/b assemblies with a SAS WDC 165 Page: 168 shows how two s/b how sets of two WDC 166 Page: 169 5.2.3.2.1.3), where s/b 5.2.3.2.1.3) where WDC 167 Page: 170 It s/b The figure WDC 168 Page: 171 are measured, but s/b may be measured but WDC 169 Page: 190 and consequently in s/b and, as a result, in WDC 170 Page: 198 Additionally s/b In addition WDC 171 Page: 203 can be s/b is WDC 172 Page: 203 must s/b shall WDC 173 Page: 206 can s/b is WDC 174 Page: 206 and consequently in s/b and, as a result, in WDC 175 Page: 206 10-12 and s/b 10-12, and WDC 176 Page: 207 if supported s/b if SSC is supported WDC 177 Page: 208 it s/b the phy WDC 178 Page: 208 specific, but s/b specific but WDC 179 Page: 208 and consequently in s/b and, as a result, in WDC 180 Page: 209 it s/b a SAS device or expander device WDC 181 Page: 210 table 79 to hold s/b table 79. This buffer holds WDC 182 Page: 213 separately on s/b for WDC 183 Page: 213 serially [Delete the redundant word.] WDC 184 Page: 213 and easily recognizable [Delete the redundant words.] WDC 185 Page: 213 pattern called a comma pattern which s/b pattern, called a comma pattern, which WDC 186 Page: 213 It s/b This subclause WDC 187 Page: 213 bits A, B, C, D, E, F, G, H and s/b bits, A, B, C, D, E, F, G, and H, and WDC 188 Page: 213 h, j s/b h, and j WDC 189 Page: 213 byte and s/b byte, and WDC 190 Page: 214 (Z s/b (i.e., Z WDC 191 Page: 214 (Z s/b (i.e., Z WDC 192 Page: 214 It s/b This subclause WDC 193 Page: 215 columns that represent two (not necessarily different) characters, corresponding to the current value of the running disparity (current RD - or current RD +). RD is a binary parameter with a negative (-) or positive (+) value. s/b columns that define the character to be transmitted based on the current running disparity (i.e., current RD - or current RD +). WDC 194 Page: 223 order in s/b order shown in WDC 195 Page: 226 not transmit OOB bursts consisting of ALIGN [0] primitives. s/b be required to transmit OOB bursts consisting of D24.3 characters. WDC 196 Page: 236 (i.e., host and device) s/b [Delete these words. Host and device have no meaning for SAS speed negotiation.] WDC 197 Page: 239 it s/b then the phy WDC 198 Page: 239 it s/b then the phy WDC 199 Page: 239 it s/b then the phy WDC 200 Page: 239 it s/b then the phy WDC 201 Page: 239 it s/b then the phy WDC 202 Page: 240 it s/b then the phy WDC 203 Page: 252 setting and s/b setting, and WDC 204 Page: 253 it s/b then the phy WDC 205 Page: 253 it s/b then the phy WDC 206 Page: 253 it s/b then the phy WDC 207 Page: 253 it s/b then the phy WDC 208 Page: 253 similarly s/b also WDC 209 Page: 255 from the SMP PHY CONTROL function requesting a phy operation of LINK RESET or HARD RESET in an expander device); s/b as the result of the management application layer in an expander device receiving an SMP PHY CONTROL function requesting a phy operation of LINK RESET or HARD RESET); WDC 210 Page: 256 it s/b the SP state machine WDC 211 Page: 257 it s/b the SP receiver WDC 212 Page: 262 it s/b then this state WDC 213 Page: 263 states, in s/b states in WDC 214 Page: 263 and performs s/b and the states in the state machine perform WDC 215 Page: 266 receiving s/b this state receives WDC 216 Page: 267 receiving s/b this state receives WDC 217 Page: 267 receiving s/b this state receives WDC 218 Page: 267 message, or s/b message or WDC 219 Page: 267 other s/b attached WDC 220 Page: 267 other s/b attached WDC 221 Page: 268 receiving s/b this state receives WDC 222 Page: 268 message, or after receiving s/b message or after this state receives WDC 223 Page: 268 receiving s/b this state receives WDC 224 Page: 268 message, or after receiving s/b message or after this state receives WDC 225 Page: 269 after: s/b after this state receives: WDC 226 Page: 269 receiving [Delete this word based on the above change.] WDC 227 Page: 269 receiving [Delete this word based on the above change.] WDC 228 Page: 269 receiving [Delete this word based on the above change.] WDC 229 Page: 269 may but [Delete the redundant words.] WDC 230 Page: 269 receiving s/b this state receives WDC 231 Page: 269 message, or s/b message or WDC 232 Page: 269 receiving s/b this state receives WDC 233 Page: 270 receiving s/b this state receives WDC 234 Page: 270 receiving s/b this state receives WDC 235 Page: 271 receiving s/b this state receives WDC 236 Page: 272 after: s/b after this state receives: WDC 237 Page: 272 receiving [Delete this word based on the above change.] WDC 238 Page: 272 receiving [Delete this word based on the above change.] WDC 239 Page: 272 This is a phy reset problem. s/b [Delete the editorial comment.] WDC 240 Page: 272 phy, initiating s/b phy initiating WDC 241 Page: 272 SATA; expander s/b SATA. Expander WDC 242 Page: 274 receiving s/b this state receives WDC 243 Page: 274 receiving s/b this state receives WDC 244 Page: 274 receiving s/b this state receives WDC 245 Page: 274 receiving s/b this state receives WDC 246 Page: 274 receiving s/b this state receives WDC 247 Page: 275 receiving s/b this state receives WDC 248 Page: 275 receiving s/b this state receives WDC 249 Page: 275 receiving s/b this state receives WDC 250 Page: 275 receiving s/b this state receives WDC 251 Page: 276 brought up successfully s/b established WDC 252 Page: 276 after: s/b after this state receives: WDC 253 Page: 276 receiving [Delete this word based on the above change.] WDC 254 Page: 276 receiving [Delete this word based on the above change.] WDC 255 Page: 276 receiving [Delete this word based on the above change.] WDC 256 Page: 276 may but s/b [Delete redundant words.] WDC 257 Page: 276 message, or s/b message or WDC 258 Page: 276 receiving s/b this state receives WDC 259 Page: 276 receiving s/b this state receives WDC 260 Page: 276 receiving s/b this state receives WDC 261 Page: 276 receiving s/b this state receives WDC 262 Page: 276 receiving s/b this state receives WDC 263 Page: 277 receiving s/b this state receives WDC 264 Page: 277 receiving s/b this state receives WDC 265 Page: 277 receiving s/b this state receives WDC 266 Page: 278 effectively [Delete the unnecessary word.] WDC 267 Page: 278 it requires two valid dwords to nullify its effect. When four invalid dwords are detected without nullification, dword synchronization is considered lost. s/b receipt of two valid dwords is required to nullify the effect of receiving the invalid dword. When four invalid dwords in a row are detected, dword synchronization is considered lost. WDC 268 Page: 281 it s/b the SP_DWS receiver WDC 269 Page: 281 it s/b the SP_DWS receiver WDC 270 Page: 281 it s/b the SP_DWS receiver WDC 271 Page: 281 it s/b the SP_DWS receiver WDC 272 Page: 281 it s/b the SP_DWS receiver WDC 273 Page: 281 receiver. and s/b receiver, and WDC 274 Page: 281 :Valid2 and s/b :Valid2, and WDC 275 Page: 281 chooses to initiate s/b initiates WDC 276 Page: 281 receiving s/b receives WDC 277 Page: 281 sending s/b this state sends WDC 278 Page: 281 receiving s/b this state receives WDC 279 Page: 282 receiving s/b this state receives WDC 280 Page: 282 receiving s/b this state receives WDC 281 Page: 282 receiving s/b this state receives WDC 282 Page: 282 might s/b may WDC 283 Page: 282 sending s/b this state sends WDC 284 Page: 282 receiving s/b this state receives WDC 285 Page: 282 sending s/b this state sends WDC 286 Page: 282 receiving s/b this state receives WDC 287 Page: 283 receiving s/b this state receives WDC 288 Page: 283 sending s/b this state sends WDC 289 Page: 283 receiving s/b this state receives WDC 290 Page: 283 receiving s/b this state receives WDC 291 Page: 283 sending s/b this state sends WDC 292 Page: 283 receiving s/b this state receives WDC 293 Page: 283 receiving s/b this state receives WDC 294 Page: 283 sending s/b this state sends WDC 295 Page: 284 receiving s/b this state receives WDC 296 Page: 284 receiving s/b this state receives WDC 297 Page: 284 sending s/b this state sends WDC 298 Page: 284 receiving s/b this state receives WDC 299 Page: 284 sending s/b this state sends WDC 300 Page: 285 it s/b then the phy WDC 301 Page: 286 it s/b the phy WDC 302 Page: 286 it s/b then the phy WDC 303 Page: 286 spin-up s/b activate its spindle motor WDC 304 Page: 286 it s/b then the SAS target device WDC 305 Page: 286 device receives s/b device containing a spindle motor for rotating medium WDC 306 Page: 286 spin-up s/b spindle motor activation WDC 307 Page: 286 need to s/b [Delete unnecessary words.] WDC 308 Page: 298 simply [Delete the unnecessary word.] WDC 309 Page: 300 dwords. s/b dwords after deletable primitives are deleted. WDC 310 Page: 300 dwords. s/b dwords after deletable primitives are deleted. WDC 311 Page: 302 it s/b transmission of a MUX WDC 312 Page: 302 they s/b the MUXs WDC 313 Page: 303 it s/b transmission of a NOTIFY WDC 314 Page: 303 it s/b the NOTIFY WDC 315 Page: 303 it s/b then the phy WDC 316 Page: 303 into s/b to WDC 317 Page: 303 an SAS s/b a SAS [it is interesting to me that this is the only remnant occurrence of this] WDC 318 Page: 303 spinning-up s/b spinning up WDC 319 Page: 303 SPC-4) and/or s/b SPC-4), and/or WDC 320 Page: 303 They shall transmit one NOTIFY (ENABLE SPINUP) after power on when the enclosure is ready for initial spin-up. After the initial NOTIFY (ENABLE SPINUP), they shall transmit NOTIFY (ENABLE SPINUP) periodically. s/b SAS initiator devices or expander devices shall transmit one NOTIFY (ENABLE SPINUP) after power on when the enclosure is ready for an SSP target device to consume additional power. After transmitting the initial NOTIFY (ENABLE SPINUP), SAS initiator devices and expander devices shall transmit NOTIFY (ENABLE SPINUP) periodically (e.g., once every several milliseconds). WDC 321 Page: 304 I_T nexus loss, logical unit reset, and hard reset shall not cause a SAS target device to spin-up automatically on receipt of NOTIFY (ENABLE SPINUP). s/b If a SAS target device is in the Stopped power condition state (see x.x), then the device shall not transition from the Stopped state (e.g., start the device's spindle motor) after an I_T nexus loss, logical unit reset, or hard reset until the device has received both a START STOP UNIT command with the START bit set to one and a NOTIFY (ENABLE SPINUP). WDC 322 Page: 304 from all s/b received on any of WDC 323 Page: 304 honor s/b process a WDC 324 Page: 304 equivalently [Delete the unnecessary word.] WDC 325 Page: 304 two SSP target ports A and B, s/b SSP target port A and SSP target port B, WDC 326 Page: 304 reached then s/b reached, then WDC 327 Page: 304 layer that s/b layer in the SAS target device WDC 328 Page: 307 it s/b the expander device WDC 329 Page: 307 request and s/b request, and WDC 330 Page: 308 exists but s/b exists, but WDC 331 Page: 308 exists but s/b exists, but WDC 332 Page: 308 it s/b the STP target port WDC 333 Page: 309 phy and s/b phy, and WDC 334 Page: 310 credit is s/b RRDYs are WDC 335 Page: 310 to close s/b during WDC 336 Page: 312 it s/b the expander device WDC 337 Page: 313 it s/b the input clock frequency WDC 338 Page: 313 slightly s/b [Delete the unnecessary word.] WDC 339 Page: 313 To solve this problem, s/b In order to solve the problems of overruns and underruns, WDC 340 Page: 315 It s/b An expander device WDC 341 Page: 315 that number based s/b the number of deletable primitives transmitted based WDC 342 Page: 315 It s/b An expander device WDC 343 Page: 315 forwarding to s/b forwarding dwords to WDC 344 Page: 315 it s/b the expander device WDC 345 Page: 315 It s/b An expander device WDC 346 Page: 315 It s/b The STP target port WDC 347 Page: 320 open and s/b open, and WDC 348 Page: 325 Address frames shall not be terminated early. s/b When an address frame is transmitted, the number of data dwords defined for the frame shall be transmitted. WDC 349 Page: 331 and should s/b and the process should WDC 350 Page: 331' it s/b the SAS target port WDC 351 Page: 331 Each time a connection request with a connection rate greater than 1.5 Gbps results in OPEN_REJECT (CONNECTION RATE NOT SUPPORTED), s/b Each time a SAS port receives an OPEN_REJECT (CONNECTION RATE NOT SUPPORTED) in response to a connection request including a connection rate greater than 1.5 Gbps, WDC 352 Page: 332 it s/b the SAS port WDC 353 Page: 332 field be s/b field to be WDC 354 Page: 332 it s/b the SAS initiator port WDC 355 Page: 332 port, and s/b port and WDC 356 Page: 335 it shall be considered a reset event and cause s/b then this shall be considered a reset event, and the phy shall cause WDC 357 Page: 335 it s/b then the phy WDC 358 Page: 336 it s/b the expander device WDC 359 Page: 336 are s/b is WDC 360 Page: 341 layer, and s/b layer and WDC 361 Page: 341 it s/b this state WDC 362 Page: 341 it s/b this state WDC 363 Page: 342 it s/b the primitive WDC 364 Page: 342 it s/b the expander device WDC 365 Page: 342 it s/b the expander device WDC 366 Page: 342 each expander port s/b each of its expander ports WDC 367 Page: 343 for orderly closing a connection s/b to close a connection in a normal manner. WDC 368 Page: 344 it s/b the phy WDC 369 Page: 344 it s/b the expander device WDC 370 Page: 344 it s/b the expander device WDC 371 Page: 346 it s/b the phy WDC 372 Page: 346 it s/b the expander device WDC 373 Page: 346 it s/b the source phy WDC 374 Page: 346 it s/b the SAS port WDC 375 Page: 346 it s/b the SAS port WDC 376 Page: 346 it s/b the SAS port WDC 377 Page: 346 it s/b the expander port WDC 378 Page: 346 it s/b the expander port WDC 379 Page: 347 it s/b the SAS port WDC 380 Page: 347 it s/b the timer WDC 381 Page: 347 it s/b the SAS port WDC 382 Page: 347 it s/b the timer WDC 383 Page: 347 conclusively s/b [Delete the unnecessary word.] WDC 384 Page: 347 it s/b the timer WDC 385 Page: 347 it s/b the timer WDC 386 Page: 347 it s/b the SAS port WDC 387 Page: 347 it s/b the timer WDC 388 Page: 347 it s/b the SAS port WDC 389 Page: 347 it s/b the expander phy WDC 390 Page: 347 it s/b the expander phy WDC 391 Page: 348 s/b the ECM WDC 392 Page: 348 it s/b the ECM WDC 393 Page: 348 it s/b the ECM WDC 394 Page: 349 it s/b the ECM WDC 395 Page: 349 contend and s/b contend, and WDC 396 Page: 349 contend and s/b contend, and WDC 397 Page: 350 the following Arb Reject confirmation s/b one of the following Arb Reject confirmations WDC 398 Page: 350 met and s/b met, and WDC 399 Page: 350 it s/b the expander device WDC 400 Page: 350 it s/b the expander device WDC 401 Page: 350 and s/b an WDC 402 Page: 351 it s/b the expander device WDC 403 Page: 351 it s/b the device WDC 404 Page: 352 it chooses to abort its s/b the phy aborts the WDC 405 Page: 352 it s/b the phy WDC 406 Page: 353 it s/b the expander device WDC 407 Page: 353 it s/b the expander device WDC 408 Page: 354 it s/b the phy WDC 409 Page: 355 connection, in s/b connection in WDC 410 Page: 355 it s/b the phy WDC 411 Page: 357 It shall insert deletable primitives whenever it underflows. s/b An expander phy shall insert deletable primitives whenever an underflow condition occurs. WDC 412 Page: 361 it s/b the SL transmitter WDC 413 Page: 355 frames and determine if the received address frame is an OPEN address frame and whether or not it was received successfully. s/b frames, determine if the received address frame is an OPEN address frame, and determine whether or not the frame was received without error. WDC 414 Page: 364 a SSP s/b an SSP WDC 415 Page: 365 received this s/b received, then this WDC 416 Page: 366 a SSP s/b an SSP WDC 417 Page: 367 transmitter, it s/b transmitter, then this state WDC 418 Page: 368 a SSP s/b an SSP WDC 419 Page: 368 Connection then s/b Connection, then WDC 420 Page: 368 Connection then s/b Connection, then WDC 421 Page: 368 Connection then s/b Connection, then WDC 422 Page: 368 state, but s/b state but WDC 423 Page: 368 a SSP s/b an SSP WDC 424 Page: 369 a SSP s/b an SSP WDC 425 Page: 369 message or s/b message, or WDC 426 Page: 369 message and s/b message, and WDC 427 Page: 369 a SSP s/b an SSP WDC 428 Page: 370 received and s/b received, and WDC 429 Page: 370 message and s/b message, and WDC 430 Page: 370 a SSP s/b an SSP WDC 431 Page: 376 received and s/b received, and WDC 432 Page: 379 received or s/b received, or WDC 433 Page: 379 dword except s/b dword, except WDC 434 Page: 381 g) s/b [Delete the extra list item designator.) WDC 435 Page: 382 received this s/b received, then this WDC 436 Page: 382 received or s/b received, or WDC 437 Page: 382 received or s/b received, or WDC 438 Page: 382 received or s/b received, or WDC 439 Page: 382 received or s/b received, or WDC 440 Page: 385 connection if there is one and s/b connection, if there is one, and WDC 441 Page: 385 connection if there is one and s/b connection, if there is one, and WDC 442 Page: 385 received and s/b received, and WDC 443 Page: 386 it s/b the SSP phy WDC 444 Page: 386 needs s/b requires WDC 445 Page: 386 needs s/b requires WDC 446 Page: 386 it s/b the SSP phy WDC 447 Page: 386 open and s/b open, and WDC 448 Page: 387 it needs to transmit a frame itself s/b the SSP initiator port has a frame to transmit WDC 449 Page: 387 It s/b An SSP initiator port WDC 450 Page: 387 it needs to transmit a frame itself s/b the SSP target port has a frame to transmit WDC 451 Page: 387 it s/b the frame WDC 452 Page: 388 an SSP initiator phy could be transmitting s/b it is permissible for an SSP initiator phy to transmit WDC 453 Page: 388 it s/b the SSP phy WDC 454 Page: 388 it s/b that the SSP phy WDC 455 Page: 389 it s/b the transmitter WDC 456 Page: 389 it s/b the phy WDC 457 Page: 390 a SSP s/b an SSP WDC 458 Page: 390 states the s/b states, then the WDC 459 Page: 394 The SSP receiver s/b An SSP receiver's WDC 460 Page: 394 The SSP transmitter s/b An SSP transmitter's WDC 461 Page: 396 the s/b a WDC 462 Page: 396 the s/b a WDC 463 Page: 396 received and s/b received, and WDC 464 Page: 396 received and s/b received, and WDC 465 Page: 396 received and s/b received, and WDC 466 Page: 396 received this s/b received, this WDC 467 Page: 396 slightly [Delete the unnecessary word.] WDC 468 Page: 397 received this s/b received, then this Page: 397 received this s/b received, then this WDC 469 Page: 397 received this s/b received, then this WDC 470 Page: 398 NOTE 76 - s/b [All of the font in this note should be changed to the proper size.] WDC 471 Page: 398 received this s/b received, this WDC 472 Page: 401 message it s/b message, this state machine WDC 473 Page: 401 message it s/b message, this state machine WDC 474 Page: 401 message it s/b message, then this state machine WDC 475 Page: 401 message it s/b message, this state machine WDC 476 Page: 401 message it s/b message, this state machine WDC 477 Page: 401 message it s/b message, this state machine WDC 478 Page: 401 argument it s/b argument, this state machine WDC 479 Page: 402 frame and its STP flow control buffer begins to fill up, it s/b frame, and the flow control buffer in the STP phy or expander phy begins to fill up, the phy WDC 480 Page: 402 it s/b the STP phy or expander phy WDC 481 Page: 402 it s/b the STP phy or expander phy WDC 482 Page: 402 it s/b the STP phy or expander phy WDC 483 Page: 402 it s/b the STP phy or expander phy WDC 484 Page: 402 it s/b the SATA host phy WDC 485 Page: 402 It s/b The SATA host phy WDC 486 Page: 402 it s/b the phy WDC 487 Page: 402 it s/b the phy WDC 488 Page: 402 it s/b the SATA host phy WDC 489 Page: 405 it s/b the STP initiator phy WDC 490 Page: 405 it s/b the second expander device WDC 491 Page: 405 it s/b the STP initiator phy WDC 492 Page: 405 (i.e., receivers are simply in the state of receiving the primitive) [Delete the gratuitous editorial comment, including the olyo adverb.] WDC 493 Page: 405 it s/b the incoming sequence WDC 494 Page: 406 it s/b the expander device WDC 495 Page: 405 it s/b the expander device WDC 496 Page: 405 It s/b The STP target port WDC 497 Page: 405 it s/b the STP target port WDC 498 Page: 405 it s/b the STP target port WDC 499 Page: 405 it s/b the STP target port WDC 500 Page: 405 drive s/b SATA device WDC 501 Page: 408 it s/b then the STP/SATA bridge WDC 502 Page: 408 it succeeds. s/b the FIS is received without error. WDC 503 Page: 408 it s/b then the STP/SATA bridge WDC 504 Page: 408 it s/b the STP/SATA bridge WDC 505 Page: 408 it s/b the STP/SATA bridge WDC 506 Page: 408 needs an outgoing connection request to be accepted s/b is attempting to establish a connection to transmit a FIS. WDC 507 Page: 408 it s/b the STP initiator port WDC 508 Page: 408 it s/b then the STP initiator port WDC 509 Page: 408 it s/b the STP target port WDC 510 Page: 410 it s/b the STP initiator port WDC 511 Page: 410 it s/b the STP target port WDC 512 Page: 413 directly [Delete the unnecessary word.] WDC 513 Page: 413 it s/b the SMP initiator phy WDC 514 Page: 419 port s/b phy WDC 515 Page: 420 h s/b [There are two possibilities here: either the PL_OC state machine may create a new Pending Tx Open for the Pending Tx Frame, or the state machine may send the appropriate Transmission Status confirmation (e.g., No Destination) to the transport layer. I've tried to describe this in the text below, but I'm not sure what to do with the arrows. Possibly there could be an arrow like the one on the right in the figure going the other way (i.e., to the transport layer) including the confirmation. I think this is all correctly defined in detail in 8.2.2.3.4.] WDC 516 Page: 420 machine sends s/b machine discards the Tx Open message and sends WDC 517 Page: 421 after the Reject To Open Limit timer, if any, has expired, and if there is a pending Tx Open slot available, s/b if there is a pending Tx Open slot available, and the Reject To Open Limit timer, if any, has expired, WDC 518 Page: 421 time. s/b time or send the appropriate Transmission Status confirmation (e.g., No Destination) to the transport layer. WDC 519 Page: 421 address; and s/b address based on transmit frame requests from the transport layer; and WDC 520 Page: 425 and s/b [Delete the extraneous word.] WDC 521 Page: 425 shall discard all pending Tx Frame messages and delete all I_T Nexus Loss timers and send a HARD_RESET Received confirmation to the transport layer. s/b shall: a) discard any pending Tx Frame messages; b) discard any pending Tx Open messages; c) delete any timers that are present in the state machine (i.e., I_T Nexus Loss timers, Arbitration Wait Time timers, and Reject To Open Limit timers); and d) send a HARD_RESET Received confirmation to the transport layer. WDC 522 Page: 425 a) discard all pending Tx Frame messages, if any; b) delete all I_T Nexus Loss timers, if any; c) send a Close Connection message to all the PL_PM state machines; d) send a Cancel Open message to all the PL_PM state machines; and e) send a Notify Received (Power Loss Expected) confirmation to the transport layer. s/b shall: a) discard any pending Tx Frame messages; b) discard any pending Tx Open messages; c) delete any timers that are present in the state machine (i.e., I_T Nexus Loss timers, Arbitration Wait Time timers, and Reject To Open Limit timers); d) send a Close Connection message to all of the PL_PM state machines; e) send a Cancel Open message to all of the PL_PM state machines; and f) send a Notify Received (Power Loss Expected) confirmation to the transport layer. WDC 523 Page: 428 messages s/b message WDC 524 Page: 430 open and s/b open, and WDC 525 Page: 430 it s/b this state WDC 526 Page: 431 it s/b this state WDC 527 Page: 440 it s/b this state WDC 528 Page: 442 parses s/b parse WDC 529 Page: 444 it s/b then the initiator port WDC 530 Page: 444 it s/b then the initiator port WDC 531 Page: 444 it s/b the initiator port WDC 532 Page: 445 it s/b the SSP target port WDC 533 Page: 445 it s/b the SSP target port WDC 534 Page: 445 this bit [Delete the unnecessary words.] WDC 535 Page: 445 already s/b [Delete the unnecessary word.] WDC 536 Page: 447 Global TASK PRIORITY s/b COMMAND PRIORITY WDC 537 Page: 447 address of the logical unit. s/b LUN of the logical unit addressed by the application client for the command. WDC 538 Page: 447 The TASK PRIORITY field specifies the relative scheduling of the task containing this command in relation to other tasks already in the task set, if the tasks have SIMPLE task attributes (see SAM-4). s/b If the TASK ATTRIBUTE field is set to SIMPLE (see table 166), then the COMMAND PRIORITY field specifies the relative scheduling importance of this command in relation to other commands having the SIMPLE task attribute that are already in the task set (see SAM-4). WDC 539 Page: 448 (four bytes) s/b (i.e., four bytes) WDC 540 Page: 449 address of the logical unit. s/b LUN of the logical unit addressed by the application client for the task management function. WDC 541 Page: 450 command and s/b command, and WDC 542 Page: 450 the s/b then the WDC 543 Page: 450 the value in the MAXIMUM BURST SIZE field (see 10.2.7.2.4). s/b the value in the MAXIMUM BURST SIZE field times 512 (see 10.2.7.2.4). WDC 544 Page: 450 a WRITE s/b a value in the WRITE WDC 545 Page: 452 CONDITION) and s/b CONDITION), and WDC 546 Page: 452 service s/b the service WDC 547 Page: 452 service s/b the service WDC 548 Page: 452 SSP s/b an SSP WDC 549 Page: 454 information or s/b information, or WDC 550 Page: 454 the s/b then the WDC 551 Page: 454 If it is not, the s/b If the value is not a multiple of four, then the WDC 552 Page: 455 the COMMAND frame could s/b it is permissible for the COMMAND frame to WDC 553 Page: 455 port. Or, they could all s/b port, or, all frames for the transaction may WDC 554 Page: 457 handled differently based on s/b processed in a different manner based on the setting of WDC 555 Page: 458 the SSP s/b the command specified a data-out operation and the SSP WDC 556 Page: 458 the SSP s/b the command specified a data-in operation and the SSP WDC 557 Page: 460 frames since s/b frames for that I_T_L_Q nexus since WDC 558 Page: 460 frames since s/b frames for that I_T_L_Q nexus since WDC 559 Page: 461 it s/b state machine WDC 560 Page: 461 it s/b the initiator port WDC 561 Page: 461 nexus, the s/b nexus, then the WDC 562 Page: 461 it considers the RESPONSE frame to be the valid RESPONSE frame. s/b the state machine processes the RESPONSE frame. WDC 563 Page: 462 disabled and s/b disabled, and WDC 564 Page: 462 9.2.6.2.3.3) and s/b 9.2.6.2.3.3), and WDC 565 Page: 462' expected, the s/b expected, then the WDC 566 Page: 462 (see 9.2.6.2.2.3) and s/b (see 9.2.6.2.2.3), and WDC 567 Page: 462 (see 9.2.6.2.2.3) and s/b (see 9.2.6.2.2.3), and WDC 568 Page: 462 (see 9.2.6.2.2.3) and s/b (see 9.2.6.2.2.3), and WDC 569 Page: 462 disabled and s/b disabled, and WDC 570 Page: 462 expected, the s/b expected, then the WDC 571 Page: 462 (see 9.2.6.2.3.7) and s/b (see 9.2.6.2.3.7), and WDC 572 Page: 462 task router and task manager(s) s/b task router or one of the task managers WDC 573 Page: 463 disabled and s/b disabled, and WDC 574 Page: 463 (see 9.2.6.3.3.6.1) and s/b (see 9.2.6.3.3.6.1), and WDC 575 Page: 463 expected, the s/b expected, then the WDC 576 Page: 463 (see 9.2.6.3.3.6.1) and s/b (see 9.2.6.3.3.6.1), and WDC 577 Page: 463 (see 9.2.6.3.3.6.1) and s/b (see 9.2.6.3.3.6.1), and WDC 578 Page: 464 The s/b Each WDC 579 Page: 466 data-out buffer size. s/b data-out buffer size (e.g., this value takes into account the value set in the MAXIMUM BURST SIZE field in the Disconnect-Reconnect mode page). WDC 580 Page: 466 operations and s/b operation, and WDC 581 Page: 467 XFER_RDY then s/b XFER_RDY, then WDC 582 Page: 467 DATA and s/b DATA, and WDC 583 Page: 467 RESPONSE then s/b RESPONSE, then WDC 584 Page: 467 correct and s/b correct, and WDC 585 Page: 467 state s/b state machine WDC 586 Page: 467 correct and s/b correct, and WDC 587 Page: 468 to ST_ITS s/b to the ST_ITS WDC 588 Page: 468 state s/b state machine WDC 589 Page: 469 defines the s/b defines each WDC 590 Page: 469 of receiving s/b of this state machine receiving WDC 591 Page: 469 that indicate s/b indicating that WDC 592 Page: 471 first bust s/b first burst WDC 593 Page: 472 and s/b plus WDC 594 Page: 474 sends s/b shall send WDC 595 Page: 477 If the number of bytes remaining to be transferred as defined by the following calculation: bytes remaining to be transferred = Write Data Length Xfer_Rdy state machine argument - (Data-Out Buffer Offset state machine argument - Requested Offset Xfer_Rdy state machine argument) is equal to the maximum size of the write Data information unit, then the amount of data shall be the maximum size of the write Data information unit. Otherwise, the amount of data shall be the lesser of: A) the bytes remaining to be transferred; and B) the maximum size of the Write information unit; s/b The number of bytes in the DATA field shall be less than or equal to the maximum number of bytes of the field. If the DATA frame does not contain the last data for the transfer, then the number of bytes contained in the DATA field shall be a multiple of four. If the DATA frame contains the last data for the transfer, then the number of bytes contained in the DATA field may not be a multiple of four. WDC 596 Page: 478 The number of bytes in the DATA field in the read Data information unit is zero. s/b a) The number of bytes in the DATA field in the read Data information unit is zero; or b) This is not the last DATA frame for the transfer and the NUMBER OF FILL BYTES field in the frame is not set to zero. WDC 597 Page: 484 request byte count; s/b request byte count (e.g., this value takes into account the value set in the MAXIMUM BURST SIZE field in the Disconnect-Reconnect mode page). WDC 598 Page: 494 If the Read Data Buffer End state machine variable minus the Read Data Offset state machine variable is equal to the maximum size of the read Data information unit, the amount of data shall be the maximum size of the read Data information unit. Otherwise, the amount of data shall be the lesser of: A) the Read Data Buffer End state machine variable minus the Read Data Offset state machine variable; and B) the maximum size of the read Data information unit for this Data-In request. s/b The number of bytes in the DATA field shall be less than or equal to the maximum number of bytes of the field. If the DATA frame does not contain the last data for the transfer, then the number of bytes contained in the DATA field shall be a multiple of four. If the DATA frame contains the last data for the transfer, then the number of bytes contained in the DATA field may not be a multiple of four. WDC 599 Page: 494 If the Read Data Buffer End state machine variable minus the Read Data Offset state machine variable is equal to the maximum size of the read Data information unit, the amount of data shall be the maximum size of the read Data information unit. Otherwise, the amount of data shall be the lesser of: A) the Read Data Buffer End state machine variable minus the Balance Point Read Data Offset state machine variable; and B) the maximum size of the read Data information unit for this Data-In request s/b The number of bytes in the DATA field shall be less than or equal to the maximum number of bytes of the field. If the DATA frame does not contain the last data for the transfer, then the number of bytes contained in the DATA field shall be a multiple of four. If the DATA frame contains the last data for the transfer, then the number of bytes contained in the DATA field may not be a multiple of four. WDC 600 Page: 495 If the Request Byte Count Data-In state machine argument is equal to the maximum size of the read Data information unit, the amount of data shall be the maximum size of the read Data information unit. Otherwise, the amount of data shall be the lesser of: A) the Request Byte Count Data-In state machine argument; and B) the maximum size of the read Data information unit for this Data-In request. s/b The number of bytes in the DATA field shall be less than or equal to the maximum number of bytes of the field. If the DATA frame does not contain the last data for the transfer, then the number of bytes contained in the DATA field shall be a multiple of four. If the DATA frame contains the last data for the transfer, then the number of bytes contained in the DATA field may not be a multiple of four. WDC 601 Page: 496 The number of bytes in the DATA field is zero. s/b a) The number of bytes in the DATA field in the read Data information unit is zero; or b) This is not the last DATA frame for the transfer and the NUMBER OF FILL BYTES field in the frame is not set to zero. WDC 602 Page: 499 it s/b the FIS WDC 603 Page: 500 Fill bytes s/b If required, fill bytes WDC 604 Page: 501 indicating s/b specifying WDC 605 Page: 501 Fill bytes s/b If required, fill bytes WDC 606 Page: 501 Fill bytes s/b If required, fill bytes WDC 607 Page: 502 returns s/b return WDC 608 Page: 502 layer and s/b layer, and WDC 609 Page: 504 a SMP s/b an SMP WDC 610 Page: 504 it s/b the frame WDC 611 Page: 505 a SMP s/b an SMP WDC 612 Page: 507 = Execute Command s/b Move all of the text after the equal sign to have the same indentation. WDC 613 Page: 507 Status) s/b Add [Status Qualifier] as an argument to the Execute Command oOUTo portion. WDC 614 Page: 509 Global initiator port to send s/b initiator port identifier (see table 9) of the SAS initiator port sending WDC 615 Page: 509 Global target port to which the COMMAND frame is to be sent; s/b target port identifier (see table 9) of the SAS target port to which the frame is sent WDC 616 Page: 509 Global Maximum of 2^32 s/b Maximum of 2^32 bytes WDC 617 Page: 510 its outstanding Receive Data-Out () calls s/b all outstanding Receive Data-Out () calls for the nexus WDC 618 Page: 510 its outstanding Send Data-In () calls have been responded to with Data-In Delivered () s/b outstanding Send Data-In () calls have been responded to with Data-In Delivered () calls for the nexus WDC 619 Page: 512 it s/b device server WDC 620 Page: 517 Global indirectly specifies the TAG field in the RESPONSE frame header. s/b I'm not sure what this means. Doesn't the Q odirectlyo specify something? WDC 621 Page: 521 If a mode page defined by this standard is not implemented, the value assumed for the functionality of each field in that mode page that is: a) allowed by this standard to be changeable; and b) is not used solely to define the mode page structure (e.g., the NUMBER OF PHYS field in the Phy Control And Discover mode page) or coordinate access to the mode page (e.g., the GENERATION CODE field in the Phy Control And Discover mode page), shall be zero (i.e., as if the mode page is implemented and the field is set to zero). [I recommend deleting this because I don't understand it at all. How can a field in a mode page that isn't implemented be changeable? How does a field define the mode page structure or coordinate access to the page? And, ultimately, though the conjunction has been omitted, the field shall be set to zero.] WDC 622 Page: 525 0Dh s/b 0Eh WDC 623 Page: 510 and set the Arbitration Wait Time timer to zero s/b and shall not set the Arbitration Wait Time timer to zero WDC 624 Page: 510 it s/b the SAS port WDC 625 Page: 526 that s/b when connection requests from the SSP target port WDC 626 Page: 526 recognizing s/b the SSP target port processes WDC 627 Page: 527 field values [Delete the redundant words.] WDC 628 Page: 527 the s/b the SAS-2 Phy mode page and the WDC 629 Page: 543 it s/b then the device server WDC 630 Page: 556 it s/b then the management device server WDC 631 Page: 557 Fill bytes s/b If the number additional request bytes is not a multiple of four, then fill bytes WDC 632 Page: 562 one but s/b one, but WDC 633 Page: 562 4.9.1) but s/b 4.9.1), but WDC 634 Page: 562 11b and s/b 11b, and WDC 635 Page: 566 Fill bytes s/b If the number additional request bytes is not a multiple of four, then fill bytes WDC 636 Page: 569 counts s/b contains WDC 637 Page: 569 it s/b then the management device server WDC 638 Page: 569 It s/b The management device server WDC 639 Page: 570 (i.e. returns OPEN_REJECT (NO DESTINATION)) s/b (i.e., the expander device returns OPEN_REJECT (NO DESTINATION) while the CONFIGURING bit is set to one) WDC 640 Page: 571 it s/b the management application client WDC 641 Page: 571 it s/b the management device server WDC 642 Page: 571 e.g. s/b i.e. [are there any other cases not listed?] WDC 643 Page: 571 number of zone groups s/b small caps WDC 644 Page: 576 (http://www.t10.org) s/b (i.e., at http://www.t10.org) WDC 645 Page: 576 component, as s/b component as WDC 646 Page: 576 unit (SKU)). s/b unit number (i.e, SKU)). WDC 647 Page: 576 (http://www.t10.org) s/b (i.e., at http://www.t10.org) WDC 648 Page: 576 server, as s/b server as WDC 649 Page: 576 server, as s/b server as WDC 650 Page: 579 it should start again s/b then the SMP initiator port should retrieve the frame again WDC 651 Page: 579 index, in ascending order wrapping from FFFFh to 0001h, that contains a valid descriptor. s/b index that contains a valid descriptor in ascending order wrapping from FFFFh to 0001h. WDC 652 Page: 579 order, wrapping from FFFFh to 0001h, based on the self-configuration status descriptor index. s/b order based on the self-configuration status descriptor index wrapping from FFFFh to 0001h. WDC 653 Page: 584 it should start s/b then the SMP initiator port should retrieve the frames WDC 654 Page: 584 returned, and s/b returned and WDC 655 Page: 585 asserted and s/b asserted, and WDC 656 Page: 587 field, defined in the ZONED BROADCAST request (see table 307 in 10.4.3.20), specifies s/b field defined in the ZONED BROADCAST request (see table 307 in 10.4.3.20) specifies WDC 657 Page: 588 field, for s/b field for WDC 658 Page: 588 field. s/b field in the descriptor. WDC 659 Page: 589 field, defined in the ZONED BROADCAST request (see table 308 in 10.4.3.20), indicates s/b field defined in the ZONED BROADCAST request (see table 308 in 10.4.3.20) indicates WDC 660 Page: 589 the Broadcast s/b a Broadcast WDC 661 Page: 589 the Broadcast s/b a Broadcast WDC 662 Page: 589 it s/b then the SAS device or expander device WDC 663 Page: 589 It s/b The SAS device or expander device WDC 664 Page: 590 going to temporarily have reduced s/b reducing WDC 665 Page: 595 after [Delete the redundant word.] WDC 666 Page: 596 ATTACHED s/b the ATTACHED [or all otheos after the first otheo may be deleted. This form is used on the next page. One way or another, they should be consistent,] WDC 667 Page: 597 ATTACHED s/b the ATTACHED [or all otheos after the first otheo may be deleted. This form is used on the next page. One way or another, they should be consistent,] WDC 668 Page: 597 ATTACHED s/b the ATTACHED [or all otheos after the first otheo may be deleted. This form is used on the next page. One way or another, they should be consistent,] WDC 669 Page: 599 counts s/b contains WDC 670 Page: 599 it s/b the expander phy WDC 671 Page: 599 (see 4.9.6.5)), and s/b (see 4.9.6.5)). The expander device WDC 672 Page: 600 phy, as s/b phy as WDC 673 Page: 600 phy, as s/b phy as WDC 674 Page: 602 process and s/b process. The SELF-CONFIGURATION LEVELS COMPLETED field WDC 675 Page: 610 (i.e., the first byte, byte 24, contains the FIS Type) s/b (e.g., the first byte of the field (i.e., byte 24) contains the FIS Type) WDC 676 Page: 613 whether s/b whether or not WDC 677 Page: 623 index, in ascending order wrapping from FFFFh to 0001h, that contains a valid descriptor. s/b index that contains a valid descriptor in ascending order wrapping from FFFFh to 0001h. WDC 678 Page: 626 it s/b then the expander device WDC 679 Page: 631 whether s/b whether or not WDC 680 Page: 631 setting and s/b setting. The SAVE field WDC 681 Page: 634 four. s/b four bytes. WDC 682 Page: 658 which s/b that WDC 683 Page: 658 performed, and s/b performed and WDC 684 Page: 659 about s/b for WDC 685 Page: 659 enabled then s/b enabled, then WDC 686 Page: 665 it s/b the phy WDC 687 Page: 710 it s/b [Delete the unnecessary word.] WDC 688 Page: 665 It s/b The phy WDC 689 Page: 666 it s/b the data WDC 690 Page: 671 it s/b the phy WDC 691 Page: 672 the phy expects it to have a valid frame header (e.g., valid frame type, source SAS address, etc.) s/b then the CJTPAT shall be contained in an SSP DATA frame (e.g., including a valid frame type, source SAS address, etc.) WDC 692 Page: 672 the phy expects it to have a valid frame header (e.g., valid frame type) s/b then the CJTPAT shall be contained in an SMP frame (e.g., including a valid frame type) WDC 693 Page: 673 practically [Delete the unnecessary word.] WDC 694 Page: 676 standard s/b standards WDC 695 Page: 685 load then s/b load, then WDC 696 Page: 685 lossy then s/b lossy, then WDC 697 Page: 686 load then s/b load, then WDC 698 Page: 686 lossy then s/b lossy, then WDC 699 Page: 687 actually applied (which is measured independently) is the attenuation and shall meet the requirement specified in 5.3.5.2. s/b of jitter applied is the attenuation, which is specified in 5.3.5.2. WDC 700 Page: 689 shall be s/b is WDC 701 Page: 689 shall be s/b is WDC 702 Page: 689 shall be s/b is WDC 703 Page: 689 shall be s/b are WDC 704 Page: 689 shall be s/b is WDC 705 Page: 689 (time) s/b (i.e., time) WDC 706 Page: 689 (the s/b (i.e., the WDC 707 Page: 689 (full tracking); s/b with full tracking; WDC 708 Page: 689 (no tracking); s/b with no tracking; WDC 709 Page: 690 This value shall fall within the range of -72 dB to -75 dB. Adjust the JMD settings to match this requirement; s/b Adjust JMD value settings to fall within the range of -72 dB to -75 dB. WDC 710 Page: 690 (00110011) s/b (i.e., 00110011) WDC 711 Page: 690 (100 ps) s/b (i.e., 100 ps) WDC 712 Page: 690 (BERT) s/b (i.e., BERT) WDC 713 Page: 690 (PJ) s/b (i.e., PJ) WDC 714 Page: 690 (100 ps). s/b (i.e., 100 ps). WDC 715 Page: 709 understands addressing s/b is capable of addressing WDC 716 Page: 709 specifically s/b [Delete the unnecessary word.] WDC 717 Page: 709 host, and s/b host and WDC 718 Page: 709 might be s/b is WDC 719 Page: 709 needs a means s/b implements a method WDC 720 Page: 710 since the result could be s/b resulting in WDC 721 Page: 710 (i.e., more than one, but less than one per command) s/b [Delete this confusing parenthetical statement. It is not possible to have oless than one [initiator port] per command.] WDC 722 Page: 710 ports, supports s/b ports and supports WDC 723 Page: 735 might s/b may ******************** End of Ballot Report ********************