ITNM must cover Juniper MIBs for proper BGP status polling event supression

The reason for a need to open a new RFE is:

For the RFE that was delivered previously (TNMGR-I-140) for "Use ENTITYID instead of MAINNODEENTITYID for BGP status polling", in the mentioned scope (which was informed to customer earlier via email), it was clearly mentioned as follows:

1. BGP policy is: "bgpPeerState" and its associated MIB labels are: "bgpPeerState", "bgpPeerRemoteAddr", "bgpPeerRemoteAs"
2. BGP status related OIDs are: 1.3.6.1.2.1.15.3.1.2, 1.3.6.1.2.1.15.3.1.7 and 1.3.6.1.2.1.15.3.1.9
3. Example "LocalPriObj" field of the event is: 'bgpPeerEntry.10.11.20.2'
4. In this LocalPriObj, in the INDEX(which is after "bgpPeerEntry.") we can see that it has only one value which is "bgpPeerRemoteAddr".
5. Here, all the above shows that we targeted for delivering the support for STANDARD BGP MIBs:
6. Name of the STANDARD BGP MIB is: RFC1657.mib/BGP4-MIB.mib
7. The above mentioned OIDs are from these STANDARD MIBs. MIB Tree for this is: 1 (iso) -> 3 (identified-organization, org, iso-identified-organization) -> 6 (dod) -> 1 (internet) -> 2 (mgmt) -> mgmt -> 1 (mib-2, mib) -> 15 (bgp) 3 (bgpPeerTable) -> 1 (bgpPeerEntry) -> 2 (bgpPeerState)
8. This means that Juniper MIBs was NOT in the scope of that RFE, whose details are as follows:
   1. MIB Name is: BGP4-V2-MIB-JUNIPER.mib
   2. MIB Labels are: jnxBgpM2PeerState, jnxBgpM2PeerRemoteAddr, jnxBgpM2PeerRemoteAs
   3. Example "LocalPriObj" field of the event is: jnxM2BgpPeerEntry.15.2.32.1.6.124.40.112.255.254.0.0.0.0.0.0.0.2.2.32.1.6.124.40.112.255.254.0.0.0.0.0.0.0.1
   4. Here, in the above LocalPriObj, in the INDEX (which is the part after "jnxM2BgpPeerEntry.") we can see multiple values (jnxBgpM2PeerRoutingInstance, jnxBgpM2PeerLocalAddrType, jnxBgpM2PeerLocalAddr, jnxBgpM2PeerRemoteAddrType, jnxBgpM2PeerRemoteAddr)
9. Hence, to cover the Juniper MIBs, additional changes are required. Hence as separate RFE is required.