**Session Date/Time:** 18 Jan 2023 15:00 # [CORE](../wg/core.html) ## Summary The CORE working group meeting covered updates and discussions on three key document areas: conditional attributes for constrained environments, the CORECONF suite (specifically Yang SID and CoMAI), and efficient URI scheme encoding for HREFs. Key discussions included clarifying the interaction of conditional attributes with CoAP Observe, streamlining Yang SID management, simplifying CoMAI's `K` parameter, and establishing a robust process for URI scheme ID registration within the HREFs document to prevent future interoperability issues. ## Key Discussion Points * **Conditional Attributes (draft-ietf-core-conditional-attributes):** * The document is currently at version 0.6 and has completed working group last call, with an early review requested from the IoT directorate. * **Security Considerations:** A review comment highlighted the need for more robust security considerations regarding `pmax` (potential for amplification attacks) and `epmax` (potential for resource exhaustion attacks). The co-authors plan to expand this section to provide guidance, noting that CoAP RFC 7641 already provides underlying mitigation for amplification. * **Observe Mechanism Interaction:** A significant discussion focused on whether conditional attributes (expressed as query parameters) interfere with CoAP Observe. The consensus indicated that applying query parameters effectively defines a "new resource" or a "new state" of an existing resource, which can then be faithfully observed. This interpretation aligns with RFC 7641 and does not fundamentally alter how Observe works, though the document needs to explicitly clarify this. * **Resource State Definition:** The concept of "resource state" was discussed, with participants suggesting it encompasses more than just payload changes, including temporal aspects (e.g., `max-age` changes, new timing information even if the value is the same) and the absence of expected updates. * **Proxies and Caching:** The potential impact on CoAP proxies and client-side caches was raised, suggesting the need for a dedicated section in the draft to clarify expected behavior. * **CORECONF Documents:** * **`draft-ietf-core-sid` (Yang SID):** * Discussion focused on the need for a "stable" field within the SID file. This field is primarily intended to facilitate clearer communication and process management among Yang module developers. * The process of determining and marking a SID as "stable" (who, when, why) was identified as a critical design aspect. * The need to record "obsolete" SIDs was also highlighted to prevent their accidental reuse and maintain clarity for implementations. * **`draft-ietf-core-comai`:** * The existing definition of the `K` query parameter for `GET` requests was identified as overly complex and problematic, particularly for strings containing commas. * A strong sense of those present indicated that simplifying or potentially eliminating the `K` parameter and making `FETCH` the primary or mandatory mechanism would greatly benefit the document, given `FETCH`'s current establishment and adoption. * **HREFs Document (draft-ietf-core-href):** * The working group is progressing towards establishing an IANA registry for numeric URI Scheme IDs (CRIs) to enable more efficient encoding of URI schemes. * The proposed registry would use "expert review" for registrations, with specific ID spaces reserved for wide-use IoT schemes and provisional schemes. * A critical open point is the **timing** of URI Scheme ID registration. Two main approaches were considered: 1. **"Now or Never" (Current PR):** IDs can only be registered concurrently with the URI scheme itself, aiming to prevent later inconsistencies if an ID is added after textual representations are widely deployed. 2. **"Automatic Registration":** Pre-register IDs for all existing URI schemes, and automatically trigger an ID registration every time a new URI scheme is registered. * This discussion was framed using the "X-dash problem" analogy, emphasizing that if numeric IDs are not available early and consistently, implementations will stick with textual representations, hindering the benefits of efficient numeric encoding. ## Decisions and Action Items * **Conditional Attributes (draft-ietf-core-conditional-attributes):** * **Decision:** The co-authors will prepare version 0.7 of the draft, incorporating expanded security considerations for `pmax` and `epmax`, clarifications on the interaction with CoAP Observe and the definition of resource state, and a potential dedicated section on proxy and caching considerations. * **Action Item:** Bill Silverajan and co-authors to digest feedback, reflect in the draft, and work in parallel with the IoT directorate review. * **CORECONF - `draft-ietf-core-sid`:** * **Action Item:** Karsten Bormann and a design team will process Rob Wilton's detailed feedback, especially concerning the "stable" field and the mechanism for recording obsolete SIDs, with the aim of producing a `-20` version of the draft. * **CORECONF - `draft-ietf-core-comai`:** * **Action Item:** A design team will be convened to decide on the future of the `K` query parameter, including options for simplification or making `FETCH` the mandatory mechanism, and to prepare a `-12` version of the draft. * **HREFs (draft-ietf-core-href):** * **Action Item:** The discussion on the optimal timing for URI Scheme ID registration will continue during the `core-href` design meeting on Friday. * **Action Item:** Marco Tiloca and Karsten Bormann will clean up other open issues and pull requests (e.g., 53, 54) related to the `href` document. ## Next Steps * The co-authors of `draft-ietf-core-conditional-attributes` will continue refining the document based on the discussion and the IoT directorate's review. * Design team meetings will be scheduled for `draft-ietf-core-sid` and `draft-ietf-core-comai` to address outstanding issues and progress these documents. * A `core-href` design meeting will be held on Friday to resolve the critical open point regarding the timing of URI Scheme ID registration and address other maintenance items.