Re: [8023-POEP] DS vs. SS debate

[Matthew Landry <Matthew.Landry@xxxxxxxxxx>]

Dan, I agree with your thinking.  Most powered devices will be 2PMP, and hence ignorant of 4P issues.  But, you conclude that the easiest solution is to define a Single Signature for a 4P PD, while it seems to me that the Dual Signature is truly the easiest solution in terms of writing the standard and achieving well-defined system interaction.

 

Those powered devices that want to capture 4PHP can decide how they want to present their independent signatures on the pairs (concurrently, sequentially, whatever), as well as how to combine the power that they will be receiving from any of a number of mixed sources (viz. the various cases identified by Yair and Steve).

 

We all agree that there are additional burdens concomitant with 4PHP -- the most significant of which is probably combining the possibly disparate power sources.  That PD cost -- be it silicon cost or implementation headache cost -- towers over the cost of providing two independent signatures.  Couple that with the questionable value of the PSE knowing whether it is talking to two 2P PDs or one 4P PD and the added complexity of writing it into the standard, the 4P Single Signature approach is a hard sell.

 

As Hugh expounded so thoroughly, simpler is better.  Now, the question is: can we agree on which method is simpler?

 

I believe that since the meeting is over, we don't have any ability to change the purpose of the classification ad hoc -- but that doesn't mean that Clay can't choose to give over the teleconference time to DS/SS discussion.  The reflector might also be an acceptable forum for hammering out this issue.

 

Cheers,

Matt

---

From: owner-stds-802-3-poep@xxxxxxxx [mailto:owner-stds-802-3-poep@xxxxxxxx] On Behalf Of Dove, Dan
Sent: Thursday, May 25, 2006 2:12 PM
To: STDS-802-3-POEP@xxxxxxxxxxxxxxxxx
Subject: Re: [8023-POEP] DS vs. SS debate

Steve,

 

Perhaps I am being too simplistic, but it seems like we should have SS and be done with it. I think that case 6 is unnecessary and case 5 can be dealt with in the PD if they want to take power from all 4 pairs, but that would be the high power case and I don't think we should burden the spec with implementation challenges of high power. I anticipate the vast market demand is going to be two-pair medium-low power applications and therefore would try to optimize for that market space.

 

I appreciate your suggestion to try to get concensus prior to the next meeting and if you want to put up a "SS proposal" I would likely support it.

 

Dan

 

------------ Previous Message Below ------------

 

---

From: owner-stds-802-3-poep@xxxxxxxx [mailto:owner-stds-802-3-poep@xxxxxxxx] On Behalf Of Steve Robbins
Sent: Thursday, May 25, 2006 10:26 AM
To: STDS-802-3-POEP@xxxxxxxxxxxxxxxxx
Subject: [8023-POEP] DS vs. SS debate

Guys,

 

This email is intended for people who are interested in the DS vs. SS debate, or the classification adhoc.  If you’re not one of those people then please disregard this.

 

Unfortunately, no decision was reached in the Austin meeting, so the DS vs. SS debate must go on.

 

This issue is far too important to just let it sit until the plenary.  We must have it all figured out before the plenary, otherwise we probably won’t reach a decision then either.  And, as we all know, the 802.3at Task Force is already way behind schedule.

 

My question is, how should we proceed from here?  So far, the discussion forum has been the classification adhoc, but this is really outside their scope.  Should the Task Force start a new adhoc, or morph the classification adhoc into a system architecture adhoc?

 

I think we need to make a decision quickly, and continue the debate aggressively.

 

Steve 

 

Ignore this legal statement: 

This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.