**Session Date/Time:** 07 Nov 2025 19:30

# CORE

## Summary

The CORE Working Group met to discuss ongoing work related to CoAP, OSCORE, and various transport bindings. Key topics included updates on YANG SID generation, clarifications needed for CoConf, and the status of several documents nearing Working Group Last Call or adoption. Significant discussion centered on the URI Path Abbreviation, Performance Measurement for CoAP, mechanisms for enhancing OSCORE privacy (hiding information, key updates, identifier updates), Observed Multicast Notifications, CoAP over Bundle Protocol, CoAP over GATT, and a new proposal for Non-Traditional Response Forms. The session also included calls for reviews and discussion on future interim meeting agendas.

## Key Discussion Points

*   **YANG SID Generation Progress:** Karsten reported on efforts from the hackathon to merge development branches for SID generation. Approximately 19,718 SIDs from RFC modules require allocation. This involves a logistical effort to define included modules, create ranges with margins, and generate IANA input and SID files.
*   **CoConf Error Messages:** An implementer questioned the use of RFC YANG data for CoConf error messages instead of S-Expressions (SX structure). While S-Expressions are newer, there are concerns about tool support and reliance on existing RCE YANG data. Implementers were invited to provide feedback on this potential change.
*   **RFC 9254 Instance Identifier Issue:** Ambiguity exists in RFC 9254 regarding instance identifiers for leaf-list and keyless list items, which are defined in RestConf for JSON. The lack of an explicit reference in RFC 9254 to RestConf for these specifics creates a problem. Options for clarification (direct text, small errata, or a new document) were presented, and interested parties were asked for input.
*   **Corrections and Clarifications (Korklar):**
    *   **Proxy-URI vs. Individual URI Options:** There is ambiguity regarding when to use the Proxy-URI option. While one view (Karsten's) sees it as a fallback, others read it as a normal choice. This is particularly relevant as the URI Path Abbreviation option lacks an "unsafe" bit, meaning an unaware proxy might manipulate individual URI options, losing the abbreviation. Christian noted that no proxy implementations are known to convert URI options to Proxy-URI, suggesting the issue might be one of confirming current practices. The discussion emphasized the need for clarity, possibly with examples.
    *   **Non-Confirmable Requests and Error Responses:** The current text in RFC 7252 suggests rejecting non-confirmable requests with a reset message if they don't work. However, the URI Path Abbreviation needs to return a 4.02 Problem Details for unsupported options. It was proposed to correct this to allow for a 4.02 Problem Details response when an error can be processed, otherwise a reset. This change was broadly supported as it aligns better with the intent of error messages.
*   **URI Path Abbreviation:** Christian presented updates on the draft, motivated by the desire to reduce path length in initial CoAP messages, especially for discovery (`.well-known/core`) and onboarding mechanisms like Ad-hoc/BRSKI. The proposed solution is a new numeric CoAP option (13), mutually exclusive with `URI-Path`, which abbreviates common paths (e.g., value 1 for `.well-known/core`). This could save 15+ bytes per message. While Karsten raised concerns about extensibility, the current design allows for future extensions without impacting existing implementations. The document aims for simplicity and focus.
*   **Performance Measurement for CoAP:** Giuseppe provided an update on a draft proposing a mechanism to measure CoAP performance (packet loss, delay) in constrained environments using Explicit Flow Measurement (EFM) techniques. This involves a "square bit" (alternate marking) carried in a new CoAP option. The "spin bit" for RTT measurement, previously included, was removed due to CoAP's discontinuous flows. An `io.coap` implementation has tested packet loss and simple delay measurement, with an outstanding check for behavior during retransmissions. The current focus is on UDP, with future plans for TCP.
*   **Hiding More Information from the OSCORE Option:** Marco presented updates on a draft to enhance OSCORE privacy by encrypting the Partial IV (sequence number) and replacing the Sender Identifier (KID) with a per-message ephemeral value. This aims to prevent leakage of side information that could enable tracking. The mechanism is optional and requires peer agreement. The recipient side uses an iterative process of assuming obfuscation status and trying security contexts. Next steps include considering a slightly longer ephemeral KID for reduced false positives, a hybrid mode for Partial IV and KID obfuscation, and further adaptation for Group OSCORE.
*   **Key Update for OSCORE (KUDOS):** Ricard presented the redesigned KUDOS draft, which uses an explicit state machine for renewing OSCORE master secrets and salts, enabling forward secrecy. The design is robust, flexible in message flow, and supports a "no-forward-secrecy" mode for very constrained devices. Updates include an ASCII figure for the state machine and additional message flow examples. Two existing implementations are slated for update.
*   **Identifier Update for OSCORE:** Ricard also presented an update on a draft to allow updating sender and recipient IDs in OSCORE contexts, aimed at mitigating message correlation and tracking. The state machine-based procedure requires explicit acknowledgments and uses timers (or potentially message counts). A successful update allows deletion of old contexts and strategic use of new IDs (e.g., after network migration). New examples include initiation via response and a failure case.
*   **Observed Multicast Notifications:** Marco reported on the split of this work into two documents: a main protocol document (v13) and a new informational document (v0) for proxy-specific use cases. This addresses IANA comments and clarifies aspects like link-local address usage and alignment with CoreHRF. The main document now specifies direct client reception of multicast, while the new document covers proxy deployments.
*   **CoAP Over Bundle Protocol (BP):** Carlos presented updates on this WG document (v01), addressing Marco's review. Key changes include specifying that the `Payload-Length` option must not be used in non-aggregate CoAP messages within a bundle, updating source node ID rules for one-to-many communication, and discussing the challenge of CoAP's `MIN_TOKEN_REUSE_TIME` in delayed-tolerant BP environments. Further details on proxy aggregation and the interplay between BPSEC and OSCORE for security were added, including privacy implications of the `Payload-Length` option.
*   **CoAP Over GATT:** Christian provided a recap and update on this document, which enables CoAP transport over Bluetooth Low Energy's Generic Attribute Profile (GATT). The motivation remains enabling communication between end-user devices and constrained nodes where direct IP APIs are unavailable. The protocol supports reliable/unreliable transport, concurrent requests, and non-traditional responses, with some CoAP header modifications to leverage GATT's guarantees. Implementations exist in Riders OS and an ACE demo.
*   **Non-Traditional Response Forms:** Christian introduced a draft to formalize and generalize the concept of "non-traditional responses" – responses that are not the single, immediate response to a request (e.g., observation notifications, multicast responses). The goal is to provide a common framework to simplify OSCORE handling for various multiple-response scenarios, avoiding the need for repeated OSCORE re-specifications. The draft proposes three new options (`Response-Form`, `Leisure-for-Response`, `Response-To`).
*   **IANA Registration for core-route-target:** Therless sent an email regarding adding extensions to the `core-route-target` IANA registration table for protocols like `animabrewski.star` and requested reviews for a draft updating RFC 6690.
*   **CoAP over QUIC:** Christian called for collaboration among groups interested in CoAP over QUIC.

## Decisions and Action Items

*   **Korklar - Non-Confirmable Request Error Handling:**
    *   **Decision:** The working group concurred to correct the text in the Korklar document to allow sending a 4.02 Problem Details error response for non-confirmable requests when an error message can be processed, rather than just a reset.
    *   **Action Item:** Karsten (and co-authors) to write up the correction in the Korklar document. Discussion will continue on the list and at the December interim.
*   **URI Path Abbreviation:**
    *   **Decision:** The working group will aim for a Working Group Last Call for this document after the December 3rd interim meeting.
    *   **Action Item:** Discussion on related `Proxy-URI` ambiguity can continue on the list and will be an agenda item for the December 3rd interim. Christian to prepare a minor update for a new version post-interim.
*   **CoAP over GATT:**
    *   **Decision:** A sense of those present indicated support (7 people) for considering the document ready for working group adoption.
    *   **Action Item:** The chairs, in coordination with Christian, will solicit two reviews for the CoAP over GATT document within the next three weeks (by approximately December 14th). Following successful reviews, a working group adoption call will be initiated on the mailing list.
*   **Non-Traditional Response Forms:**
    *   **Action Item:** The chairs will solicit two reviews for this document. Marco volunteered to provide one review. Christian and the chairs will identify another reviewer (Göran or Francesco were suggested). An adoption call will be initiated once two reviews are completed.
*   **YANG SID Generation:**
    *   **Action Item:** Anyone with a YANG module that could benefit from SID files is encouraged to speak with Karsten.
*   **RFC 9254 Instance Identifiers:**
    *   **Action Item:** Interested parties are requested to provide feedback on clarification options for the ambiguities identified in the RFC.
*   **CoConf Error Messages:**
    *   **Action Item:** Implementers (both on-site and remote) are requested to provide feedback on the proposal to change from RFC YANG data to S-Expressions for CoConf error messages.

## Next Steps

*   **Interim Meetings:** A one-off interim meeting is scheduled for December 3rd, focusing primarily on URI Path Abbreviation and Korklar. A series of four bi-weekly interim meetings will then resume from January 14th until IETF 125, typically on Wednesdays in the European afternoon.
*   **Document-Specific Actions:**
    *   Authors of Performance Measurement, Hiding OSCORE Option Information, KUDOS, and Identifier Update drafts are to continue with their outlined next steps, including implementation updates/testing, considering design adjustments (e.g., longer KIDs, message counts), and addressing specific corner cases.
    *   The authors of Observed Multicast Notifications will discuss the "Max Age" for initial notifications and address reverse proxy use cases, as well as the applicability of the main document's option in requests.
    *   Carlos will investigate padding options from the Cacheable OSCORE document for CoAP over Bundle Protocol.
*   **Cross-WG Coordination:** Parties interested in CoAP over QUIC are encouraged to coordinate.
*   **General:** Continue discussions on identified issues and ongoing work on the mailing list and GitHub.