Hi Jim,I am not physically on site, therefore many thanks for setting up the Zoom-Option for participation in this relevant meeting.
Kind Regards, Pawel On 17.07.26 16:50, James Galvin wrote:
Thank you Pawel for clearly stating your position. Please confirm, are you physically present? I currently understand that you’re not, so we may have to setup something ad hoc to include your participation. Thanks, Jim On 14 Jul 2026, at 11:55, Pawel Kowalik wrote:Hi Chairs, I would also prefer to participate in the discussion. 2-4pm on Monday would be possible. I have a clear view aligned with WG position from several meetings ago to close draft-ietf-regext-rdap-extensions first. This draft shall give a clear guidance, how extensions shall be written and what are the expectation of clients and servers with STD95-based RDAP deployment - without any extensions. This includes a clear guidance as under what conditions the extension identified MAY remain the same if an extension specification is being updated, and what conditions determine that the identifier MUST change. The pivotal question remains, what the conditions are. A part of the question is when to consider a specification update as not back compatible. I think here we have a good understanding, drafted in draft-ietf-regext-rdap-extensions, what kind of changes we consider breaking and which back compatible for clients operating pure STD95 protocol without extensions. As to when the identifier MUST change, there seem to be 3 options on the table, each with different degree of rigidity: 1) extension identifier MUST update on every specification change - IMHO too restrictive, not really aligned with REST API approaches, burden for both clients and servers in migration paths. Also not in line with spirit of rfc9083 2.1. 2) extension identifier MUST update only on not back compatible specification change - less restrictive but coarse-grained. Not allowing space of other mechanisms of signalling changes. Easy to implement for the client though. 3) extension identifier MUST update only on not back compatible specification change, unless extension offers own signalling of compatibility within its own extension identifier namespace. draft-ietf-regext-rdap-versioning MAY be a solution of choice for all such extensions to set upon in a standardised way. It shall remain open that there might be other methods. The called out "solution, offered by Pawel" was in fact the approach 2, however I see the arguments about too coarse-grained versioning consequences of it, therefore I can also agree to go with 3. The choices imho shall be taken regardless of existence or compatibility of further drafts in the discussion, as draft-ietf-regext-rdap-extensions shall lay down higher level principles that the other drafts in question shall not gate. That being said I think we shall finalise draft-ietf-regext-rdap-extensions with full focus not waiting for any of the drafts down the stream. Also limit the influence of those drafts specific solutions in the discussion to absolute minimum. To the other questions: - draft-ietf-regext-rdap-versioning and draft-ietf-regext-rdap-x-media-type have both mechanisms for signalling of requested representation (content negotiation). I still hold to my opinion that: a) 2 ways of signalling in "versioning" draft are not necessary and that we shall have only one way described in one draft. "media type" draft is my clear preference as using standard http content negotiation. b) "media type" shall foresee not only requesting extensions by a list of ext. identifiers, but also their versions in opaque way - so that "versioning" draft can fill in on one side, but other versioning mechanisms can use same way. This is only useful if we go for option 2 or 3 from above. More utility with 3. Kind Regards, Pawel On 14.07.26 14:43, Andy Newton wrote:Hi Chairs, Regarding the question of what is needed: We need to go back to the agreement [1] made in a meeting at the Montreal IETF between the authors of these documents and interested parties. At that meeting, everyone agreed to a simple solution, offered by Pawel, that is compatible with how RDAP is deployed today. The crux of the current disagreement is compatibility with RDAP as it is deployed today. While the versioning draft has been a moving target -- now on its third redesign -- each iteration has NOT been compatible with currently deployed RDAP. Regarding logistics: I am available during those times though would prefer an evening meeting because IETF sessions do get moved around. Also, Pawel has been very involved in these discussions and played the part of mediator. It would be unfortunate if he could not be on equal footing in these discussions. Absent an immediate need to meet a deadline, I think a fast-follow, virtual interim meeting would serve us well. -andy, no hats [1] https://mailarchive.ietf.org/arch/msg/regext/sN-ar484f9n5YgXkTauq7CE6xMk/ On 7/13/26 11:43 AM, James Galvin wrote:To the principals listed below, please confirm if you wish to be present for the discussion the Chairs are trying to organize. To everyone in the working group, the question the Chairs need to answer is, “What is needed to move these documents forward?” It may help to think of this as a pre-working-group-last-call question. For anyone who has a question, concern, or a position regarding these documents, please do send a note to the list with your statement. One email message per person, please. Do not respond to each other. The Chairs will review all messages and frame the discussion to be had and propose either a consensus or a specific question for consideration after the IETF. Again, the goal is to finalize these documents so we can quickly move forward a number of other documents that are dependent on them. LOGISTICALLY, it seems that Wednesday morning is not going to work for our ad hoc meeting. Best bets are currently Monday Session III (2-4pm timeslot) or in the evening on Monday or Tuesday. It would be helpful if the principals would indicate their availability in those times. Thanks to all. See you next week in person. Jorge, Antoin, Jim On 10 Jul 2026, at 18:06, James Galvin wrote: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://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/ https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-x-media-type/ https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-versioning/ 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] To unsubscribe send an email to [email protected]_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
