Markdown Version | Session Recording

Session Date/Time: 06 Nov 2025 14:30

RPP Session Minutes - IETF 124

Summary

The RPP Working Group met at IETF 124 to review progress on its core deliverables. Key discussions revolved around the requirements document, updates from the hackathon and Tiger team, and initial drafts for architecture, core protocol, DNS data modeling, and abstract data objects. The group made decisions on several requirements, acknowledged open issues, and planned for further review and consensus calls. The need for clear extensibility and alignment with existing EPP practices while not being constrained by them was a recurring theme.

Key Discussion Points

• Deliverables and Milestones: The working group aims for consensus on the requirements document this month, followed by core architecture and extension mechanisms by next August, and domain name provisioning specifications with EPP/RPP mapping six months after that.
• Requirements Document Review: The draft-ietf-rpp-requirements-01 was presented, incorporating feedback from IETF 112 and mailing list discussions.
  • Resolved Issues:
    • Data Validation: Decision made to go with strict validation.
    • Response Caching: Deemed useful and will be included.
    • Historical Data: Not a "MUST" requirement, can be an optional extension.
    • Bulk Requests/Responses: Identified as a requirement.
    • Password Update: Not a requirement, can be an extension.
    • Transaction Information in Headers: Will be included.
  • Open Issues: Client data omission (considering optional fields with profiles) and the need to support profiles require further input.
  • Other Updates: Support for thick/thin registry models, specific sections for host/domain/contact objects, future handling of delegation with DELAC, and enhanced EPP Poll command equivalent.
• Hackathon Recap:
  • Explored data modeling for RPP, specifically considering integration with DENOS and DELAC.
  • Discussed updating parent-child relationships (arrays) using "labeled aggregation" inspired by EPP.
  • Considered placement of TLD information in URL structures for multi-TLD deployments (in path vs. before path).
  • A front-end prototype for an RPP backend was demonstrated.
• Tiger Team Recommendations:
  • Analyzed 67 EPP extensions, identifying common patterns.
  • Recommended RPP Extensibility: Support for object, response, command type, function, operational practice, object property, and innovation value space extensions.
  • Recommended NOT to Support: Authorization information, key-value pair, and transport mapping extensions.
  • High-Level Recommendations: Process information, status information, extended error handling (codes, clear messages), clear mechanisms for new objects and command types.
  • Object-Specific Recommendations: Generic interface for provisioning zone resource records, extensible name server representation (e.g., NSETs), and diverse contact types.
  • EPP Extensions to RPP: Recommendations to embed into core RPP (e.g., DNS, Login security), port directly (e.g., Launch phase, Change poll), or ensure RPP design supports them (35 identified extensions).
• Architecture Document (draft-ietf-rpp-architecture):
  • Adopted by the working group.
  • Describes architectural layers and design principles, splitting HTTP layer concerns into reuse and profiling.
  • Defined principles for RPP codes in relation to HTTP codes.
  • Discussion: Questions were raised regarding the appropriate document track (Informational vs. Proposed Standard) for the architecture document given charter wording.
• Core Protocol Document (draft-ietf-rpp-core):
  • Initial solutions for requirements were presented.
  • RPP Code Header: Proposed a single RPP code header for backwards compatibility with EPP, using a new leading digit (0 for EPP codes, 1 for RPP codes).
  • Object Authorization: Proposed a custom HTTP-like header for object authorization, distinct from API authentication.
  • Non-CRUD Processes: A generic interface separating process information from object data, with a Location URI in responses for status tracking.
  • Availability Check: A /availability path segment for checking object registration status, supporting HEAD for quick true/false and GET for detailed information (e.g., pricing, rules).
  • Error Handling: Utilizes RFC 9457 Problem Details for standardized error responses, with discussion on supporting multiple errors within a single response.
  • Discussion: The use of HTTP headers for application data and the potential for an IANA registry for RPP result codes were raised. Debate on whether to support multiple error codes in Problem Details, with participants noting EPP typically returns one.
• DNS Data Modeling Document (draft-ietf-rpp-dns-data):
  • Aims to represent DNS RFCs in JSON structures for RPP.
  • Core Challenge: How to handle host objects and control delegation records, particularly in light of DELAC which has no glue concept.
  • Proposed Approaches: Domain object full control, host object full control, a separate structure for shared control, or templating (like Domain Connect).
  • Discussion: A sense of those present indicated that the group should not be bound by EPP semantics and consider new object types (e.g., a "delegation object" managed by name server operators) if current concepts are inadequate.
• RPP Data Objects Document (draft-ietf-rpp-data-objects):
  • A new draft defining abstract data elements and operations, independent of a specific representation (e.g., JSON).
  • A planned IANA registry for RPP data objects was outlined.
  • Key Concepts: Data element semantics (name, type, cardinality, mutability), a basic CRUD interface for operations, normative primitive data types, and vocabulary for relations (aggregations, compositions, "labeled aggregations").
  • Core Data Objects: Domain, Contact, Host, and Organizational objects are envisioned, building on EPP RFCs and Tiger team recommendations.
  • Discussion: The importance of supporting references to external registries (e.g., business registers) and the ability to express data verification status was highlighted. The author confirmed the document uses a strict template for object definitions and supports extensibility. There was discussion on whether to split the document into multiple, smaller drafts for easier collaboration and review.

Decisions and Action Items

• Requirements Document:
  • Decision made for strict data validation.
  • Decision made to include response caching.
  • Decision made to require bulk requests/responses.
  • Decision made to include transaction information in headers.
• Action Item (Working Group Members): Review draft-ietf-rpp-requirements-01 to provide feedback ahead of the Call for Consensus.
• Action Item (Pavel): Incorporate the remaining Tiger team recommendations into the requirements draft.
• Action Item (Martin): Research industry best practices for using HTTP headers for application data. Investigate the feasibility and utility of an IANA registry for RPP result codes. Gather feedback on the need for multiple error codes in Problem Details.

Next Steps

• Requirements Document: The chairs will work to close all existing open issues and then issue a Call for Consensus on draft-ietf-rpp-requirements-01, aiming to achieve consensus before the next IETF meeting. Once consensus is reached, the document will be "parked" to allow work on the core protocol.
• Tiger Team Recommendations: Remaining recommendations will be incorporated into the requirements document.
• Architecture Document: Will be reviewed again after the requirements milestone, and more full reviews from the working group are encouraged. Discussion on its eventual publication track (Informational vs. Standard) will continue.
• Core Protocol Document: The author will align the core document with the requirements and Tiger team recommendations, then seek working group adoption.
• DNS Data Modeling: Further work is needed on how to manage delegation records, potentially exploring new object types.
• RPP Data Objects Document: Early feedback is sought on draft-ietf-rpp-data-objects-01, with an update to 02 planned for the mailing list. The author welcomes contributions to the draft ahead of asking for adoption.
• General: Continue to focus on extensibility and reuse of existing best practices from HTTP APIs while defining RPP-specific mechanisms.