03-07-2025 08:06 AM
Although Cisco does not promise any target version or date, the fix for his is targeted in 17.19.1.
The goal is to remove false positives of field tampering on reload. On a field deployed IR8140 this is a big concern and not analogous to previous CGR1240 traps. The erroneous traps propagate to Cisco IoT Field Network Director and Operators cannot tell this is from a reload vs someone tampering with device and removing/inserting hardware.
The Bug ID CSCwn98622 text neither clearly states this nor does the severity indicate the importance of this issue.
Thus the post here to clarify.
03-07-2025 11:33 AM - edited 03-07-2025 11:35 AM
Note the Severity level listed for the bug ID: "6 Enhancement". This means that when a DE (Development Engineer) analyzed root cause, they determined that the function was actually working as originally designed. This does not mean that the behavior is ideal nor that the original design was not somehow flawed, it just means that the DEs do not consider this to be a bug, per se. Hence, it is listed as a request to enhance the original design and implementation. This also means that no DE resources are being assigned to fix it as a "bug", as DE bug-fix resources are prioritized to fix Sev 1/2 defects (Sev 3 might get some attention if a big customer pushes for it). DE resources to implement enhancements are prioritized separately from those to fix bugs.
How can you get this moving and get DE resources assigned to an enhancement request? Contact your Cisco account team (or Cisco reseller if that is how you purchase Cisco products) and stress how important the resolution of this issue is to your future business with Cisco. With Cisco, money talks so Product Managers prioritize the implementation of enhancements based on the incremental sales revenue projection associated with each enhancement request (it is best if you can tie this enhancement to an upcoming purchase). Add your voice/dollars behind this request, but the brutal truth is that if there is no appreciable revenue associated with an enhancement, it will never get implemented as there are just not enough DE resources to work on every request.
05-12-2025 03:24 PM
Based on recent Cisco discussion, this is targeted for 17.18.1a as well.
05-13-2025 06:51 AM
The magic word in Cisco-speak is "committed", as "targeted" is a soft promise and means the code might, or might not, get committed into the release and usually represents the earliest release where the code can be committed.
Every release will have a commit window, the time period during which the code is open to having changes committed into it. If you want to pin down this enhancement request further, ask your Cisco rep if it has been committed into 17.18.1a. If it has not, ask when the commit window closes. Committing code after the window closes is not impossible, but close to it and often requires a de-commit of something else in order free up DE and DevTest resources.
05-13-2025 10:26 AM
Yep, you said it there. "pin down" and "Cisco release" are diametric opposites. LOL But even the fuzzy logic is nice when planning where to go next. Hope it is helpful to the community.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide