RE: [802.3af] Coments to the Register proposals for IEEE 802.3af
Hi David ,
Thanks for your work.
Avi
> -----Original Message-----
> From: David Law [SMTP:David_Law@xxxxxxxxxxxx]
> Sent: Fri, August 24, 2001 4:12 PM
> To: Avi Berger
> Cc: 'mike_s_mccormack@xxxxxxxxxxx'; 'stds-802-3-pwrviamdi@xxxxxxxx';
> 'Dan Romascanu'
> Subject: RE: [802.3af] Coments to the Register proposals for IEEE
> 802.3af
>
>
>
> Hi Avi,
>
> As ever thanks for you time and you comments. I have added a few comments
> below
> to you e-mail but in general I think we are in agreement about everything.
> I
> will incorporate these changes into my submission and try and ensure I
> post it
> early next week for review. Please be assured, as I mentioned before, that
> as I
> will submit it as a comment against the draft the Task Force will be free
> to
> rejected it (I hope not), accepted it or modified it as they see fit.
>
> Bye for now,
> David
>
>
> PS - Note that I have re-formatted the e-mail I received as its format was
> getting messed up, no doubt due to all the e-mail systems it crosses, but
> I
> don't believe I have changed any of the contents.
>
>
>
>
>
>
>
> Avi Berger <AviB@xxxxxxxxxxxxxx> on 22/08/2001 14:38:13
>
> Sent by: Avi Berger <AviB@xxxxxxxxxxxxxx>
>
>
> To: David Law/GB/3Com@3Com
> 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>
> Subject: 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 seenhere. 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
> avi> indicates that the PD Detection function is disabled. If you connect
> avi> a not valid PD (no signature ) to that port the PSE will supply power
> avi> and can do some damage to this PD.
>
> david > Thanks for this clarification. I certainly agree that the ability
> to
> david > turn off the PD Detection function as you describe above should
> david > not be permitted and will remove this enumeration.
>
>
> 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
>
> david > Thanks for this.
>
>
> 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
> avi > classification of an attached PD .
> avi > are you including it in the recommended package?
>
> david > Yes, I will include this in the recommended package in my
> submission.
>
>
> 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
> avi > manager would like to read the setup. In some case he can compare
> avi > the same object in the PSE with the PD and solve some power
> management
> avi > problems.
>
> david > I am happy that this will help diagnostics and would support this
> david > in the IETF MIB but as described about I would prefer not to
> include
> david > this in Clause 30 nor in the register specification. I hope you
> are
> david > happy with this.
>
>
>
> 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
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>