Comments resolution for EPON MIBs - draft-ietf-hubmib-efm-epon-mib-02.txt

Hi all,
Here is the list if comments received on the
draft-ietf-hubmib-efm-epon-mib-02.txt document and their proposed
resolution. The comments were provided through this reflector. Comments
are categorized according to their commenter. I tried to capture the
entire discussion on each item. My final line is the proposed
resolution.

I want to take the opportunity here and thank again all commenters for
the time and effort they have invested in reading and commenting.

Thanks,
Lior


1) Charles Chen [mailto:[email protected]] 

1.1) I have a question regarding some counters of eponDeviceStatTable. I
thought only the ONU has eight queues, which it can report to the OLT.
So the ONU can have counters for respective queues. However, the
counters defined in the table include those at the OLT. Do you assume
that the OLT also have eight queues? Then how the queue information is
passed from ONU to OLT or vice versus? How can we ensure the consistence
between queues at ONU and those at OLT? Do you assume that we could use
802.1Q information to achieve this? Is this defined anywhere in 802.3ah?

[LK] 
Actually the OLT counting of the queue model was assumed to be the same
as the ONU but indeed it is not forced by the 802.3ah. I will remove in
the description the reference to the OLT.

2) 

Long thread of discussion regarding "RE: [Hubmib] RE: EFM OAM MIB and
the DateAndTime TC"

OAM adopted suggestion by Dan :

- add a Timestamp object 
- keep the current object, but change the SYNTAX to DateAndTimeOrZero,
so that it returns zero if the managed entity does not have a clock
capability Later, when some implementation experience will be achieved,
we can deprecate one of the objects. 

[LK] I will practice the same for the EPON DateAndTime objects. 0 value
indicated that there is no clock capability.




3) Glen Kramer [[email protected]]

 
3.1. In tables in section 7, object names that are split across lines
lost a letter. 
[LK] Will be fixed

3.2. dot3MpcpMode object should be read-only as is its counterpart in
802.3ah (aMPCPMode attribute).

[LK] I believe it is useful to have also a configuration possibility for
this parameter. As a guideline I believe management should have access
to define main modes of the system. Can you please specify why do you
think writing such a parameter is not useful? If we want to be strictly
following clause 30 I can add change the attribute in the device MIBs
objects to read-write but I would rather have it following the
configuration from the EFM MIB objects. 

[GK] dot3MpcpMode specifies whether the device is an OLT or an ONU.
*ALL* MPCP state machines defined by IEEE 802.3ah are specified either
for the OLT or ONUs. There are no common state machines. It is not
possible to change a configuration parameter and force the OLT to behave
as the ONU or the ONU to behave as the OLT. If in a network, the
management somehow forces the mode change for an EPON device, this will
result in EPON malfunction. In addition, physical layer parameters are
different for these devices: OLT has burst-mode receiver and normal
transmitter and ONUs have normal receiver and burst-mode transmitter. 

[LK] Although I am generally in favor of extending management
flexibilities I am willing to accept this observation regarding the
great difference between an OLT and an ONU and as result the pointless
in a configuration option. So unless anyone IS planning to make a device
which can be an OLT or an ONU (please shout - objection) I will make it
a read only attribute.


3.3. dot3MpcpRoundTripTime should be defined for the OLT only, similarly
to its counterpart in 802.3ah (aMPCPRoundTripTime attribute).  The ONUs
are not aware of the round-trip times to the OLT.

[LK] Agreed

3.4. dot3MpcpOnTime and dot3MpcpOffTime. It is not clear from the
description that these objects refer to laser_on and laser_off times.
Also, according to the 802.3ah, these times are constant and fixed at 32
TQ. These objects are not necessary.  Correspondingly, 802.3ah did not
find it necessary to specify such attributes in clause 30.

[LK] My believe is that the management entity as a general requires the
knowledge of the PON switching time and does not need to find parameters
in the spec to complete the picture as it is may be probably part of a
more general access system. I think the MIB objects should supply a
visibility of the system major parameters although some are fixed. I can
add the description of 32TQs value to align with the MPCP. 

