Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [802.3ae] D3.1 Clause 45 and Clause 48 potential inconsistenc ies

The comment cannot be acted up.  Reason: There was no comment against D3.1
against this.  D3.2 is in the process of being created, and when issued, a
comment can be generated during the ballot and comment period to change the
text.  If the comment is accepted, then the text in Clause 45 will be
changed by Ed Turner (Pat Thaler is the Clause 49 editor).

We welcome any and all comments to make the draft standard a great document,
but we also have a formal process that we're required to follow.


Brad Booth
P802.3ae Editor-in-Chief
bradley.booth@xxxxxxxxx <mailto:bradley.booth@xxxxxxxxx>  

		-----Original Message-----
		From:	James Colin [mailto:james_colin_i@xxxxxxxxx]
		Sent:	Wednesday, July 25, 2001 3:50 PM
		To:	pat_thaler@xxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
		Subject:	RE: [802.3ae] D3.1 Clause 45 and Clause 48
potential inconsistenc ies

		I think that in this case the Draft should be written
		in a better way. Following this thread, I think that
		the term "detect a local fault" is defined in a very
		general and not accurate way. And even you admitted
		that there is an un-necessary duplication. You may fix
		it or not; But the problem is not "misreading the
		spec" as you wrote. As a matter of fact, I think it
		was read very carefully. I think that you should be
		thankful for such comments.


		> -----Original Message-----
		> From: THALER,PAT (A-Roseville,ex1)
		> Sent: Tuesday, July 24, 2001 10:06 PM
		> To: Boaz Shahar
		> Cc: HSSG (E-mail)
		> Subject: RE: [802.3ae] D3.1 Clause 45 and Clause 48
		> inconsistenc ies
		> Boaz,
		> I agree with Rich. I notice that you consistantly
		misread the 
		> text of clause
		> 45. Whenever it says "detects a local fault
		condition" you quote it as
		> "detects an LF condition" and this seems to be the
		source of the
		> misunderstanding. The former means that the the
		device has 
		> detected a fault
		> in itself. The fault could be an inability to sync
		to the 
		> incoming signal or
		> it could be an implementation dependent fault
		detection capability. 
		> We have no requirements (and no options) for any
		> except the RS to
		> detect an incoming LF signal and we specify no rules
		for such 
		> detection
		> except at the RS. That is why there are no bits in
		Clause 45 
		> for "detects an
		> LF signal". There are only bits that are set when a
		> fault condition is
		> detected.
		> Regarding your question about the apparent
		duplication of local fault
		> reporting bits. I have never understood why in
		> register 1 we have a
		> bit that indicates that the receive link is up while
		> status register 2 we
		> have a bit that indicates it's inverse - a receive
		local fault. (Note
		> however that, since they both latch, they may not at
		a given 
		> time contain
		> inverse values. One may have been cleared by reading
		> the other still
		> is latched.) The duplication has fallen below my
		> threshold for
		> raising a comment. Since in Status register 1 never
		has many 
		> bits used and
		> the other bits in Status register 2 generally report
		> information such
		> as abilities, it would be logical to move the
		receive and 
		> transmit local
		> fault detection bits to status register 1 and to
		remove the 
		> receive link up
		> bit.
		> The bit in 5.24.12 is different than the bits in
		> registers 1 and 2 in
		> two significant ways. First, it only indicates a
		failure to achieve
		> alignment to the incoming signal while the other two
		bits can reflect
		> implementation dependent fault detection. Secondly,
		it is not 
		> latched. The
		> bits in the lane status registers represent a
		snapshot of the 
		> status of the
		> receive link synchronization: the status of each
		lane plus 
		> the ability to
		> deskew across the lanes.
		> Regards,
		> Pat Thaler 

		Do You Yahoo!?
		Make international calls for as low as $.04/minute with
Yahoo! Messenger