Re: [RFC] SNMP MIB reset function

On 17/03/2026 8:14 am, Steven Wilton wrote:

On 17/03/2026 4:26 am, Tim Düsterhus wrote:

Hi On 3/16/26 06:03, swilton@fluentit.au wrote:

I believe that the process is to send a message to the list, and gauge whether there is positive feedback before creating the RFC for voting.  Please let me know if I should create the RFC first? The PR is here: https://github.com/php/php-src/pull/21452/changes

I suspect that SNMP is such a specialized and rarely used extension that folks will be unable to meaningfully discuss an RFC for this feature - at least not without you doing quite a bit of explaining. This might be case where it's best to just find an informal agreement with you providing a well-tested and well-explained patch rather than doing a full RFC.

I'm very happy to avoid the RFC process, and happy to explain/discuss the changes :) On the topic of the RFC - @devnexen has suggested that a RFC is the correct process for this change.  I have no issues with following whatever process is required to get this considered, but if most maintainers won't be too concerned about changes to the module I am interested who I should be discussing with that does know the code well enough to make the decision on including it or not.

I have submitted a second PR below to add support for other SNMPv3 security protocols, and am wondering if I do end up going down the RFC route whether it is best to merge everything into a single PR for "SNMP changes", or if distinct changes should have their own PR with an associated RFC? https://github.com/php/php-src/pull/21451 While considering the previous question, I would like to add that I would also like to add more options to control the output format.  These would just be duplicating the code for enum_print, quick_print and oid_output_format.  The question here is whether it should be a new request with a new RFC, or if this is trivial enough to be considered independently. regards Steve