[GK] There is a large number of constants specified in MPCP spec.
Laser-on and laser-off constants are not more important that other
parameters. Why would you choose to define MIB objects for some
constants and not other? 
If the management entity does not know what "PON switching time" is, it
cannot query dot3MpcpOnTime and dot3MpcpOffTime objects. If the
management is EPON-specific enough to understand that there exists "PON
switching time", it already knows that this is a constant equal 32 TQ. 

[LK] As opposed to other constants in the MPCP the switching time
parameter has a meaning in management perspective as to BW management.
It defines the efficiency of the link and therefore is in interest to
the entire network. That is the reason why I considered that there is a
sense in defining these attributes.

 
3.5. dot3MpcpRxNotSupportedMpcp.  The description of this object does
not make sense. If a frame is not supported, it is not an MPCP frame.
Conversely, there exist no unsupported MPCP frames. There is no matching
attribute in clause 30 in 802.3ah and this object should be removed from
this draft as well.

[LK] dot3MpcpRxNotSupportedMpcp. The meaning here is to 8808 opcode
frames which are not of PAUSE or used by the MPCP protocol. I will clear
the description.

[GK] Aha! So it is simply a counter of "not supported MAC Control
opcodes". In this case, this object is not EPON specific, but general
for all Ethernet MIBs. Furthermore, this object already exists
(dot3ControlInUnknownOpcodes) 

[LK] Thanks. The dot3ControlInUnknownOpcodes is the necessary counter.


3.6. Not clear why dot3OmpEmulationSLDErrors is mandatory at the OLT but
optional at the ONU. It is not optional per 802.3ah and is relevant for
both devices. (For comparison, the dot3OmpEmulationCRC8Errors is
mandatory in the OLT and ONUs).

[LK] Agreed

3.7. dot3OmpEmulationBroadcastLLIDPlusOnuId. It is not clear what the
phrase "broadcast LLID plus ONU's LLID (frame reflected)" means. Should
it simply say "broadcast or unicast LLID"?  Also, there is no relevant
attribute in clause 30 in 802.3ah.

3.8. dot3OmpEmulationNotBroadcastLLIDNotOnuId. This object is redundant,
as the dot3OmpEmulationBadLLID will count the same frames. I recommend
removing dot3OmpEmulationNotBroadcastLLIDNotOnuId from this draft.

 [LK] 7+8 ) If we can see the forwarding rules of the ONU in clause 65
then there is a behavior for frames with bit broadcast in the LLID where

the LLID is the OLU's LLID (frames is rejected) and when the LLID is 
not the ONU's LLID (frame is accepted) as part of the point to point 
emulation peer to peer capabilities. This counter counts the first 
frame. I have sent in the past comments regarding that to clause 30. 
The result was  OnuPonCastLLID and OltPonCastLLID which I think their 
definition is too vague and refers to a long list of forwarding rules. 
A solution for alignment is to make a request to change in the 
definition of these attributes in the spec and then unify these 
counters in them.

[GK] I understand now the intentions of this object. I must add that its
description needs some work. Also, more appropriate name would be
"dot3OmpEmulationMode1PlusOnuId", because "Broadcast LLID" refers to a
very specific 15-bit value. Also note that this mode would be used for
shared medium emulation, not P2P.

[LK] I will change broadcastLLID to broadcastBit I think that is the
attribute used in the spec. So I will clear the definition as follow:
dot3OmpEmulationBroadcastBitPlusOnuLlid OBJECT-TYPE
    SYNTAX  Counter32
    UNITS      "frames"
    MAX-ACCESS  read-only
    STATUS  current
    DESCRIPTION
            "A count of frames received that contain a valid SLD
             field in a OLT, as defined in [802.3ah] clause
             65.1.3.3.1, and pass the CRC-8 check, as defined in
             [802.3ah] clause 65.1.3.3.3, and contain the broadcast
             bit in LLID and the ONU's LLID (frame reflected) as 
             defined in [802.3ah] clause 65. This attribute is 
             mandatory for an ONU and mandatory for an OLT (a
             counter per LLID)."
    ::= { dot3OmpEmulationStatEntry 9}


3.9. The access to eponDeviceObjectReset object should be write-only. If
device is being reset, it cannot generate "reset" response. When the
device can generate the response, it will be running already. Thus, the
only possible response is "running".

[LK] As a general logical deductive comment you have here a very good
comment. The problem comes when in devices a reset process can be a very
long process where many different sub-systems are reset. In such a
scenario there is a meaning for being in a reset process. Therefore I
believe that this is an attribute which is needed for a device. I am
open here for suggestions.

3.10. The object eponDeviceObjectOamMode is not necessary. To get the
OAM mode, the management agent would access OAM MIB. No need to
duplicate objects in different MIBs.

[LK] Agreed

3.11. eponDeviceObjectDeviceReadyMode object should be read-only.
Modifying device mode through the management may have unpredictable
results (like taking down entire EPON).

[LK] Changing this variable might indeed cause very major changes in the
system. Yet in my opinion it is needed for management. Unfortunately in
true life engineered systems there is a possibility that a system is not
operating well and it is needed to make it inactive immediately. The
purpose of such an attribute is like this. 

[GK] We should not confuse MIB with debug functions. I would agree to
have an object that would allow disabling a device. I am against
allowing management changing device mode from notReady to ready or from
inProcess to ready. This would take down the device and very likely
would take down the entire EPON. Device mode should only change
according to state machines defined in IEEE 802.3ah.

[LK] Why is it referred only to debug mode? It can be needed during
operation also. Anyway management can affect device condition and
malfunctioning can be a result of any write operation even if it is
resetting of some database log/or table. I think that the security
section in the document should point to the proper place and point out
the hazards. Why is it different in a concept from resetting an alarm
table action or from changing an operational mode? 


3.12. eponDeviceObjectPowerDown - "Setting this variable to True(1) will
cause Device to be entered into Power down mode where no registration is
allowed and only receiving data from the link.". This object does not
make sense. Setting it to True will cause the device lose the link
(because no transmission is allowed leading to MPCP timeout) and never
register again (because registration is not allowed).

[LK] I guess the question is what is the meaning of power down. I
thought of a condition where the device is in minimal power mode where
it is not transmitting and it is in listening mode so it can be enabled
by activation according to MAC address. Keeping it registered can be
done easily by reducing its SLA to minimal BW but I don't think it  is a
power down mode. Keeping it in listening mode will really make it
possible for the system to reduce power (notice I do not define what is
exactly this mode as it can be implemented as the vendor wishes) yet
have the minimal capability to wake up.  

[GK] This is very suspiciously seems like fitting of MIB spec to a
specific proprietary implementation. Even if device is not transmitting
any user data, it should periodically transmit MPCP and OAM messages. 
You are trying to define some kind of standby mode without clear
explanation what this mode is or how it can be implemented. I argue that
because MPCP relies on periodic messages, this mode is not possible
without breaking IEEE 802.3ah standard. "Keeping it registered can be
done easily by reducing its SLA to minimal BW..." This is a particular
implementation. Device registration has nothing to do with the
provisioned SLA. There is a very formal state machine that explains
steps of EPON device registration. 


[LK] O.K. I see what you mean and that is not my intention. I want to
refer to a general power down mode without referring to a specific
implementation. So I will remove the reference for receiving data from
link. eponDeviceObjectPowerDown OBJECT-TYPE
    SYNTAX  TruthValue
    MAX-ACCESS  read-write
    STATUS  current
    DESCRIPTION
            "Setting this variable to True(1) will cause Device to be
             entered into Power down mode. Setting this variable to
             False(0) will cause the device to go out of power down
             mode. When getting True(1) the device is in power down.
             when getting False(0) the device is not in power down.
             Writing can be done all the time. 
             This attribute is relevant for an OLT and an ONU."
    DEFVAL { false }
    ::= { eponDeviceControlEntry 5 }



3.13. eponDeviceObjectReportThreshold. The 802.3ah standard does not
limit number of thresholds to be used.  This object will only return the
first threshold for each queue. What about the rest of thresholds? How
to read/set them?

