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.
Thanks,
Brad
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
Pat,
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.
Regards
James
> -----Original Message-----
> From: THALER,PAT (A-Roseville,ex1)
[mailto:pat_thaler@xxxxxxxxxxx]
> 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
potential
> 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
sublayer
> 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
local
> fault condition is
> detected.
>
> Regarding your question about the apparent
duplication of local fault
> reporting bits. I have never understood why in
status
> register 1 we have a
> bit that indicates that the receive link is up while
in
> 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
while
> the other still
> is latched.) The duplication has fallen below my
personal
> 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
static
> 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
status
> 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
http://phonecard.yahoo.com/