|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Thanks for your response.
Please see my answers/inputs below.
I am glad we are on the same page on these important issues. From my perspective, the objective of this adhoc in a study group phase can be met by Dave’s table.
Yair: You may be correct. See my updated presentation. In general, my sole intent and strategy was:
a) In order to build compatibility matrix we need to define the PSEs name/type/power (pick the best title that serves this purpose) and also the PDs so we can addressed them.
b) The ways to find those devices are (1) what is obvious by the standard e.g. Type 1 and Type 2 devices (2) those that can/may implement by the current standard which may require some discussion. (3) those devices that we know about them that currently is used in the market and compatible to the standard. (4) Possible 4P devices that covers the maximum power allowed today by the cabling standards TIE etc. e.g. up to 51W max. at the PD (5) Other 4P devices with higher power than 51W at the PD. Yes this is make the table more complex than the 802.3at table but for sure it cannot be as in 802.3at just because we have more options now. One of the objectives of our group is to agree on the use case that are relevant for the study group for crafting the objective 14 like.
We need to be careful that we will define in the table the use case that we want to support on one hand and on the other hand not to caught into a situation that if we didn’t define some cases it will not be addressed at the task force because we "don’t have to" argument that comes together with "we don’t have time, we need to meet standard time limitations etc. So I see objectives as a commitment and not just something to check and move on so we can say we met 5C etc. we are not late or out of schedule so we can do it and done with It within a meeting or two. The group inputs is one important factor to do it in reasonable time.
May I suggest another adhoc to exhaustively go over the case studies of what Dave’s table means/implies in the Task Force as this in my mind is a considerable amount of work. For instance I think it deserves some added perspective of what the overall likelihood of some of the corner cases actually are. I think there are a lot of premeditations and combinations here to consider.
Yair: I fully agree. This is very complex issue and we for sure will address it in the task force and it deserves an ad-hoc.
Just creating a list of PSEs, ‘Y’ cables, Mid-Spans on the PSE side, and PD types in combination with ‘Y’ cables on the PD side would seems to generate a fairly large set to consider.
For that matter, we should consider the likelihood of running into ‘Y’ cables at all. It something I would like to see open for the entire group to see and ponder.
Yair: I agree. In my updated presentation I have narrowed its scope to address what I believe is a must starting point to meet our ad-hoc objectives. The rest can be done in the task force.
Also I would guess we would want to establish some sort of baseline error (false detection) rate, what could loosely be compared to the acceptable BER of a PHY system. (this is only a loose comparison!) This could for instance be based on existing false detections that cause undesirable results in real systems today.
Yair: This is even more complex issue and belongs to task force and not to this ad-hoc objective.
I guess what I am saying is that some corner cases and their effect on the ultimate specification for PoE++ are not just black and white and I would want the larger group to have time to consider there likelihood and therefore risk in some sort of agreed upon context.
Yair. I Fully agree. However what is corner cases? To some it is corner cases to some is real issue, so the challenge of this ad-hoc is to address and define the sure things and not crafting objective that will be wrongly used to ignore those cases under time pressure. At least I believe, we need to address what is explicitly or implicitly allowed by the standard so we meet the backwards compatibility requirement as well.
Creative text will help here.
I am by no means an expert in what work goes in a Study Group and what work goes in a Task Force but I would prefer to get to the Task Force sooner and solve these issues where we can actually make material decisions based on technical merit, cost, and risk which we are (mostly?) prevented from doing in a Study Group.
Yair: Agree. The study group is focusing on crafting the 5C and objectives. It cannot craft/address the standard actual work. To have good objective and show that we can meet 5C, we may need some technical work/presentations to raise the topics we want to address in our objective. For example if you believe that we can get maximum 51W and we don’t have a current sharing issue to worry, it will be helpful if you show why you believe it so the group can address it and you may save my time and the group time since One of my action item is to do presentation that shows how current sharing issues affect the maximum useable power to TBD below 51W while meeting economical and technical feasibility and as a result to get to a consensus to craft the objective that state what will be the power that we will "at least " support as required by one of our objectives.
BTW, given all of this this I totally see why you cannot quickly evaluate the cases for Dave’s table, or really any table at this stage of a Study Group. This amount of work could delay out ability to get to the Task Force if it were fully explored in the Study Group.
I fully agree that we need to keep it simple and also per Jeff comment not to imply or suggest solution.
During the meeting on Thursday we will review first the initial material that I have send you and getting your specific inputs and comments and discuss it.
I appreciate if you can send specific inputs today, e.g. the text that you believe is implying or suggesting solutions (per Jeff comment) so I can send you updated presentation that is addressing your comment.
I will not have time to address or modify the presentation per Dave inputs so we can address it during the meeting or afterwards over mails to verify it covers all devices.
I like the terseness of your table.
I have attached a presentation to this email with some thoughts on the compatibility matrix. I think we need to keep it as simple as possible, while still conveying the information needed. I wanted to get this suggestion in front of everyone before the conference call.
+1 603.222.8519 (Office)
+1 603.410.7884 (Mobile)
Thanks for the comments.
Regarding comment #1: I have addressed the foot notes at the relevant places and it affected the requirements. Please see attached updated slide 10 in the cases were PD power >PSE power.
Regarding comment #2: Please see slide 4 where you can find part of the answers to your question and I hope the missing data will be captured by the ad-hoc members prior the ad-hoc call. We need the information from the group as well. No doubt about it and yes, it may take some time unless everybody agrees that what is in the presentation covers our scope of interests.
Recommended Slide Changes:
· Update table on slide 9 to include footnotes 2 & 3 after the text “work” for all pertinent cells.
· I suspect it will take a considerable amount of time to put together the various device lists outlined on slide 3. Will this data be captured prior to the Ad-Hoc call?
Please see attached Compatibility Matrix Ad-Hoc material for our Compatibility Matrix Ad-Hoc conference call.
Meanwhile, until the formal ad-hoc conference call meeting, I'll appreciate if you review it and send your inputs over the reflector to start the discussion so we can better prepared for this meeting.
I am planning to have at least one ad-hoc conference call until the IEEE802.3 Geneva Interim which its details I'll send to you within a day or two.
4P-PoE Compatibility Matrix Ad-Hoc Chair.