On Mar 27, 2017, at 3:03 PM, Vincent Bernat <ber...@luffy.cx<mailto:ber...@luffy.cx>> wrote:
❦ 27 mars 2017 19:26 GMT, Jeff Haas <jh...@juniper.net<mailto:jh...@juniper.net>> : To your relevant next point: If the junos mib is in error, what to do about it? Very likely fixing the issue will cause mass amounts of unhappiness as people's existing scripts and mib walking code fails due to the new sub-indices. do the right thing, create misery? Leave it as is, document that it's wrong? I totally understand it's not possible to just fix the issue. Your best bet is to convert the draft into a RFC and fix the issue here! ;-) It's technically possible to fix and use a cli knob to give compliant behavior. But then someone (likely me, based on on how bug work gets email dispatched) gets to own questions about that workaround for a decade. (Did I mention I didn't like SNMP?) Otherwise, use another table with the correct indexing? jnxBgpM2PeerTableNew := jnxBgpM2PeerData.2? Dunno if it's worth your time. I think you misunderstood my original point: https://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-15 Note that the draft is long expired. It was impossible to get vendors to want to implement it. Since *becoming* one of those vendors, I got some minor support to get the code restructured for the IETF MIB from an intern, but... well, it was intern code and didn't get through full commit criteria. If this is something the operational community has passion for, it could be done, but it'd normally get done through the usual product manager process. Or, if I get supremely bored and have copious spare time (ha!) I may just finish it. But I've been saying that for a few years now. -- Jeff _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
