regext

Summary

This meeting of the regext working group focused on administrative matters and a discussion about implementation requirements for documents. The main discussion revolved around whether the working group should formalize requirements for implementations before advancing drafts to proposed standard status, drawing comparisons with other IETF working groups like CiderOps and IDR. A key consideration was balancing the need for implementation experience with the desire to avoid creating unnecessary barriers to participation and innovation. The meeting also touched on the role of the wiki in documenting implementations and process issues around stalemates.

Key Discussion Points

Implementation Requirements:
- A proposal was made to require at least one client and one server implementation before a draft could be advanced to proposed standard status.
- Concerns were raised about the small number of implementers in the group, particularly for ARDAP clients.
- The potential for new requirements to deter participation and encourage proprietary extensions was discussed.
- The differences between client/server implementations vs. two interoperable independent implementations was discussed.
Experimental RFCs:
- The possibility of publishing documents as experimental RFCs when consensus on implementation is lacking was considered.
- The benefits of experimental RFCs in retaining IETF change control were noted.
- Concerns were raised that designating documents as "experimental" could deter adoption.
Implementation Wiki:
- The potential for using the working group wiki to document implementation status and experience was widely supported.
- The ease of updating the wiki by implementers was highlighted as an advantage.
Deleg Relationship:
- The activities of the Deleg working group with potential impact on RegExt were reviewed.

Decisions and Action Items

Decision: No changes will be made to the formal implementation requirements for the working group at this time. However, targeted implementation requirements may be considered on a case-by-case basis.
Action Item: The Chairs will work to promote greater use of the working group wiki to document implementation status and experience.
Action Item: The chair will add to the Regext "toolbox" the opportunity to consider an experimental RFC or external project if stalemate occurs within the working group.
Action Item: The Chairs will publish a summary of decisions and discussion on the mailing list for review by remote participants.

Next Steps

The working group will continue its discussion of ARDAP considerations on Wednesday.
The Chairs will follow up on the action items outlined above.

Session Date/Time: 24 Jul 2024 20:00

regext

Summary

The regext working group held a meeting to discuss several technical topics related to EPP and RDAP. Key discussions revolved around internationalized email addresses, the adoption of Domain Connect as a standard, a RESTful EPP proposal, redaction in ARDAP, contact objects, versioning and signaling in extensions, and IDN variance. The group considered the scope of existing work, potential new work, and how to best proceed with standardization efforts.

Key Discussion Points

Internationalized Email Addresses: The working group discussed the challenges of progressing the internationalized email addresses draft after it was remanded back from the IESG. A simplified draft proposal was presented, focusing on not updating RFC 5733 and allowing for one additional email address (ASCII or UTF8). Concerns were raised about requiring both ASCII and UTF8 addresses.
Domain Connect: Pavel presented an update on Domain Connect, an application-level protocol for provisioning DNS records, highlighting its widespread adoption and the need for standardization. There was discussion on where this work best fits within the IETF, considering both regext and DNSOP.
RESTful EPP: Martin presented the RESTful EPP proposal, aiming to map existing EPP functionality to a RESTful API with JSON support. The group debated whether this constitutes a new provisioning protocol or simply a different transport for EPP. There was also a discussion on supporting both XML and JSON, with some favoring focusing solely on JSON.
ARPDAP Redaction (RFC 9537): Andy presented limitations and challenges encountered while implementing RFC 9537, particularly regarding JSONPath, redaction by removal, and the complexity for clients. The group discussed whether to pursue a BIS draft or focus on addressing errata.
Contact Objects: Discussed different approaches to contact objects, including JSContact and Simple Contact. The group considered the benefits and drawbacks of each approach, as well as the possibility of letting JSContact move forward as an experimental protocol.
Versioning and Signaling in Extensions: Discussed the need for guidance on versioning and signaling for ARDAP extensions.
IDN Variance: Update was given on the joint effort between ICANN TechOps and the IETF. A draft proposal is being worked on to handle IDN variance and there will be proposed extension for both EPP and ARDAP to be presented to the working group.

Decisions and Action Items

Internationalized Email Addresses: The working group decided to wait for the new simplified draft to be published and then revisit the technical discussion.
Domain Connect: There was a sense of support for the regext working group to be a home for the work but the final decision is pending further discussion with the area director and chairs from other working groups. Howell is to ask for working group adoption via the mailing list.
RESTful EPP: The working group had divergent opinions as to whether this constituted a new provisioning protocol or simply a new transport. More discussion will be needed but with engagement and excitement for the draft the decision was to move it to the mailing list.
ARPDAP Redaction (RFC 9537): The working group acknowledged the implementers' experience and committed to further evaluation on the mailing list. Options include a BIS draft or focused errata.
Contact Objects: The working group tentatively decided to let JSContact move forward as an experimental protocol, excluding the signaling aspects.
Versioning and Signaling in Extensions: The working group agreed that each of the three documents should proceed and develop for a solution.
IDN Variance: No action item yet but expected in the near future.

Next Steps

Authors to provide a new simplified draft for Internationalized Email Addresses to the mailing list
Howell to ask for working group adoption of Domain Connect on the mailing list
Further discussion and consideration of the RESTful EPP proposal on the mailing list, focusing on its classification as a new protocol or transport for EPP.
Discussion of potential errata or a BIS draft for ARDAP Redaction (RFC 9537) on the mailing list
Each of the authors for Contact Object, Versioning and Signaling Extensions to progress each of their drafts on the mailing list for a solution
The IETF and ICANN team will publish a draft and present it to the working group for adoption.