Re: [802.3af] RE-SEND: Coments to the Register proposals for IEEE 802.3af
Hi Avi,
First let me thank you for your comments. In particular I am grateful for the
time you have taken to compose proposed changed text, this is certainly
appreciated.
Now before I respond to your comments in detail I think it is important that I
state the context under which I generated these submissions. While I intend to
provide these submissions as a comment against the draft and, as with any
comment, they could contain any text I wish to propose (which may be rejected,
accepted or modified as the Task Force sees fit), I did volunteer to do this
work based on the output of the IEEE P802.3af Management Ad Hoc and the contents
of IEEE P802.3af Draft D1.2, subclauses 33.2.11 'PSE Management' and 33.3.6 'PD
management'. It is these two subclauses which I will place the comment against.
When the IEEE P802.3af Management Ad Hoc met in January they reviewed the IETF
MIB proposal and their review was placed in a document which is available on the
802.3af web site (URL -
http://www.ieee802.org/3/af/public/documents/management_ad_hoc_report.pdf).
Subclauses 33.2.11 'PSE Management' and 33.3.6 'PD management seem to be based
on this document. In a number of cases the IEEE P802.3af Management Ad Hoc felt
that a proposed IETF object should not be included in the IEEE standard, a few
of which you propose to add back in as optional attributes.
So in summary while I note the specific three instances below, in general, I do
not wish to provide attributes, nor the associated registers, in my submission
when they were specifically rejected by the IEEE P802.3af Management Ad Hoc,
that were not listed in IEEE P802.3af Draft D1.2 subclause 33.2.11 'PSE
Management' nor 33.3.6 'PD management' and are not related to new features.
Now I am not commenting here on the merits of your proposal to add these three
attributes (I may do that later), however I would like to suggest that you
submit this proposal as a separate comment rather than including it within this
submission. I feel this proposal warrants a individual comment as to add these
attributes overturns the conclusion of the IEEE P802.3af Management Ad Hoc and
therefore I believe this requires a wider discussion within the group before it
happens.
So in summary I think we are in general agreement about everything, there are a
couple of comments below which I would be grateful for thought on and once we
have resolved them I think we will be in great shape to move forward.
Thanks again for your time.
Regards,
David Law
1. 30.9.1.1.2 - change the auto and off to enable and disable
=============================================================
I will update my submission to match this, I assume the IETF proposal will be
changed to match this.
2. 30.9.1.1.4 - delete the both option form this object
=======================================================
I believe that this now matches the MIB to the draft standard's text 'PSEs shall
not operate both Alternative A and Alternative B on the same link
simultaneously' contained in subclause 33.2.1 and will therefore update my
submission as suggested.
3. 30.9.1.1.5 - delete the off option (it is unsecured feature)
===============================================================
I wonder if you could elaborate on the security issue that is seen here. If the
issue is that power can be disabled from the far end device by setting the
attribute to the enumeration 'off' doesn't the same issue exist with the
enumeration 'test' (as this enumeration, while enabling PD detection, prevents
power from being supplied even when a valid PD is detected). We also already
have a MAC enable/disable attribute, aMACEnableStatus, which can disconnect the
network connection from far end device(s) although I guess you may argue this is
not as bad as powering off the far end device.
4. 30.9.1.1.6 - add test, detected and noValidPD to this object
===============================================================
I believe that these additional enumeration addresses my comment text in the
submission and therefore I will add these enumerations and remove the comment. I
assume that values with similar meanings will be added to this related object in
the IETF draft.
5. 30.9.1.1.7 - rename the object name to aPSEPowerCurrentStatus
================================================================
6. 30.9.1.1.8 - add a new object aPSEPowerVoltageStatus
========================================================
While this is a proposal for a new attribute and was not reviewed as part of the
IEEE P802.3af Management Ad Hoc MIB review since, from what I understand,
monitoring these levels are a part of the PD detection system, as well as
current monitoring, I agree that this attribute should be added and I will
include it in my submission.
7. 30.9.1.1.9 - an optional object to GET the usage power for a port
====================================================================
8. 30.9.1.1.10 - an optional object to GET the usage current for a port
=======================================================================
9. 30.9.1.1.11 - an optional object to GET the usage voltage for a port
=======================================================================
The IEEE P802.3af Management Ad Hoc records 'should not be part of the standard
- will not be supported' against these portPseUsagePower and portPseUsageCurrent
hence my reluctance to add these into Clause 30. I believe the issue relates to
a concern of the hardware overhead these items would require, specifically, A to
D converters. Due to this, as I stated above, I would request that you submit
this suggest as a separate comment against D1.2.
As far as adding these attributes to Clause 30 if they were approved, assuming
that they were optional, I believe that they should be added as part of a
separate package (this would appear as another column in Table 30-4) name
something like 'Power monitoring package (optional)' rather than including it
with the recommended package.
10. 30.9.1.1.12 - an object for the classification
==================================================
Within IEEE P802.3 Clause 30 we normally will only provide an object if it is
related to some form of hardware function and therefore has associated registers
bits. If the attribute is purely software based, for example a constant that can
be encoded in the management agent (such as portPdType - telephone, webcam, ...)
or can be calculated by software by combining other attributes (such as summing
several specific error counters to obtain a total error counter), we will not
normally include it in Clause 30 and will leave it to the IETF to define.
In this case the bits defined in the register state 'when read describes the
different terminal on the Power Over LAN Network'. Now if this simply means the
Power sourcing capability of this particular PSE port I think this is a value
that can be encoded in the management agent and I am not too sure how the
register bits would work. For example if I purchased a PHY from vendor A with
these register, how would these registers return a value as PHY vendor A would
have no idea how my power supply system would be configured to supply power to
each port. If you have to have the agent program the registers only then to have
the agent read them back you might as well just use a location in memory to do
this and avoid the need for registers.
If however the attribute, and associated registers bits, are intended to report
the PSE's classification of an attached PD after PD detection has completed (see
33.2.6 onwards), which I believe is the intent, then I agree that as Power
Classification is a new feature this attribute and register bits should be
added. On point to note is that we do not reserve enumerations in attributes for
future use as this is not necessary, if we need to add enumerations for a future
standard that is when it will be done. The same of course is not true of
register bits and these indeed will need to be reserved.
11. 30.9.1.2.1 - rename the object to acPSEPowerCurrentStatusClear
==================================================================
12. 30.9.1.2.2 - add a object acPSEPowerVoltageStatusClear
==========================================================
Based on comments 5 and 6 above I will include these changes in my submission.
As an aside have you had time to consider my comments in relation to the use of
latching bits within this MIB. I would note that similar bits have now been
removed from the IEEE P802.3ae 10Gb/s Ethernet Clause 30 draft D3.2 for similar
reasons and I believe that the parallel IETF group will not have latching bits
either - both groups at more or less the same time, although for different
reasons, came to the conclusion latching bits were not a good idea and I can
provide the rational for this if you wish.
13. 30.9.2.1.4 - add an object for the classification of the PD
===============================================================
Based on my response to comment 10 above I believe that this attribute is simply
the Power classification of the PD which would be a constant value encoded
within the management agent and therefore should not be include in Clause 30 nor
the registers.
14. change in Clause 33 to reflect the changes
==============================================
Accept
Avi Berger <AviB@xxxxxxxxxxxxxx> on 22/08/2001 08:18:30
Sent by: Avi Berger <AviB@xxxxxxxxxxxxxx>
To: "'David_Law @eur.3com.com'" <David_Law@xxxxxxxxxxxx>
cc: "'mike_s_mccormack @ne.3com.com'" <mike_s_mccormack@xxxxxxxxxxx>,
"'stds-802-3-pwrviamdi @ieee.org'" <stds-802-3-pwrviamdi@xxxxxxxx>, "'Dan
Romascanu'" <dromasca@xxxxxxxxx> (David Law/GB/3Com)
Subject: [802.3af] RE-SEND: Coments to the Register proposals for IEEE 802.3af
Hi all,
I am sorry but the files attachment to first e-mail made it too large for
the
reflector so I am re-sending it with the files on the web site.
Avi
Hi all
I am the editor of the IETF Power Ethernet (DTE Power via MDI) MIB .
I have some comment to the proposals management documents.
1. 30.9.1.1.2 - change the auto and off to enable and disable.
2. 30.9.1.1.4 - delete the both option form this object.
3. 30.9.1.1.5 - delete the off option ( it is unsecured feature).
4. 30.9.1.1.6 - add test, detected and noValidPD to this object.
5. 30.9.1.1.7 - rename the object name to aPSEPowerCurrentStatus.
6. 30.9.1.1.8 - add a new object aPSEPowerVoltageStatus to reflect the
overvoltage and undervoltage state.
7. 30.9.1.1.9 - an optional object to GET the usage power for a port.
8. 30.9.1.1.10 - an optional object to GET the usage current for a port.
9. 30.9.1.1.11 - an optional object to GET the usage voltage for a port.
10. 30.9.1.1.12 - an object for the classification.
11. 30.9.1.2.1 - rename the object to acPSEPowerCurrentStatusClear.
12. 30.9.1.2.2 - add a object acPSEPowerVoltageStatusClear.
13. 30.9.2.1.4 - add an object for the classification of the PD.
14. change in clause33 to reflect the changes.
I am adding an update document with the changes ( yellow background indicate
the change form the old version)
on the web site at the URLs -
http://www.ieee802.org/3/af/public/documents/clause33_proposal_comments.pdf
and
http://www.ieee802.org/3/af/public/documents/clause30_proposal_comments.pdf
Avi Berger
NMS Development Manager
> PowerDsine Ltd. - Powering Converged Networks
> 1 Hanagar St., P.O. Box 7220
> Neve Ne'eman Industrial Zone
> Hod Hasharon 45421, Israel
Tel: +972-9-775-5100 Ext.307
Fax: +972-9-775-5111
> mailto: avib@xxxxxxxxxxxxxx
> http://www.powerdsine.com
>
>
>