[LK] 
O.K. Would you consider such an object definition instead: I think it
covers multiple thresholds. eponDeviceObjectReportNumThreshold
OBJECT-TYPE
    SYNTAX  Integer32
    MAX-ACCESS  read-write
    STATUS  current
    DESCRIPTION
            "A set of 8 integers, for each LLID, that defines the
             number of thresholds for each Queue in the REPORT
             message, as defined in [802.3ah] 64. Each Queue set
             reporting will provide information on the queue 
             occupancy of frames below the matching Threshold. 
             Writing can be done all the time.
             This attribute is relevant for an OLT and an ONU."
    DEFVAL { 0 }
    ::= { eponDeviceControlEntry 7 }

    eponDeviceObjectReportThreshold OBJECT-TYPE
    SYNTAX  Integer32
    UNITS       "TQ (16nsec)"
    MAX-ACCESS  read-write
    STATUS  current
    DESCRIPTION
            "A multiple set of 8 integers, for each LLID, that 
             defines the thresholds reporting for each Queue in the 
             REPORT message, as defined in [802.3ah] 64. The number 
             of sets is eponDeviceObjectReportNumThreshold. Each 
             Queue set reporting will provide information on the  
             queue occupancy of frames below the matching Threshold.
             The value returned shall be in Time quanta (TQ) which 
             is 16nsec or 2 octets increments.
             Writing can be done all the time.
             This attribute is relevant for an OLT and an ONU."
    DEFVAL { 0 }
    ::= { eponDeviceControlEntry 8 }

[GK] This is better. For the eponDeviceObjectReportNumThreshold, we need
to describe what happens if this parameter is set to a value greater
than the device can support.  Or maybe we should define a read-only
object eponDeviceObjectReportMaximumNumThreshold that would inform
management entity of the maximum supported number of thresholds.

I would also add read-only object for maximum supported number of
queues: 802.1D says that a device can have from 1 to 8 queues.

[LK] OK


3.14. eponDeviceRemoteMACAddressLLIDControl - "Indicates and controls
the resetting of the LLID MAC address log. Setting this object to
none(1) has no action resetLog(2) empties the LLID MAC address log. All
data is deleted. Setting it to useDefaultReporting(3) returns all
entries priorities to their factory-default reporting. Reading this
object always returns useDefaultReporting(3)." The description of this
object seems to match some proprietary EPON device. In the 802.3ah
standard, there is no provision of whether to keep LLID MAC address log.
It is not clear, what does it mean "returns all entries priorities to
their factory-default reporting", since there is no specification for
either "entries" or "factory-default reporting". This object should be
removed.

[LK] The OLT and ONUs of an EPON device serves as a distributed virtual
switch where the LLIDs represent bridge ports. This model is behind the
point to point emulation mechanism of clause 65 and of the whole LLID
concept. A bridge have a MAC address to port address table and this
table here serves for exactly the same purpose. It is not a proprietary
implementation. The eponDeviceRemoteMACAddressLLIDControl is a control
attribute for resetting this Table. As a table is a manageable entity I
think such an object is needed. The useDefaultReporting(3) category is a
common option for such attributes as a default setting for tables -
Implementation is according to Vendors preference. I have no special
suggestion for the default value. If people will feel more comfortable I
can remove useDefaultReporting(3) and return in the reading none(1).

[GK] There is no document defining what is "LLID MAC address log". The
phrase "The OLT and ONUs of an EPON device serves as a distributed
virtual switch where the LLIDs represent bridge ports" assumes a
particular implementation. LLIDs do not represent bridge ports. LLID
represent virtual links.  These links may or may not be connected to a
bridge at the OLT. The eponDeviceRemoteMACAddressLLIDControl attribute
refers to an address table in the bridge and has nothing to do with
EPON. Therefore, it should be moved to the bridge MIB.

[LK] You are right. It seems like the definition of the table mixes 2
things which were not my intention. My intention was not to hold a MAC
address table as in a bridge (which is well covered in the bridge MIB
objects and I had no intention to replica) but to hold a log of ONUs and
their status. The description of the table is indeed confusing and I
will clear it. I think that the MIBs in the table are O.K. I added the
last 3 sentences for clarification in the last draft and they should be
removed as confusing.

Should be:
eponDeviceRemoteMACAddressLLIDTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF EponDeviceRemoteMACAddressLLIDEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION 
            "A table of read-only value that identifies the
             source_address and LLIDs parameter of the remote devices
             in the network. This MacAddress value, as defined in 
             [802.3ah], 30.3.5.1.5, is updated on reception of a
             valid frame with a unicast destination Field or 
             (1) a destination Field equal to the reserved multicast
             address for MAC Control specified in [802.3ah] Annex
             31A, (2) lengthOrType field value equal to the reserved
             Type for MAC Control as specified in [802.3ah] Annex
             31A. (3)an MPCP subtype value equal to the subtype
             reserved for MPCP as specified in [802.3ah] Annex 31A,
             and an LLID as allocated by the OLT. The table is
             defined as Remote MAC address - LLID (RMadL)
             The table is relevant only for an OLT device"
    ::= { eponDeviceControlObjects 2 }

