Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130382
Message-ID: <de84f73d-b1b5-4cec-8fda-082063da539f@fluentit.au>
Date: Tue, 17 Mar 2026 21:32:29 +0800
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] SNMP MIB reset function
To: internals@lists.php.net
References: <5a2-69b78f00-11-50bc7700@253019388>
 <1c9534ff-d8c6-4939-a6f2-85a4c547ac0b@bastelstu.be>
 <d9858b1f-db86-4281-ad11-84246ca599ff@fluentit.au>
Content-Language: en-US
In-Reply-To: <d9858b1f-db86-4281-ad11-84246ca599ff@fluentit.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: swilton@fluentit.au (Steven Wilton)

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