Hi, +1 for optimizing the process where possible.
But i wonder why this new process is limited to RDAP extensions only? What is the distinction between RDAP extensions and other work done in REGEXT such as EPP extensions? - Maarten > Op 17 jun 2024, om 16:25 heeft Hollenbeck, Scott > <shollenbeck=40verisign....@dmarc.ietf.org> het volgende geschreven: > >> -----Original Message----- >> From: Andrew Newton (andy) <a...@hxr.us> >> Sent: Friday, June 14, 2024 6:23 AM >> To: regext@ietf.org >> Subject: [EXTERNAL] [regext] using experimental to move items forward >> >> Caution: This email originated from outside the organization. Do not click >> links >> or open attachments unless you recognize the sender and know the content is >> safe. >> >> Hi all, >> >> When I look at the DNSOP working group I see items like CDS bootstrapping >> and generalized NOTIFY are nearing completion. They have even spun off >> another working group recently. Comparing that to the progress here, it seems >> that in REGEXT we don’t make as much progress. >> >> Given the different perspectives, I’d like to propose a change in our working >> group process inspired by mailmaint [1], sidrops [2], and idr [3]. The basic >> proposal is to adopt the SIDROPS/IDR thresholds but with a lower bar for all >> RDAP extensions: before publication on the standards track there must be at >> least one interoperable server and client implementation documented with an >> implementation report published on the working group wiki [4]. Otherwise >> the extension may be published as experimental with the proviso that it could >> be put back on the standards track once interoperability between a client and >> a server is documented. >> And in special circumstances, the chairs could waive this requirement. >> >> Note that in the SIDROPS and IDR examples above, there's nothing in the >> working group charter that requires these interoperable implementations. >> We might be able to do this in REGEXT without a charter change, too. >> Following their lead, we would publish this proposal to the REGEXT wiki [4]. > > [SAH] This proposal is worth discussing. Can we put it on the agenda for > IETF-120? > > Scott > _______________________________________________ > regext mailing list -- regext@ietf.org > To unsubscribe send an email to regext-le...@ietf.org _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