[DR] 
Please clean up the grammar of this DESCRIPTION clause, otherwise it is
hard to understand. Expressions like 'a table of read-only value that
identifies...' or 'the table is defined as Remote MAC Address...' do not
make too much sense to me. I can guess that you are referring to the
objects (columns) in the table, but I will leave to you clarifying this
text. 

[LK] 
eponDeviceRemoteMACAddressLLIDTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF EponDeviceRemoteMACAddressLLIDEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION 
            "A read-only table of objects that identifies the source
             MacAddress and LLIDs parameter of the remote devices in
             the network. 
             This MacAddress value, as defined in [802.3], 
             30.3.5.1.5, is updated on reception of a valid frame
             with:   
             (1) a unicast destination Field or a destination Field
             equal to the reserved multicast address for MAC Control
             specified in [802.3] Annex 31A. 
             (2) lengthOrType field value equal to the reserved
             Type for MAC Control as specified in [802.3] Annex
             31A. 
             (3)an MPCP subtype value equal to the subtype reserved
             for MPCP as specified in [802.3] Annex 31A,
             and an LLID as allocated by the OLT. 
             This table is denoted as 'Remote MAC address - LLID'
             (RMadL) table.
             The table is relevant only for an OLT device."
    ::= { eponDeviceControlObjects 2 }


3.15. Objects eponDeviceStatTxFramesQueue[0-7],
eponDeviceStatRxFramesQueue[0-7], and
eponDeviceStatDroppedFramesQueue[0-7]
are not specific to EPON. These objects exist for other devices, such as
bridge ports. There is no need to duplicate these objects here. Besides,
neither 802.3ah nor 802.1D standards require exactly 8 queues to be
implemented. I recommend removing these objects.

[LK] The report message in the MPCP refers to such entities. Please see
section 64.3.6.2 for report message format. These counters refer to
that.

[GK] The REPORT message does not refer directly of indirectly to any
such entities. I attached the clause 64.3.6.2. Would appreciate if you
could point where and how this clause refers to count of transmitted,
received, and dropped frames. 
I agree that these are useful parameters. But my point is that they are
already defined and are not EPON-specific. There is no need to duplicate
them in this MIB.

[LK] of course it does not refer to the counters. It refers to the
queues. The counters are an outcome of these entities. 
As indeed you say they are useful parameters. As it is not defined in
the EFM MIB objects I added them to the device MIB objects.

[GK]
I think we have a fundamental disagreement on the scope of this
document. I argue that this MIB should only include EPON-specific
objects, i.e., objects that you would not find in any other MIB. This
would include statistics for MPCP messages, LLIDs, and so on. I believe
that EPON devices should implement multiple MIBs: OAM MIB, Bridging MIB,
and EPON-specific MIB. It seems to me that your approach is to define a
single MIB that would include (or duplicate) all objects that *MAY BE*
used in EPON, even though these objects may already have been defined
elsewhere. 

For example, counters of transmitted, received, and dropped frames per
queue are not EPON-specific. Any port (according to 802.1D) may have up
to 8 queues behind it and would count these statistics. I don't think
these objects belong to EPON-specific MIB.

Before further discussing specific comments, I'd like to ask for a
clarification from the task force on the scope of this document.

[LK] 
We do not have any fundamental agreement. The EPON MIB objects document
is not trying to duplicate all objects from other MIBs and it tries to
fill what the author considered as missing from that for an EPON device.
Such an equipment usually uses many many protocols and higher layer
applications and I believe each one is needed to be covered by its own
MIB objects. So that if it is needed for a device to be a bridge then it
should rely on using the bridge MIB objects. I think that this state of
mind is clearly presented at the beginning of the document. 
Please note however that the EPON has its special properties so if there
is needed a special consideration due to that, then I think it should be
in this MIB document. Obviously we will find it in objects which are on
the boundary of the L2 EPON. That is why considerations and issues so
often come regarding bridge MIB objects.

