The editor's note describes a potential future change that has been discussed (most recently at the last SAS editor's meeting, which almost nobody bothered to attend).  If such a proposal does come to fruition, it would include the necessary state machine changes.
 
I don't know why you would prefer people to be totally surprised by such a proposal and not warn them with an editor's note that such a change might be forthcoming.
 
If you really meant you are not in favor of the concept described by the note (rather than just want the editor's note removed), then that's a fair discussion.  The reason it's suggested is that SAS tolerates single-bit errors with minimal disruption in most cases (via redundant primitives, transport layer retries, 1 ms timeouts, etc.).  A single-bit error in the IDENTIFY frame, however, requires redoing the entire link reset sequence - which takes much longer than 1 ms, increments error counters, and triggers Broadcast (Change).  Sending IDENTIFY 3 times would improve SAS-2 phys' tolerance for such problems.
 
Unless the bit error occurs during the SOAF primitive, it probably won't help a SAS-1.1 receiver, which per SL_IR ignores everything after the first SOAF.
 
 

From: owner-t10@t10.org [mailto:owner-t10@t10.org] On Behalf Of Stephen FINCH
Sent: Friday, February 16, 2007 3:51 PM
To: T10 Reflector
Subject: sas2r08 Editor's Note 35 (Clause 7.9)

Here is the text of the referenced editor’s note.

 

Editor’s Note 35: To better tolerate single-bit errors, it might be prudent to require SAS-2 phys

transmit IDENTIFY address frame 3 times rather than just once. Although the frame includes a

CRC, there is no NAK to cause retransmission if it fails - the entire link reset sequence must be

restarted if a bit error corrupts the IDENTIFY address frame. If it were transmitted 3 times, that

would not be necessary. 3 times would cover DFE error propagation between back-to-back

EOAF-SOAF (which should be allowed). After sending one IDENTIFY, must be immediately ready

to handle an incoming OPEN. Can stop sending additional IDENTIFYs if that happens (or keep

sending them - it shouldn’t matter to the recipient).

 

I would like this editor’s not removed from the draft standard. 

 

This note is in conflict with the SL_IR statemachine.

 

I have seen no proposal to change the link layer functionality as suggested by this note and,

until such a proposal is made I believe this does nothing but add confusion.

 

Regards,

 

 

Steve Finch

STMicroelectronics