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 startin