**Session Date/Time:** 08 May 2024 14:00

# [CORE](../wg/core.html)

## Summary

This interim meeting of the CORE Working Group focused on clarifying the document architecture and dependencies for Service Binding Records (SBRs) with CoAP, specifically to facilitate the discovery of DNS over CoAP (DoC) resolvers. The primary goal was to untangle normative references between several drafts to enable the more rapid progression of the DoC specification. Discussions revolved around the placement of the CoAP request construction logic from SBRs, the CoAP over DTLS ALPN ID registration, and the nature of references between the DoC draft, a dedicated CoAP over DTLS SBR draft, a transport indication draft, and the CoRE-DNR problem statement. A plan for document component distribution and referencing was established.

## Key Discussion Points

*   **Background and Problem Statement:**
    *   Initial efforts aimed to discover DNS over CoAP (DoC) resolvers via DNS, DHCP, and Router Advertisements using Service Binding Records (SBRs).
    *   A limitation was identified: SBR discovery currently primarily specifies CoAP over TLS due to an existing ALPN ID, necessitating a CoAP over DTLS ALPN ID.
    *   Additional challenges included specifying different CoAP transport protocols, OSCORE, and ad-hoc security mechanisms with SBRs.
    *   DoC utilizes a `dock-path` key (as a CBOR sequence of text strings) for path discovery, similar to DNS over HTTPS (DoH).
    *   An earlier "DNR" draft (D4) had become overly broad, attempting to solve too many new problems and creating problematic normative dependencies for the DoC draft (D1).
*   **Previous ITF 119 Decisions (Recap):**
    *   The CoAP ALPN ID allocation was separated from the DNR draft.
    *   The DNR draft (D4) was refocused as a problem statement for dedicated DNS resolvers (DDR/DNR) with OSCORE and ad hoc security.
    *   General transport discovery mechanisms were moved into a `transport-indication` draft (D3).
    *   The DTLS ALPN ID itself was moved into its own draft, referred to as `CoAP over DTLS SVCB` (D2).
*   **Document Structure and References Discussion:**
    *   **CoAP Request Construction from SBRs (C3):** Originally contemplated for the `CoAP over DTLS SVCB` draft (D2), it was argued that this general construction logic belongs better in the `transport-indication` draft (D3). This would prevent the DoC draft (D1) from incurring an additional normative dependency if D3 described the construction. The possibility of D1 only sketching the construction (similar to how HTTP SBRs are handled without a dedicated specification) or using an informative reference was discussed.
    *   **CoAP over DTLS ALPN ID Registration:** The ALPN ID is currently registered with IANA, referencing an older DNR draft. It was confirmed that IANA can update the reference to a new document (e.g., D2 or D3) as documents evolve.
    *   **Normative Reference from D1 (DoC) to D2 (CoAP over DTLS SVCB):** The necessity of DoC (D1) having a normative reference to D2 (CoAP over DTLS SVCB) was debated. Given that DTLS is considered the preferred secure transport for CoAP, it was deemed important for DoC to explicitly point to the DTLS ALPN ID specification.
    *   **Informative References:** The value of informative references for guiding readers to related ongoing work (e.g., OSCORE) was emphasized, even if they don't solve the core problem described in the main document.
    *   **`dock-path` Naming:** A recent GitHub comment suggested renaming `dock-path` to `coap-path` or `coap-path`. The current `dock-path` is specific to DNS over CoAP and its use of URI templates. The unique URI namespace for CoAP vs. HTTP, and the implications for generalization, were discussed. No immediate decision was made, pending further discussion with SVCB experts.

## Decisions and Action Items

**Decisions:**

1.  **Component Distribution:** The specification for constructing a CoAP request from an SBR (component C3) will be moved to and detailed in the `transport-indication` draft (D3).
2.  **D1 (DoC) to D2 (CoAP over DTLS SVCB) Reference:** The DNS over CoAP draft (D1) will include a **normative** reference to the `CoAP over DTLS SVCB` draft (D2) for the CoAP over DTLS ALPN ID. This ensures that DoC explicitly points to the preferred secure transport.
3.  **D1 (DoC) to D3 (Transport Indication) Reference:** The DNS over CoAP draft (D1) will include an **informative** reference to the `transport-indication` draft (D3). This reference will provide examples or guidance on how to construct a CoAP request from an SBR, without making it a hard normative dependency.
4.  **D3 (Transport Indication) to D2 (CoAP over DTLS SVCB) Reference:** The `transport-indication` draft (D3) will include a **normative** reference to the `CoAP over DTLS SVCB` draft (D2). This is because D3 will describe general CoAP SBR usage, including the specific DTLS transport.
5.  **D1 (DoC) to D4 (CoRE-DNR) Reference:** The DNS over CoAP draft (D1) will maintain an **informative** reference to the `CoRE-DNR` problem statement (D4). This informs readers about ongoing work regarding OSCORE and ad hoc security for DoC discovery, acknowledging that these aspects are not yet fully solved.
6.  **D4 (CoRE-DNR) References:** The `CoRE-DNR` problem statement (D4) will include **informative** references to D1 (DoC) and D3 (Transport Indication) to provide context for the problems it addresses.

**Action Items:**

*   **Martin Lindner and Christian Amsüss:** Send an email to the CORE WG mailing list summarizing the agreed-upon document structure and referencing plan, including the conceptual whiteboard table discussed. This allows for broader WG review and comment.
*   **Christian Amsüss:** Initiate the process with IANA to update the ALPN ID registry entry for CoAP over DTLS to point to the `CoAP over DTLS SVCB` draft (D2) once it is ready.
*   **Martin Lindner:** Discuss the naming of `dock-path` (e.g., `coap-path`) with SVCB experts to determine the most appropriate and general term.

## Next Steps

*   Update and/or create the relevant drafts in accordance with the decisions made regarding component distribution and references.
*   Christian Amsüss and Marco Tiloca will continue work on "onion style addresses" as they relate to ad hoc solutions, potentially drawing from the `CoRE-DNR` problem statement (D4).
*   The next CORE interim meeting is scheduled for June 5th.