Please note that some device MIB objects documents of other standards
(not IEEE) used different approach and did try to define much more - for
instance DOCSIS (RFC2669). In such a document you can find for instance
IP addresses for the devices and reference to services. I think I
clearly do not take this approach in this document.

As for your specific point. You are assuming here that the ONU is a
bridge and therefore holding the 802.1D bridge MIB objects. I tried to
avoid the assumption of this specific implementation in the ONU. 
I think that in order to cover the items described in the MPCP spec
which include description of queues for transmission and reporting we
need these counters and can not assume that they are covered by other
MIB objects.

Counters in .1D are defined to reflect operation at the 802.1 level -
counters in the .3 MIBs should reflect behavior at the .3 level.
Although both may define "DropFrames", the dropping point and therefore
the actual semantics of the counter would be different.  I'm not arguing
that EPON needs or does not need a DropFrame counter, only that if it
does define one, it has nothing to do with the 802.1D DropFrame counter.


3.16. The following objects represent non-EPON-specific events and
should be
moved to OAM MIB.   
   eponDeviceSampleMinimum 
   eponDeviceDyingGaspAlarmState
   eponDeviceDyingGaspAlarmEnabled
   eponDeviceCriticalEventState
   eponDeviceCriticalEventEnabled
   eponDeviceLocalLinkFaultAlarmState
   eponDeviceLocalLinkFaultAlarmEnabled
   eponDeviceTemperatureEventIndicationState
   eponDeviceTemperatureEventIndicationEnabled
   eponDevicePowerVoltageEventIndicationState
   eponDevicePowerVoltageEventIndicationEnabled
   eponDeviceGlobalEventState
   eponDeviceGlobalEventEnabled
   eponDeviceErroredSymbolPeriodEventState
   eponDeviceErroredSymbolPeriodEventEnabled
   eponDeviceErroredFrameEventState
   eponDeviceErroredFrameEventEnabled
   eponDeviceErroredFramePeriodEventState
   eponDeviceErroredFramePeriodEventEnabled
   eponDeviceErroredFrameSecondsSummaryEventState
   eponDeviceErroredFrameSecondsSummaryEventEnabled
   eponDeviceOrganizationSpecificEventState
   eponDeviceOrganizationSpecificEventEnabled
   eponDeviceEventControl

[LK] As a general concept we tried to create in the EFM MIB objects a
reflection of the IEEE802.3ah management object keeping as much as we
can aligned to clause 30. There is here an additional section which
refers to device MIB objects. In there I tried to put all things which
are necessary for the management of an EPON device (in an access
network) and was not truly covered by the IEEE802.3ah spec as being a
spec for L2 MAC mainly. So although they are OAM they are in device
level.

[MS] Alarms exist in OAM MIB.

[DR] I agree with Glen and Matt, although reflecting the objects from
the management clause of 802.3ah is not a requirement. I made the
comment at IETF-59 that RFC 3433 (Entity Sensor MIB) would be a better
solution for temperature and voltage indication. 

[LK] Dan. Thanks for the detailed comment. I will verify the coverage
and remove the objects from the EPON device MIB and create a reference
instead.



4) Romascanu, Dan (Dan) [[email protected]]

Technical

T1. As per the revised charter, the new MAU MIB should provide a
different mechanism for defining new MAU types. I recommend that all MAU
extensions be taken out of this document and the new MAU MIB and
extensibility mechanism be referred. This will also lead to changes in
the IANA section (I believe)




Editorial

E1. The IEEE 802.3ah draft references need to be replaced by the name of
the final IEEE standard, which is now available

E2. Badly formatted title in Section 4.1

E3. Section 4.1, row 4 - unjustified capital T

E4. Replace 'OAM EFM MIB' with 'EFM OAM MIB'

E5. Section 4.1 to 4.6 define requirements without using key words such
as MUST and MAY as required by RFC 2119.

E6. The last phrase in Section 5 needs not be introduced, or must be
marked for the RFC Editor to be taken out at standard publication.

E7. Acronyms as MPCP, P2MP, etc. need to be expanded at their first
occurrence (which is I believe in Section 6)

E8. The company designation of the WG chair is Avaya and not Avaya Inc.

E9. Missing period in the DESCRIPTION clause of
eponDeviceObjectFecEnable


[LK] Agreed and All will be done.