RE: [802.3af] RE-SEND: Coments to the Register proposals for IEEE 802.3af
Hi David,
Thanks for your response I will update the IETF document with the
changes .
I am sending you some clarification about your comments.
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.
> avi> The enumeration “off” in the aPSEPowerDetectionControl object
> indicates that the PD Detection function is disabled. If you connect a not
> valid
avi> PD (no signature ) to that port the PSE will supply power and
can do some damage to this PD.
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
=======================================================================
avi> I will submit this comment's separately against D1.2
10. 30.9.1.1.12 - an object for the classification
==================================================
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.
avi > I agree with your comment this bits are intended to report the
PSE's classification of an attached PD .
avi >are you including it in the recommended package?
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.
avi > I agree with your comment this bits are constant values but
the manager would like
avi > to read the setup. In some case he can compare the same object
in the PSE with the PD and solve some
avi > power management problems.
Regards,
Avi Berger
> -----Original Message-----
> From: David Law [SMTP:David_Law@xxxxxxxxxxxx]
> Sent: Wed, August 22, 2001 11:13 AM
> To: Avi Berger
> Cc: 'David_Law@xxxxxxxxxxxx'; 'mike_s_mccormack@xxxxxxxxxxx';
> 'stds-802-3-pwrviamdi@xxxxxxxx'; 'Dan Romascanu'
> Subject: 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.pd
> f
> and
> http://www.ieee802.org/3/af/public/documents/clause30_proposal_comments.pd
> f
>
> 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
> >
> >
> >
>
>
>
>