Hi < responsible ad hat on> On Wed, Jul 10, 2024, 3:55 PM James Galvin <gal...@elistx.com> wrote:
> I’m happy to provide some during the “admin” portion of our meeting for a > discussion of this. If you want to kick this off that’s great too. > > As co-Chair, I will observe only that if you want a “standards track” > document then whatever discussion is happening or needs to happen in REGEXT > is appropriate. In fact, if that results in delay, I would be inclined to > lean on the side of that being a good thing since I would hope that means > the group is looking at interoperability issues. If not, then that’s > something we should address on a case by case basis. > > As far as the working group blessing something as “experimental” or > “informational”, I’m not inclined to support that. I’ll remind folks that > both EPP and RDAP extension registries are open, meaning anyone can publish > a document describing their extension and get it listed. You don’t need > any special permission. > For folks interested in learning more about why you might choose a specific intended status as a working group, please see: https://www.ietf.org/process/process/informational-vs-experimental/ It's true that the bar for review is higher, for proposed standards, as is the expectation of good interoperability, multiple independent implementations, etc... For certain extensions, I can imagine that a successful experimental document might be published faster, and once more implementations exist, documenting a proposed standard might help address any gaps that were exposed by implementation experience. You have to be careful attempting to update a proposed standard with an informational or experimental document ( or even a cross stream document ). TLDR, there are great ways to use informational documents to pave the way for proposed standards, but how this gets applied can vary across areas or working groups. > Of course, getting the working group to acknowledge it does mean the IETF > gets change control, and perhaps that’s a desirable characteristic and thus > adding this process option to how we work would be good thing. > > So, let’s plan to talk about it at IETF120. > Looking forward to this discussion. These decisions are for the working group, and chairs to make, but I'm happy to help you consider how changes might impact our process. > Thanks, > > Jim > > > > On 14 Jun 2024, at 6:22, Andrew Newton (andy) wrote: > > > 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]. > > > > -andy > > > > > > [1] https://datatracker.ietf.org/wg/mailmaint/about/ > > [2] https://wiki.ietf.org/en/group/sidrops > > [3] https://wiki.ietf.org/group/idr > > [4] https://wiki.ietf.org/group/regext > > > > > > _______________________________________________ > > 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 >
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
