RE: [802.3ae] D3.1 Clause 45 and Clause 48 potential inconsistenc ies
Jim,
I don't fix anything in Clause 45. I am the Clause 49 editor.
There is a bit that contains the same information as another bit. Whether
this is unnecessary duplication or not is up to the task force to decide and
not to any individual.
Also, these bits were present in D3.0. They haven't been changed and no one
commented that they should be. The bits may be less than optimally
efficient, but they aren't broken. We will be conducting a recirculation
ballot on 3.2 where the valid subject for comment is the technical changes
since D3.1 and any unresolved no vote comments. Recirculation isn't for
making technical changes to for minor optimizations because if we let that
happen we may never finish.
LF is a signal name. "Detect a local fault condition" is not equivalent to
"detect an LF [signal]" and so when someone quotes a part of the standard
that says local fault but changes local fault to LF it appears they are
misreading what is there.
If you feel other wording would be more clear, then I suggest you submit a
ballot comment to that affect. Personally, I agree with Rich that clause 48
clearly defines the meaning of detecting a local fault condition for that
sublayer.
Sincerely,
Pat
-----Original Message-----
From: James Colin [mailto:james_colin_i@xxxxxxxxx]
Sent: Wednesday, July 25, 2001 1: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/