Markdown Version | Session Recording

Session Date/Time: 28 Jul 2022 21:30

regext

Summary

The regext working group session focused primarily on two key areas: an update on existing documents, particularly the Registration Data Dictionary, and a significant discussion on RDAP extensions and identifier conformance. The latter involved addressing an impasse on the mailing list regarding how extensions should be identified and whether versioning mechanisms should be standardized. The chairs presented a proposal to resolve this, emphasizing adherence to existing RDAP Internet Standards which prioritize uniqueness and optionality of extension identifiers, rather than introducing a versioning mechanism at the protocol level.

Key Discussion Points

• Administrative and Process:
  • Welcome and standard IETF Note Well and Code of Conduct reminders.
  • Minute Taker: Rick Wilhelm volunteered to take notes.
  • Document Management: Chairs reiterated the importance of securing at least five independent reviewers for documents during last call and obtaining document shepherds early in the adoption process.
• Document Status Updates:
  • Published Documents: None since the last meeting, but several are near completion.
  • Internationalized Email Addresses in EPP Extension: Currently with IESG, near release to RFC Editor queue. Significant IETF last call discussions were successfully addressed.
  • Simple Registration Reporting: A revised document exists; publication is on hold, pending other documents.
• Registration Data Dictionary (draft-ietf-regext-data-dictionary):
  • Update: Slow progress, main feedback centers on concerns that the draft might implicitly drive policy, despite intentions. Support from RIRs who see value in a common data dictionary.
  • Chairs' Proposal: Add explicit language to the introduction and abstract clarifying that the document is not intended to promote policy development but to provide broadly applicable common terms.
  • Discussion - Policy Concerns:
    • Richard (PIR) expressed concern that the document's definitions overlap with ICANN contracts, and RFCs are often used by ICANN to anchor technical terms. He worried that a "malleable" data dictionary, curated by an expert group, would undermine contractual certainty for ICANN contracted parties.
    • Steve (Co-chair) clarified that the document intends to provide a solid, neutral basis for definitions, similar to how ICANN already references RFCs. He emphasized that RFCs, once published, are immutable, and the envisioned expert group would curate new entries and maintain sanity, not arbitrarily change existing definitions.
    • George Michaelson (APNIC) reinforced that RFCs are substantively immutable post-publication, addressing the concern about a "malleable" document.
    • Antoine (Co-chair) sought clarification that definitions within the data dictionary would remain stable once established. Steve confirmed the expert group's role is to ensure stability and curate new additions.
• RDAP Extensions and Identifier Conformance (Major Discussion):
  • Context: Extensive mailing list discussion has led to four RDAP documents being held back due to a lack of consensus on how to handle extensions and their identifiers.
  • Chairs' Proposal to Resolve Impasse:
    • Focus: Not to debate the technical merits of specific proposals (Options 1, 2, 3), as all are technically valid starting from scratch, but to resolve the current lack of consensus given existing Internet Standards.
    • Core Principle: Adhere to the existing RDAP RFCs (9082, 9083) which define extension identifiers as unique strings that must be unique against all other identifiers in the registry. Uniqueness and optionality are the critical characteristics.
    • Metric: Protocol behavior and performance are the primary metrics, not programming effort/complexity.
    • Versioning: The chairs assert that versioning is not an integral part of the base RDAP standard. While an individual extension could define its own versioning mechanism (similar to "Option 3"), it should not be a requirement or managed by the core RDAP protocol or its extension registry.
    • Conclusion: There is no sufficiently motivated or consensual technical reason to change the existing Internet Standard regarding unique, opaque extension identifiers.
  • Discussion on Proposal:
    • Jim Gould: Supported the proposal. Emphasized that versioning remains an important element for future consideration and specifically for policy identifiers (e.g., RDAP profile identifiers).
    • Scott Hollenbeck: Supported the proposal. Suggested errata for RFC 9083:
      • Change "lunic" to "lunic level zero" in examples for consistency (RDAP itself is "RDAP level zero").
      • Strengthen the "hint" wording regarding identifiers in the rdapConformance data structure for clearer interpretation.
    • Clarification on rdapConformance: The rdapConformance data structure's purpose is to inform clients which extensions a server supports or is represented in a response, allowing clients to understand how to process unexpected data structures.

Decisions and Action Items

• Decision (Chairs' Proposal): The working group will adhere to the existing RDAP Internet Standards (RFCs 9082/9083) regarding extension identifiers, focusing on their uniqueness and optionality as opaque strings. Versioning of extensions will not be addressed at the base protocol level or in the extension registry at this time.
• Action Item (Chairs): Send a closing message to the regext mailing list summarizing this meeting's discussion and the chairs' proposal, seeking final working group consensus on the agreed approach.
• Action Item (Scott Hollenbeck): Upon confirmation of working group consensus, Scott Hollenbeck will draft and submit errata for RFC 9083 to address consistency in examples (e.g., "lunic" vs. "lunic level zero") and clarify the "hint" wording regarding rdapConformance.
• Action Item (Authors of held-back documents): Authors of the four RDAP documents currently held back should review their drafts to ensure alignment with the unique identifier approach, make any necessary editorial changes, and prepare them for progression.

Next Steps

• The regext mailing list will be used to finalize consensus on the chairs' proposal.
• Scott Hollenbeck will proceed with drafting RFC 9083 errata as agreed.
• Dependent RDAP documents (e.g., redacted draft, which has a dependency on a JSON Path RFC expected in November) will be progressed.
• Future work on versioning of extensions or version negotiation could be initiated as a separate discussion if motivated by the working group.