**Session Date/Time:** 26 Sep 2022 15:00

# [DNSOP](../wg/dnsop.html)

## Summary

The DNSOP interim meeting focused primarily on discussing outstanding issues related to DNS terminology, specifically the definitions of "bailiwick" and "glue" for the RFC 8499bis document. Key discussions revolved around whether to interpret these terms strictly based on historical definitions or to update them to reflect modern DNS practices, especially considering their impact on the "glue is not optional" draft. No final decisions were made in the meeting; instead, the chairs gathered input from the working group to formulate specific questions for a future consensus call on the mailing list.

## Key Discussion Points

*   **Welcome and Agenda**: Benoît Claise (co-chair) opened the meeting, welcoming participants and outlining the agenda. The main topic was DNS terminology, with a proposed informal chat on "alt-TLD" if time permitted. The IETF Note Well and Code of Conduct guidelines were noted.
*   **General Context for Terminology (Paul Wouters)**: Paul Wouters, an author of the 8499bis draft, highlighted the challenge of reconciling historical definitions from original documents with evolving DNS practices. He urged the working group to decide whether the definitions should strictly interpret old views or embrace emerging views, emphasizing that the document should not attempt a "halfway" approach.
*   **Definition of Bailiwick**:
    *   The current draft defines bailiwick by specifying "in domain," "sibling domain," and "out of bailiwick."
    *   A suggestion was made to drop the term "in bailiwick" due to its ambiguity and to only use the more specific terms "in domain" and "sibling domain."
    *   **Warren Kumari (AD)** suggested that rather than completely dropping "bailiwick," the document could provide a somewhat imprecise, "hand-wavy" definition to help readers understand its historical use in other documents or discussions, with a note that the term is now largely avoided.
    *   **John Levine** agreed, emphasizing not to try and strictly define it in a modern context, but rather to acknowledge its past, ambiguous usage.
    *   **Jim Reid** and **Tim Wicinski (co-chair)** echoed this, suggesting the document should explicitly state that the term is historical and ambiguous, choosing not to give it a strict modern definition, but keeping a mention for context.
*   **Scope of Use of Bailiwick / Glue**:
    *   Discussion questioned whether the scope of bailiwick/glue should be restricted to strictly necessary records for name resolution (A/AAAA) or extended to include DNSSEC validation (DNSSEC RRs) or newer record types like SVCB.
    *   **Paul Wouters** cautioned against extending to new types like SVCB, which didn't exist two years ago, arguing it would make the definition perpetually fluid. He preferred a more historical acknowledgement without detailing every change, especially as these definitions impact the "glue is not optional" draft.
    *   **Dwayne Bailey**, an author of "glue is not optional," stated that definitions like "bailiwick," "in domain," and "sibling" are necessary for his draft.
*   **Definition of Glue**:
    *   A proposed definition from the mailing list was discussed, leading to a debate between "necessary for resolution to proceed" (the original phrasing) and "useful for resolution to proceed" (a proposed broader interpretation by Ben Schwartz in earlier mail threads).
    *   **Dwayne Bailey** expressed an inclination towards the narrower "necessary" definition for now, specifically for A and AAAA records, as these are currently the only types consistently treated as glue. He suggested that if other RR types are to be considered glue in the future, it would require further specification, potentially through a registry, rather than broadening the definition in 8499bis prematurely. He noted the distinction between the list of RR types and the "necessary vs. useful" wording.
    *   **Tim Wicinski** noted that a broader definition would require clarifying text in relation to RFC 2181 and would need significant working group discussion.
    *   **Paul Wouters** reiterated the difficulty of predicting future changes in definitions and suggested acknowledging the evolution of the glue definition over time without attempting to update RFC 2181 directly. He stressed the importance of getting this definition right for the "glue is not optional" document, as it dictates how things should act.
    *   **Dwayne Bailey** emphasized that the precise wording ("necessary" vs. "useful") is subtle and less critical than how the protocol actually behaves concerning specific RR types as glue, which would be defined further down the road.
*   **Definition of Sibling Glue**:
    *   It was clarified that "sibling glue" is a shortcut term, and the more precise terminology used in the "glue is not optional" draft is "glue for sibling domain name server." This implies that a separate definition for "sibling glue" as a distinct term is not necessary.
*   **Alt-TLD Discussion**: Due to time constraints and the extensive discussion on terminology, the informal chat on "alt-TLD" was deferred.

## Decisions and Action Items

*   **Chairs Action Item**: The chairs (Benoît Claise, Tim Wicinski, Suzanne Woolf) will formulate specific questions regarding the definition of "bailiwick" and "glue" (including the "necessary" vs. "useful" debate and the scope of RR types for glue) and send them to the DNSOP mailing list for a formal consensus call.
*   **Bailiwick Definition**: Input indicates a direction to treat "in bailiwick" as a historical and ambiguous term, not to be strictly defined in a modern context. The document should acknowledge its past use while favoring "in domain" and "sibling domain" for precision.
*   **Glue Definition**: The working group will discuss on the mailing list the preference between "necessary for resolution to proceed" and "useful for resolution to proceed," and which RR types should be explicitly covered as glue (with current inclination towards A/AAAA records until further specification of others). The needs of the "glue is not optional" draft are paramount in this discussion.

## Next Steps

*   The DNSOP chairs will prepare and send the consensus call questions to the mailing list for formal working group review and input.
*   Authors of RFC 8499bis (Paul Wouters, Kazunori Fujiwara) and "glue is not optional" (Dwayne Bailey) will use the feedback and consensus from the mailing list to refine their respective drafts.
*   Further discussions on "alt-TLD" will need to be scheduled separately or conducted on the mailing list.
*   A message from the chairs regarding future direction on contentious topics is also expected on the mailing list.