Session Date/Time: 08 Oct 2024 15:00

DELEG

Summary

The DELEG WG held an inter-meeting session to discuss the current requirements draft (draft-ietf-deleg-requirements-01) and address ongoing conversations from the mailing list. The chair provided an overview of requirements categorized by the level of discussion they had received. Key technical points revolved around the security model (DNSSEC), backward compatibility, the role of parent and child zones in delegation information, the clarity of "operator" definitions, and the concept of "provisioning" within the protocol. The session aimed to refine the requirements to prepare for a new draft revision and facilitate closing the requirements discussion at the upcoming IETF meeting in Dublin.

Key Discussion Points

Requirements with "No Discussion" (Initial Chair's Grouping)

H1: Delig must not disrupt the existing registration model of domains
- Discussion: There was a consensus that this requirement should remain. A participant noted that from the perspective of TLDs, disruption is primarily financial, and the proposed technical changes are not seen as disruptive as long as the money flow is maintained. While the word "disrupt" might be ambiguous (a new RR type could be seen as disruptive), the sentiment of not upending the existing domain name industry was agreed to be important.
H3: Delig must not negatively impact most DNS software
- Discussion: It was clarified that "negatively impact" does not mean no software changes are allowed (as new software will be needed to implement DELIG). Instead, it means not breaking older software's existing functionality.
S4: Delig should enable a DNS operator to manage DNS service more completely on behalf of domain administrators
- Discussion:
  - A participant questioned if this should be a "hard" requirement, but the sense of those present was that it remains an aspirational "soft" requirement, representing a problem DELIG aims to solve rather than an absolute necessity for protocol function.
  - The phrasing "more completely" and "domain administrators" was seen as clunky.
  - A participant distinguished S4 (third-party DNS providers, e.g., Cloudflare managing DNS) from S7 (child signaling parent about updates).
  - Proposed rephrasing: "Delig should allow or provide a third-party DNS operator to manage DNS service."
  - Concern was raised about the ambiguity of "DNS operator" (e.g., authoritative, recursive, child, registry).
  - Alternative phrasing suggested: "should minimize the need to communicate across different parties in the involved in the protocol" or "simplify the data flow for synchronization between all concerned parties."

Requirements with "Little Discussion" (Initial Chair's Grouping)

H2: Delig must be able to secure delegations with DNSSEC
- Discussion:
  - A participant suggested simplifying this to "Delig must be able to secure delegations," removing the specific mention of "DNSSEC" to avoid over-specification of the security mechanism.
  - The intent was understood to be that DELIG should not hinder DNSSEC and should support secured delegations, but not necessarily be dependent on DNSSEC itself. It was also noted that the existing H1 (not breaking the installed base) implicitly covers not hindering DNSSEC.
S7: Delig should support an inband means for the child to Signal the parent that the parent's side records related to the child should be updated
- Discussion: There was strong sentiment to delete S7 completely. It was viewed as an implementation detail rather than a core requirement and was seen as assuming a specific protocol design (e.g., "inband" communication was problematic). It was argued that if S4 (facilitating third-party management) is met, the need for frequent child-to-parent signaling might be reduced, implicitly addressing the underlying issue.

Requirements with "A Lot of Discussion" (Initial Chair's Grouping)

H7: Delig must be backward compatible with the existing ecosystem
- Discussion:
  - The group acknowledged that "backward compatible" might be too strong, as DELIG introduces a new mechanism.
  - The core intent behind this requirement was to "not disrupt the installed base." A participant, who was an original proponent, clarified that the goal was that users of NS records would not have to worry about DELIG, and that existing NS records would continue to function.
  - It was emphasized that DELIG's role is to define how delegation concepts are expressed in the protocol, not to fundamentally alter the underlying concepts of delegation or authority within the DNS.
Parent/Child Record Question (should a child zone have DELIG records, parent-centric vs. child-centric models)
- Discussion:
  - This was identified as a significant discussion point on the mailing list, though not directly tied to a specific requirement in the draft.
  - A participant advocated for a model where "if you do something in the parent, you should not do it in the child" (using the DS record as an example of current ambiguity).
  - Conversely, another participant argued that the new design should clearly define where authority for information lies, and that delegation information should originate from the parent.
  - The sense of those present was that at the requirements stage, the document should not rule anything in or out regarding parent-centric vs. child-centric models or where delegation information should reside (e.g., parent only, child only, or both). This level of detail is more appropriate for the protocol design phase.
  - It was suggested to avoid the terms "parent-centric" and "child-centric" due to divergent interpretations among participants. Instead, the focus should be on the goal: creating less confusion and making operations easier for all involved parties (authoritative, resolver, child, registry operators).
  - Proposed non-requirement: If a new delegation protocol is based on a DNS resource record, that record must not appear in both the parent and the child with the same name and type (this was already added as a non-requirement in revision -01, arising from this discussion).

New Discussion Point: Provisioning

Discussion: A participant raised the question of whether "provisioning" should be a front-and-center issue for DELIG. They highlighted the difference between DNS's query/response protocol (ask, get response) and provisioning protocols (request action, get acknowledgment/denial). Current mechanisms like CDS/CDNSKEY can convey information but lack explicit "denial" capabilities common in provisioning.
Conclusion: The sense of the group was that provisioning is a complex "minefield" and should remain out of scope for the requirements document. Existing DNS update protocols could potentially be used for DELIG provisioning, similar to NS, and over-specifying it now would be premature. The primary aim of DELIG is to simplify the referral process, which should reduce the frequency of provisioning changes needed.

Decisions and Action Items

The document authors will incorporate the feedback from this meeting and the mailing list into a new revision of the requirements draft.
Specific GitHub issues have been opened to track proposed changes and rewordings, particularly for H2, S4, and the removal of S7.
The goal is to finalize a new draft revision before the IETF-118 draft submission deadline (October 21st).

Next Steps

The document authors (Brian and Tommy) will work with the chairs to review meeting minutes, address open GitHub issues, and prepare a new revision of the requirements draft (draft-ietf-deleg-requirements) for publication before the IETF-118 deadline.
The aim for the DELEG session at IETF-118 in Dublin is to conclude the discussion on requirements and move towards initiating technical discussions on potential protocol designs.