Hi Matt,
Probably you didn’t
see my email which I ask not to have meetings on Friday. Friday and Saturday are
a non working days here like Saturday and Sunday' in North
America.
Any way, please find
below my comments/opinion regarding the base line bucket:
Comment #141:
Comment #141 deals with
"Range of Maximum power used by the PD".
The commenter state that
this column has no value and I disagree with him.
This column has value in
which it specifies the range of maximum for better power management.
It is true that when you
are using L2 you may not need this information however when using only L1, this
information has value.
Regarding the argument
that it confuses the average reader with the minimum power required to keep the
port ON, I don’t see how it confused since the text is clear and if it
still confuse we can add clarification but it is not justifying changing the
level of information contained in this column.
I suggest rejecting this
comment or ad clarification for the use of it in respect to 33.3.6.
Comment #124:
The commenter is basing
his argument on the following assumptions:
- The existing PD detection section requires specific design
requirements that are not necessary to ensure interoperability: This is
not accurate statement. All the requirements in the specification are a
result of extensive analysis and tests. Each of the requirements came to
ensure interoperability.
The
change it or modify it we need to td feasibility and economical
tests/simulations. Non of it has been shown or demonstrated.
- Pointing out to presentation made in September 2005: This
presentation was "rejected in principle" by the audience at that
meeting since it failed to accommodate false positive detection due to the
time constant issue. Specifically, the standard recommend to take
measurements after 5tau=1% of steady state in order to reduce the chance
for false positive detection. So this presentation is a good example for
what we should not do. There are other detection concepts that were
discussed such as capacitor detection, AC coupled diode and other and the
resistor concept was chosen as the preferred one which meets all objectives
at low cost and high reliability.
- Figure 33-10 is no the PD model so it is not clear why it is
related to detection issues as stated in the Suggested Remedy.
- Requiring PSE to detect values of Rpd_d for all permissible values
of Cpd_d as specified in Table 33-2 is not practical and it is not
required by the standard today. It adds unnecessary burden to the implementers
with increased time constant problems.
Rational:
The
current specification required to meet Rpd_d together with Cpd_d<0.15UF. This
is possible and proven feasible.
Requiring
meeting Rpd_d with Cpd_d>>0.15UF is technically problematic due to long
time constants and false positive detection risks. There is a way to overcome
this problem by using ac signals with source and sink capabilities however it
requires technical and economical feasibility tests which if somebody present
such it will be easier to consider and asses its technical and economical
aspects.
- To delete the requirement of two point detection it requires to
show that you can detect Rsig with out errors within single measurement. This
is not an implementation issue. It is clear interoperability issue. If
somebody can technically and economically prove that it can be done in
other ways he is welcome.
I
suggest rejecting this comment unless serious technical work will be presented
to backup the changes suggested.
Comment #13:
This comment
is similar in principle to comment #124.
Figures
33-8 and 33-9 are not mandating implementations.
It guarantees
interoperability.
Figure 33-8:
- Zsource>45K: Limiting energy backwards to PSE.
- Zsource>45K : Preventing 25K signature if two PSEs are connected
together
- Vdetect and Zsource>45K allows meeting 30V open loop and 2.8-10V
during valid signature with adequate resolution
- D1: Prevents two PSEs connected together in opposite voltage
polarity to generate 25K signature
- D1: Prevents two PSEs connected together in opposite voltage
polarity to generate 120V on the port/chips.
Figure 33-9:
- Zsource not limited, with series diode D2: Limiting energy
backwards to PSE.
- D1: Prevents two PSEs connected together in opposite voltage
polarity to generate 25K signature
- D1: Prevents two PSEs connected together in opposite voltage
polarity to generate 120V on the port/chips.
The implementer can use any Thevenin equivalent of figures 33-8 or 33-9 which
allows the flexibility which we are looking for.
In order
to allow such big changes it is requires proving feasibility with different
PSEs using different methods complying to the suggested remedy……!!!
Unless
such proofs made I suggest to reject this comment.
Yair
From:
owner-stds-802-3-poep@IEEE.ORG [mailto:owner-stds-802-3-poep@IEEE.ORG] On Behalf Of D. Matthew Landry
Sent: Friday, January 04, 2008
4:16 PM
To:
STDS-802-3-POEP@LISTSERV.IEEE.ORG
Subject: Re: [8023-POEP] Baseline
Bucket ad hoc
Please find
attached material for discussion during this morning's baseline bucket ad hoc.
Note in the meeting notice below, the 11:00AM starting time is Central Standard Time.
-matt
On Dec 11, 2007 11:53 AM, D.
Matthew Landry
< dmlandry@ieee.org> wrote:
Colleagues -
This message is announcing a comment resolution adhoc to discuss the remaining
comments classified in the baseline
bucket. This meeting will be administered by teleconference. Required materials
will be sent prior to commencement of the meeting. The bucket of comments can
be found at the following URL:
http://www.ieee802.org/3/at/comments/D1.0/P802d3at_D1p0_postmtg_bucket_baseline.pdf
Please take some time to review the IEEE-SA PatCom slides prior to the start of
the telecon. I will ask if anyone has not
reviewed the slides at the beginning of the call. If any attendees indicate
that they have not reviewed the slides, time will be made available for such
review. The slideset can be found at the following URL:
http://standards.ieee.org/board/pat/pat-slideset.pdf
The dial-in information is found at the end of this email. If you plan to
attend, I ask that you RSVP no later than the day before so that I can
ensure that enough dial-in slots are available.
Thank you.
- matt
TELECONFERENCE DETAILS
Subject:
IEEE 802.3at baseline bucket
Meeting ID:
802302
Date/time:
01/04/2008, 11:00 AM (US: Central (CST/CDT))
01/11/2008, 11:00 AM (US: Central (CST/CDT))
Duration:
1 hrs 30 minutes
Dial-in:
International: 1.512.532.5999
USA:
1.866.781.8274