Speaking as Chair, I want to highlight two points in your message, Jim, for everyone here.
You are correct, when we first adopted these three documents it was with the objective we would be able to bring them together. I want to add that it was at least a year ago (maybe 2, I have to check) at an IETF where we then decided that we would split the documents and the authors would work together to “split” the overall responsibilities and roles into separate documents. It is this last step that does not seem to have come to consensus. In addition, these documents are now holding up several documents. Taking a step back, we do need to agree on the “rules” for RDAP extensions and the “rules” for versioning. At least, that is what I recall we set as our objectives when we first took on these documents. We have multiple proposed RDAP extensions waiting for these documents so they can make sure to align with our recommendations on these issues. Thank you for stating your position clearly. I’ll have more to say in a separate document about logistics. Jim On 13 Jul 2026, at 10:12, Gould, James wrote: > Jim, > > Can we setup the meeting to ensure that Mario is able to attend in person on > Tuesday? I have a concern that these three drafts are actively competing and > impacting the culture of the working group. We can always agree to disagree > and move forward with complementary solutions, but I don't get a sense that > we're moving in a positive direction. > > I don't believe that the working group should have working group documents > that are in active competition with each other. One option is if we can't > work through the competition issues with the three individual drafts that we > drop all three drafts and regroup with the co-editors on a single draft if a > common set of goals can be agreed to. In the future, for the good of the > culture of the working group, the working group should not adopt drafts that > have any chance of competing. > > These three drafts were adopted by the working group at the same time with > the understanding that we would work together to move them forward. When > rdap-extensions was adopted, I envisioned that it would tackle the forms of > RDAP extensions with guidelines for those forms, in the same way that RFC > 3735 "Guidelines for Extending the Extensible Provisioning Protocol (EPP)" > does for EPP, but it is focused on extension identifiers and extension > versioning that overlaps and competes with rdap-versioning. To make > rdap-x-media-type complementary with rdap-versioning, rdap-versioning made > implementation of rdap-x-media-type a requirement for servers and made it a > choice with the query parameter defined in rdap-versioning for clients. That > complementary element of rdap-versioning is threatened by rdap-x-media-type > only supporting the passing of extension identifiers and not extension > version identifiers (extends the extension identifier to pass additional > versioning information) and section B.2 "Inappropriate Use of Query > Parameters" of rdap-x-media-type attacking the use of the query parameter > defined in rdap-versioning. I've posted on the mailing list that guidance > for the use of query parameters, as a form of extensibility, should be > covered in rdap-extensions and not in an appendix of rdap-x-media-type. > > > Thanks, > > -- > > JG > > > > James Gould > Fellow Engineer > [email protected] > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > > On 7/10/26, 6:07 PM, "James Galvin" <[email protected] > <mailto:[email protected]>> wrote: > > > 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. > > > The Chairs have received requests both on list and privately to please help > facilitate finding a consensus as to how to proceed with these three > documents. > > > https://secure-web.cisco.com/1PkLwDIQWFX1craLvysDu6edCkjyrFJORrig7s-AGFQMAneFyNcEKlADulCcmC6didg-eelFSW4IG0XzuxJhUW7m1TwOHRJzjgwcjG8DzQH-MIzx27xupGexThvKKHCe-ROSeLlDhxQ463NSh8V7zcim1poJWKICqpTSGhpsqK7hZCYYjPtayVKF7F2tUQVPINUVQkNnZsDPwgsjIY7hx9PhoJgzjc46BTwXeaeMGZkuU_4tMZfo8TzkwVpAKx3tTiyVgTM1gEXaTKBrD9Wfx8zAsV6kSxJd3lU-Y3vWjGbU/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-extensions%2F > > <https://secure-web.cisco.com/1PkLwDIQWFX1craLvysDu6edCkjyrFJORrig7s-AGFQMAneFyNcEKlADulCcmC6didg-eelFSW4IG0XzuxJhUW7m1TwOHRJzjgwcjG8DzQH-MIzx27xupGexThvKKHCe-ROSeLlDhxQ463NSh8V7zcim1poJWKICqpTSGhpsqK7hZCYYjPtayVKF7F2tUQVPINUVQkNnZsDPwgsjIY7hx9PhoJgzjc46BTwXeaeMGZkuU_4tMZfo8TzkwVpAKx3tTiyVgTM1gEXaTKBrD9Wfx8zAsV6kSxJd3lU-Y3vWjGbU/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-extensions%2F> > https://secure-web.cisco.com/1ZzdC871DLDgWLJD-yiZeFlC3r50aY1APU08lDsuwTALxs-6QCgsU0GuctffnVo7iveEURpeCDPyshL7WcT1N33qvakmQptdXONE4y5TPI7roysIP7U_ZQNcRfpfbvV2-shfIOw94ApDSpoXc0HUY64v80vQ2s_GV_n9fn3RFIwqKd0Us_9Cuzm9bAUo5Vw5JIuQ_TluxvHQoxgbXcXFdpkiybDkOSVwbPJa6G6TykCfYu0KCYwyX4vQ-CajEckWN1bIc4nWKpWiBpd-BEtw56ieqqO9Xr64eGLjC6fy61nA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-x-media-type%2F > > <https://secure-web.cisco.com/1ZzdC871DLDgWLJD-yiZeFlC3r50aY1APU08lDsuwTALxs-6QCgsU0GuctffnVo7iveEURpeCDPyshL7WcT1N33qvakmQptdXONE4y5TPI7roysIP7U_ZQNcRfpfbvV2-shfIOw94ApDSpoXc0HUY64v80vQ2s_GV_n9fn3RFIwqKd0Us_9Cuzm9bAUo5Vw5JIuQ_TluxvHQoxgbXcXFdpkiybDkOSVwbPJa6G6TykCfYu0KCYwyX4vQ-CajEckWN1bIc4nWKpWiBpd-BEtw56ieqqO9Xr64eGLjC6fy61nA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-x-media-type%2F> > https://secure-web.cisco.com/1Uu0nzHd8i9-853DqGHEYCxoU0kZvgjpgPwYiu1LoMKKzZD8uEAtJltqsjODEhkd_3ApTmk4i6k9uzuPIoEfuRPmJ0rsM7vJNGb_96WBbxgKw1THV6Yx4rcFwnmYoUP4hiyZ0SNFmhMeMMzI7-bPiIpeRgnJ6gBZ0mZF-sNt-BJhtMSmupqqOLOo3jHYUac0CYMg8MH79STUU2FmYkEH-z8yqlB1hs-5bo-EkAimt8e0uffJI4gvZgRzOUn93AudI9PVmawUsFAZkRXNZbywHz5G6ReMoJCUwFwxqFB-cZvk/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-versioning%2F > > <https://secure-web.cisco.com/1Uu0nzHd8i9-853DqGHEYCxoU0kZvgjpgPwYiu1LoMKKzZD8uEAtJltqsjODEhkd_3ApTmk4i6k9uzuPIoEfuRPmJ0rsM7vJNGb_96WBbxgKw1THV6Yx4rcFwnmYoUP4hiyZ0SNFmhMeMMzI7-bPiIpeRgnJ6gBZ0mZF-sNt-BJhtMSmupqqOLOo3jHYUac0CYMg8MH79STUU2FmYkEH-z8yqlB1hs-5bo-EkAimt8e0uffJI4gvZgRzOUn93AudI9PVmawUsFAZkRXNZbywHz5G6ReMoJCUwFwxqFB-cZvk/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-versioning%2F> > > > It does seem that there is an impasse, which is unfortunate. However, The > Chairs remain ever hopeful that we will find a path forward. > > > What we propose is to get the principals together while we are all present in > Vienna. The Chairs will prepare an agenda and review concerns and preferences > among the principals. The objective is for the Chairs to be able to identify > the rough consensus, if not full consensus, in the room. > > > The Chairs will provide a summary of the discussion to the list and assert > the identified consensus for review by the working group. we will be looking > for objections from other working group members and, of course, ask that if > you object you provide a technical explanation with new information to > support it. > > > The goal is to finalize these documents, or to indicate explicit next steps > to be completed that will finalize these documents. They have been on our > milestone list for years and worse they are about two years overdue. > > > The only meeting slot that we have available to do this is Wednesday morning, > 22 July, in the first time slot of the day 9am-11am local time. Our AD has > offered the IESG meeting room for this discussion and it is currently > reserved for us. Sorry folks, there is no remote participation available but > we believe this will be okay as we will be reporting to the working group for > the final decision. > > > Although anyone is welcome to join, the principals the Chairs would like to > be present for this discussion are as follows. > > > Jim Gould > Tom Harrison > Paweł Kowalik > Mario Loffredo > Andy Newton > Jasdip Singh > > > We should appreciate if those on that list would indicate if they are > available for this discussion. As long as we have a quorum, as determined at > the discretion of the Chairs and the AD, we will have the discussion and > report to the mailing list. > > > If for some reason this meeting cannot happen, then the Chairs will organize > an interim meeting in the weeks following the IETF. Of course, we’d prefer > not to do this so please do try to accommodate this meeting in your busy > schedules. > > > Thanks to all! > > > Jorge, Antoin, and Jim > > > _______________________________________________ > regext mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
