Session Date/Time: 20 Jun 2023 18:00

DNSOP

Summary

This interim meeting focused on resolving the contentious definition of "lame delegation" within the RFC 8499bis (DNS Terminology) document. Following extensive discussion on the mailing list and during the working group last call, it was clear that the term has multiple, ambiguous interpretations and a long history of confusion. The working group achieved rough consensus on a path forward: to mark "lame delegation" as a historic term within the document, provide a descriptive paragraph of its various past uses without being prescriptive, and advise future authors to be more specific in their terminology when describing delegation issues.

Key Discussion Points

Problem Statement for RFC 8499bis: The definition of "lame delegation" in RFC 8499bis has proven highly controversial and ambiguous, leading to significant discussion during the working group last call.
Desire for New Terms vs. Redefinition: Paul Hoffman noted that many participants expressed a desire for new, clearer terms rather than attempting to redefine "lame delegation," which has a history of failed redefinitions in terminology documents.
Current Use and Ambiguity: Participants discussed the current use of "lame delegation" in various contexts, including IETF documents (e.g., CDNS/CDSYNC discussions), authoritative server documentation, and guidance for DNS administrators. It was emphasized that the term's meaning has consistently been unclear across these uses, even in historical contexts like ARIN policy discussions.
Chair's Initial Options: The chair presented three main options: 1) retain the existing definition with an added note on ambiguity, 2) mark the term as historic, or 3) find rough consensus on a new, explicit definition (which had some mailing list support). The chair also suggested that defining entirely new terms should occur in a separate document to allow 8499bis to finalize.
Proposal for "Flawed Delegation": Paul Wilders proposed marking "lame delegation" as historic and introducing a new, broader term like "flawed delegation" to encompass various inconsistencies (e.g., inconsistent NS records, unreachable IPs, no name server listening).
Concern about Prescriptiveness: Dwayne expressed concern that merely "suggesting" new terminology without a clear definition might perpetuate the current ambiguity. Paul Hoffman clarified that the intent was to guide future authors without being overly prescriptive with new definitions.
Suzanne's Comprehensive Proposal: Suzanne put forward a proposal that garnered significant support:
- Mark "lame delegation" as historic in RFC 8499bis.
- Add a new, descriptive paragraph that explains the various situations and meanings for which the term "lame delegation" has been used in the past. This paragraph would not define new terms but describe past usage.
- Explicitly advise authors of future documents to use more precise and descriptive language when referring to delegation issues, rather than the ambiguous "lame delegation."
Support for Suzanne's Proposal: Ed Lewis supported this approach, emphasizing that the diverse ways delegations can be "broken" make a single, generic term inadequate. He agreed that the historic context should be noted, but the primary advice should be for clarity and specificity in current and future documents. Dwayne and Paul Wilders confirmed their acceptance of this path forward.

Decisions and Action Items

Decision: The RFC 8499bis document will explicitly mark the term "lame delegation" as historic.
Decision: The document will include an additional descriptive paragraph detailing the various interpretations and contexts in which "lame delegation" has been used historically. This paragraph will avoid prescribing a new definition for the term.
Decision: The document will advise future authors to employ more specific and descriptive terminology when discussing issues related to DNS delegations, discouraging the continued use of the ambiguous "lame delegation."
Action Item: Suzanne volunteered to draft the specific text for this new paragraph and update to the RFC 8499bis document. She aims to complete this within the next week.
Action Item: The chairs will publish these minutes and send a summary of the discussion and agreed-upon way forward to the DNSOP mailing list.

Next Steps

Suzanne will provide the drafted text for incorporation into RFC 8499bis.
The RFC 8499bis document will be updated to reflect these changes, likely resulting in a new draft version (e.g., draft-ietf-dnsop-rfc8499bis-08).