Subject: [Hubmib] Re: draft-romascanu-hubmib-power-ethernet-mib-00.txt

From: "Nick Stapleton" <[email-masked]>
Date: Wed, 21 Mar 2001 03:17:51 +0000

The following comments are from some members of the 802.3af management AdHoc:

Some comments, (inc editorial) are captured as change tracking in the following
word doc, and I have attempted to capture some of these, and other technical
comment in plain text  below also.
My thanks to Steve Buck for much of the input.
regards, Nick Stapleton

(See attached file: draft-romascanu-hubmib-power-ethernet-mib-Comments.doc)

Comments:

Page 6: pethPsePortPowerEnable
- in the 802.3af discussion only 2 enumerated types were defined for this: Auto,
and off.
Currently 802.3af intends to specify the corresponding register as 1 bit
enumerated type, hence "test" would not be supported. I believe hat we (the
802.3af management AdHoc) intended the "test" function described in this MIB to
be part of the register coresponding to MIB Variable
"pethPsePortPowerDetectionStatus"

Page 7: pethPsePortPowerIdPairs
- comment/info: Separate register bits will be provided for "signal" and
"spare". the condition "Both" should not occur in a single PSE, and is not a
legal / allowed configuration within the standard as currently defined.
Page 7: pethPsePortPowerDetectionStatus
 - setting the value test(3) puts the port in a testmode: force continuous
discovery without applying power regardless of whether PD detected.

Page 8: pethPsePortDetectionOperStatus
- I believe: a value of Off(2) means detection mechanism disabled (can't search)
- results from a value of <off(2)> in pethPsePortPowerDetectionStatus
- a Value of searching(3) means that the detection mechanism has not yet
detected a valid PD. It will continue searching indefinately, perhaps with short
intervals between, untill either a valid PD is found, a fault is found, or the
port is disabled.

Page 8: pethPsePortPowerPriority
- this is left as a software only value, no register bits will be specified by
802.3af for this attribute

Page 8: pethPsePortDenyError
- this is left as a software only value, no register bits will be specified by
802.3af for this attribute

Page 9: PsePortFaultError
- comment / info - since this attribute / register would be able to record
transient events, it is possible for the register / variable to have a value of
"both" - ie both an undercurrent event, and an overcurrent event.
Page 9: pethPsePortType
- It is suggested that this attribute should be removed - it is not relevant to
a power-over ethernet MIB in that the type of device provides no useful
information wrt it's power consumption eg a wireless access point can have
precisely the same consumption as an IP Phone, yet one manufacturers IP phone
might have twice the power consumption of another, or of a different model ofIP
phone from the same manufacturer. The priority attribute defined earlier allows
for intelligent management of eg designated 911 emergency phones.

Page 11: pethPdPortPowerPairs
- comment/info: Separate register bits will be provided for "signal" and
"spare". the condition "Both" could occur but is not a legal (allowed
configuration within the standard as currently defined).
Page 11: pethPdPortType
- It is suggested that this attribute should be removed - it is not relevant to
a power-over ethernet MIB in that the type of device provides no useful
information wrt it's power consumption eg a wireless access point can have
precisely the same consumption as an IP Phone, yet one manufacturers IP phone
might have twice the power consumption of another manufacturers, or of a
different model of IP phone from the same manufacturer. The priority attribute
defined earlier allows for intelligent management of eg designated 911 emergency
phones. Note also Power classification is currently being investigated by the
detection AdHoc, but it is not yet certain how many power classes would be
feasible.