| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Yes, this issue is closed. Yair From: So it looks like Anoop and Yair worked this out
while I was enjoying the long American holiday weekend. Yair, I take this to mean that you no longer have
the concern you originally voice in the email and that we can close this email
chain out as resolved? Thanks to all. - From:
owner-stds-802-3-poep@IEEE.ORG [mailto:owner-stds-802-3-poep@IEEE.ORG] On Behalf Of Darshan, Yair Hi Anoop, OK. I got your point. Yes we could do the change that you are offering
(Type 1 PSE to optionally return to IDLE when classification fails) however it
will not fix the "problem".. it only increase the number of good PDs
over the years. It looks that Chad's input that we don’t
have to worry about interoperability issues when non compliant PDs are involved
is the right path therefore going to IDLE in Type 2 whenever bad class is
detected is OK. Yair From: owner-stds-802-3-poep@IEEE.ORG
[mailto:owner-stds-802-3-poep@IEEE.ORG] On
Behalf Of The problem is exactly what you mention..... A PD that violates the Vport spec will work with
all the PSEs until the new spec is ratified and we have PSEs that shut off the
port when the Vport is outside the operating range. I understand that this is
optional behavior. But it is acceptable behavior and hence different PSEs (not
based on type) will behave differently to the non-compliant PD. If you like the above behavior then I go back to
my earlier suggestion that we should allow Type-1 PSEs to optionally return to
idle state if classification fails. This will ensure that both type-1 and
type-2 PSEs could behave similary when connected to a non-compliant PD
in the future. Thanks Anoop From:
owner-stds-802-3-poep@IEEE.ORG [mailto:owner-stds-802-3-poep@IEEE.ORG] On Behalf Of Darshan, Yair Hi
Anoop, I
am not sure that the example you have used below is correct. It
is true that almost all type 1 PSEs are using Foldback however the rest of the
statement " We have specifically disallowed this behavior for type-2 PDs.
Aren't you concerned about this?" is not clear to me due to the fact that
if Vport is out of operating range, both Type 1 and Type 2 PSE may disconnect
the power so I don’t understand what you meant by "we specifically
disallow this behavior …" . Please elaborate more on
this. Yair From: owner-stds-802-3-poep@IEEE.ORG
[mailto:owner-stds-802-3-poep@IEEE.ORG] On
Behalf Of Hi Yair We have made ample changes to the spec that will
cause type-1 and type-2 PSEs to behave differently towards a non-compliant PDs.
For example "Move that a PSE in power on state may
remove MDI power when the MDI voltage is out of specification" M: F. Schindler S: Y. Darshan Almost all type-1 PSEs that I know of use
aggressive foldback and hence will support a PD that violates the Vport spec
for short intervals. We have specifically disallowed this behavior for type-2
PDs. Aren't you concerned about this? Anoop From:
owner-stds-802-3-poep@IEEE.ORG [mailto:owner-stds-802-3-poep@IEEE.ORG] On Behalf Of Hi Anoop, I am not aware of such PD however this question
is not relevant to our discussion. This is a principle discussion about
interoperability. I thought that we should equate the behavior of
Type 1 PD when connected to Type 1 PSE and Type 2 PSE. Yair From: Hi Yair Is there a reason why you want this behavir for
Type-2 PSEs? Do you know of any PDs that fail classification? If not then we
should not be discussing this. If the PD is non-compliant type-1 and type-2
PSEs might treat them differently and I dont see this being an issue. Thanks Anoop From:
owner-stds-802-3-poep@IEEE.ORG [mailto:owner-stds-802-3-poep@IEEE.ORG] On Behalf Of Hi Summarizing all opinions on that subject leads to
the conclusion that: If we allow PSE type 1 to power PD type 1 with
bad classification and it will not be powered when connected to Type 2 PSE, it
is not a case of interoperability due to the fact that the PD was not compliant
(or defective) at the first place. Yair From: 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. - From: 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? 1. It is Type 1 PD which according to 802.3af it will get power from
the PSE. 2. It
is Type 2 PD with bad classification circuit or a non compliant PD or dumb PD. 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>. |