| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Statement #1: "802.3af PD that takes
50mA during classification is still a compliant
device.
Yair, you are mixing up the ends here. You are
correct that it is perfectly legal for an AF PSE to power a PD that draws
<50mA during classification. I think you are overlooking the fact that
it is illegal for the PD to actually draw more than 44mA (see 33.3.4 of
802.3af: In addition to a valid detection signature, PDs shall provide the
characteristics of a classification signature as specified in Table
33-11).
A PD that draws more than 44mA during classification is
non-compliant.
Statement #2 "It is allowed by the
802.3af and is treated by the 802.3af
PSE.
I think I proved above that it is not allowed for the
PD.
Statement #3 "If it was a mistake to
allow it or not in the 802.3af is not relevant now due to the fact that it was
allowed.
It is only relevant for Type 1 PSEs -- and only if anyone
else cares to continue to allow power to non-compliant devices. I have no
problem closing a loophole in the first standard to disallow bad
behavior.
Statement #4 "In addition, it was not
a mistake to allow 802.3af PSE to power 802.3af PD with bad classification due
to the fact that in 802.3af the whole classification issue was optional and
especially in 802.3af PSE it was optional so in order to give the PD the same
treatment when it is connecting to a PSE that do classification to a PSE that is
not doing classification you had to power the PD in case of classification error
of any kink."
Classification was only optional in the PSE, the PD is
strictly required to conform to some sort of classification. It was
considered optional because you can get Class 0 for free with the detection
resistor. I don't really care if I don't get equal treatment between PSEs
that perform classification and PSEs that don't when we are talking about a
non-compliant PD. Maybe classification should have been mandatory for the
PSE. That is certainly a better solution than allowing power to a
non-compliant device.
To
clarify my statement that you didn't understand, let me place some sentences
here:
from
33.2.8.1: "A Type 2 PSE that has
failed to complete mutual identification may provide Class 0
power."
from
July 2007 Plenary: "Move that Type 2 PSEs may
optionally power Type 1 PDs with Type 2 current
limits."
Figure
33-14 PI operating current templates, this applies to both Type 1 and Type 2
PSEs and makes no distinction between T1 and T2 PDs.
It is
not explicitly stated but via the statements above I can rationally make a PD
that fails to complete mutual ID and gets Class 0 power. But according to
the agreement in SF in July 2007 (moved by Schindler, Seconded by Darshan), the
Type 2 PSE is free to power the Type 1 PD with Type 2 limits. So now I can
be a non-compliant PD and I can reasonably expect that I will get 30W from a
Type 2 PSE. And the PSE is not required to police and only has to conform
to the operating current template which will allow 600mA for a Type 2 PSE.
That was the point of my statement.
Statement #5 "The fact is
The PD
you mention is impossible to design. If it draws no current during
classification (disables the detection resistor), it is still Class 0. Any
other current falls into some category, Class 1, 2, 3, 4 or fail. I know
we can't prevent all non-compliant behavior but, in my opinion, it is bad form
to make it SO EASY to misbehave and still get powered.
Statement #6 "Now what will cause PSE vendors or PD vendors more
problems and noise from the field? Type 1 PD that always working with Type 1
PSE but not working with Type 2 PSE OR fooling our selves that we have the
ultimate solution how to prevent using dumb PDs? You can see to you don’t have
to be smart to create dumb PDs.
My
assumption here is that people have been making compliant PDs and there will be
no noise from the field. As I said above, I am not fooling myself into
thinking this can be made bulletproof, but this is a glaring hole in the
spec. And I disagree, you have to be very smart to make the dumb PDs and
you have to do it on purpose because you thoroughly read the standard and
understand all the intertwined rules that allow misbehavior.
-Chad
From: Darshan, Yair [mailto:YDarshan@microsemi.com] Sent: Thursday, May 22, 2008 3:14 AM To: Chad Jones (cmjones); Clay Stanford; Matthew Landry; Fred Schindler (frs); Patoka, Martin; Bill Delveaux (bdelveau); Anoop Vetteth (avetteth); McCormack, Michael; gthompso@nortelnetworks.com; Jetzt, John J (John); Reshef, Tamir; Feldman, Daniel; Rimboim, Pavlick Cc: STDS-802-3-POEP@listserv.ieee.org Subject: RE: Problems with remedy regarding PSE type 2 behaviour when it reads bad classification Hi 802.3af PD that takes
50mA during classification is still a compliant
device. It is allowed by the
802.3af and is treated by the 802.3af PSE. If it was a mistake to
allow it or not in the 802.3af is not relevant now due to the fact that it was
allowed. In addition, it was not
a mistake to allow 802.3af PSE to power 802.3af PD with bad classification due
to the fact that in 802.3af the whole classification issue was optional and
especially in 802.3af PSE it was optional so in order to give the PD the same
treatment when it is connecting to a PSE that do classification to a PSE that is
not doing classification you had to power the PD in case of classification error
of any kink. This was exactly an interoperability issue only because PSE
classification function was optional. Regarding the argument
" The other problem with
your remedy is that there is a two layer slight of hand going on here. If
you allow a Type 2 PSE to assign this noncompliant PD class 0 there is another
statement that says the Type 2 PSE can treat the class 0 PD as Class 4 and now
we are back to the start. You are allowing a noncompliant device to draw
up to 30W, therefore enabling dumb PDs. My opinion is this is completely
unacceptable. If I were a devious designer, I would just draw 60mA during
class and then move on to drawing 30W." I dot understand the
point you are trying to make since I am not sure that the facts are correct or I
didn’t understand you: You said: " there is
another statement that says the Type 2 PSE can treat the class 0 PD as Class 4
and now we are back to the start. " The specification says
that in 802.3af Class 4 PD is treated as class 0 and not as you mentioned above.
So I don’t understand the argument? You said:
. "You are
allowing a noncompliant device to draw up to 30W, therefore enabling dumb
PDs. My opinion is this is completely unacceptable. If I were a
devious designer, I would just draw 60mA during class and then move on to
drawing 30W." How I allow non
compliant PD to get 30w? Case 1: PD is drawing
60mA during classification. What could be the
options?
The fact is
He design a PD with
resistor signature and without classification at all. So when voltage is applied
it will take full power without any issue. It is not compliant behavior but you
can not prevent it… Now what will cause
PSE vendors or PD vendors more problems and noise from the
field? Type 1 PD that
always working with Type 1 PSE but not working with Type 2 PSE OR fooling our
selves that we have the ultimate solution how to prevent using dumb PDs? You can
see to you don’t have to be smart to create dumb
PDs. Yair From:
We only have to
guarantee interoperability for compliant devices. A device that draw more
than 51mA during classification is noncompliant.
As I pointed out in my
comment it was a mistake in AF to allow a PSE to power a device that has failed
classification and that we should fix that in AT. I'm not concerned that a
device that is noncompliant will not get power from a Type 2 PSE.
The other problem with
your remedy is that there is a two layer slight of hand going on here. If
you allow a Type 2 PSE to assign this noncompliant PD class 0 there is another
statement that says the Type 2 PSE can treat the class 0 PD as Class 4 and now
we are back to the start. You are allowing a noncompliant device to draw
up to 30W, therefore enabling dumb PDs. My opinion is this is completely
unacceptable. If I were a devious designer, I would just draw 60mA during
class and then move on to drawing 30W. the only thing we have
to be careful of is that we are not making all legacy PSEs noncompliant by
removing their ability to power devices that fail classification as Class
0. I would support your statement if it said: If a PSE detects
Iclass_lim, it may power the PD strictly at Class 0 levels or it may choose to
enter the IDLE mode. A Type 2 PSE that decides to power a PD that violates
Iclass_lim shall limit Pport to 15.4W. In this case, there is no allowance
for the Type 2 PSE to power at Type 2 levels. or some other
equivalent but better wording. I would want a shall statement that
generates a PICS that would check that a PSE will police at 15.4W if it powers a
noncompliant device. Of course we would also have to figure out how to
work this into the state diagram. To me the easier
solution is to make the decision to not power these
devices. - From:
Hi
guys, I have found a problem
with the remedy on the above subject. We have 3 cases in
which we agree last meeting to return to IDLE
state. Case
1: If PSE type 2 reads
class The rational was that
we don’t want to encourage someone using different coding so we can reserve it
for future use. So far it makes
sense. Case
2: If PSE Type 2 pass
detection successfully and fails to complete classification, it will return to
IDLE state. Rational: Classification in Type
2 PSE and PD is mandatory. If it is not working then probably one of the two
parts PSE or PD is non compliant or defective. Case
3: If PSE detects
Iclass_lim, it will return to IDLE. The problem is in Case
3. Rational: a) If PSE type 2
connected to PD type 1, and PSE reads Iclass_lim then according to last week
change, PSE will return to IDLE state. b) But If PSE type 1
connected to PD type 1, and PSE reads Iclass_lim, PSE is assign Class 0 which
mean the PD will be operated. Which means that in
(a), PD type 1 will not work ever never with PSE type 2 under Iclass_lim and may
work with PSE type 1. This is violates
backwards compatibility and creates interoperability problems between PSE type 1
and PSE type 2 connected to PD type 1 exhibiting
Iclass_lim. The solution for this
problem is: In Case 3 (and maybe
also in case 2) , The PSE type 2 shall assign Class 0 as well as Type 1 PSE, if
it detects Iclass_lim. What is your opinion on
these guys? Yair
Analog Mixed Signal
Group Microsemi
Corporation
Cell:
+972-54-4893019 E-mail: <mailto:ydarshan@microsemi.com>. |