Session Date/Time: 07 Dec 2022 15:00

CORE

Summary

The CORE Working Group held an interim meeting to discuss the status and next steps for several key documents and to resolve outstanding errata. Key discussions focused on the CORECONF cluster (specifically the CORESID document), the COMAI K query parameter encoding, the Target Attributes document, and the proposed Corrections and Clarifications (CoRCLR) document. The group also reviewed and made progress on the resolution of various errata for existing CORE RFCs.

Key Discussion Points

CORECONF Cluster Update (CORESID)

Document Status: One CORECONF document is an RFC, one is in ISG (with a DISCUSS from July last year on version 16), one has passed WG Last Call, and the Yang Library document is stalled.
CORESID DISCUSS Resolution: The main issue with the ISG DISCUSS was to better document the objectives of SID management. Dash 19 (Pull Request 146, July this year) aims to address this.
Rob's Input: The WG is awaiting input from Rob on Dash 19, despite attempts to contact him. Francesca was asked to nudge Rob.
SID File Workflow Issue: A new requirement arose for handling SID files that merge stable (e.g., published RFC) and unstable (e.g., current draft) inputs. The current pyang tool does not support this.
Proposed "stable" Field: A "stable" field (boolean, defaults to true) was proposed for the SID file to address the merging issue. This requires pyang implementation support.
Second WG Last Call: Due to the accumulated changes, particularly the "stable" field and DISCUSS resolution, a second Working Group Last Call is anticipated for CORESID.
Editorial Work: Further editorial review is needed to update Yang data references to CBOR structure, remove obsolete Netconf references, update dates/authors, and review against COMAI requirements.
Design Team Meeting: A design team meeting is planned to discuss workflows, especially those related to the "stable" field.

COMAI (CoAP Management Interface)

Status: The document is awaiting Yang-CBOR completion for finishing touches.
Technical Issue: K Query Parameter Encoding: The current draft defines different encodings for various Yang data types (e.g., unsigned vs. signed integers) when used with the CoAP GET method's K query parameter. This introduces complexity.
Proposed Solution: From IETF 115 hackathon discussions, the proposal is to uniformly use URL-safe base64 encoding of the CBOR representation of the key. This simplifies implementation by having a single approach, though it may occasionally result in longer query parameters.
String Case Optimization: Discussed whether to make a special case for string keys (a common scenario) to optimize length, potentially reducing 11 cases to 2.
Implementer Feedback: Christian Amsüss (implementer of both GET and FETCH) confirmed that while the current varied encodings add complexity, their impact on code size isn't significant. He supported the uniform URL-safe base64 CBOR approach for consistency and safety (especially addressing cases where commas in string keys break parsing).

Target Attributes

Status: Adopted as a Working Group document.
Next Steps: A -01 revision is needed to update pre-fill tables with already registered attributes.
Name Length Limit: Thomas Fossati suggested limiting the length of Target Attribute names (e.g., 16 or 32 characters) to ease implementation. This will be discussed in a GitHub issue.
WG Last Call: A Working Group Last Call is planned after the -01 revision.

Corrections and Clarifications (CoRCLR)

Revival: The 2018 draft is proposed for revival, leveraging an existing GitHub repository.
Content Sources:
- Errata Explanations: Incorporate detailed explanations for errata reports (e.g., Pull Request 26 example).
- CoAP FAQ: Pull in content from the CoAP Frequently Asked Questions (a wiki document).
- "Every CoAP" Document: Incorporate relevant text from the expired "Every CoAP" Internet Draft.
Document Status Discussion:
- Standards Track Elements: Actual corrections (fixes updating the protocol) would require a standards track status and strong consensus.
- Informational Elements: Clarifications, explanations, and implementation guidance (e.g., "how do I do X?") would be informational and might be more opinionated.
- Structure: Considered putting informational parts into an appendix to clearly separate them from standards-track corrections.
- Platform for Content: Discussed using a Wiki (IETF Wiki) vs. GitHub for community contributions, with GitHub in the WG organization favored.
Content Selection: Guidelines for selecting relevant content from various sources will need to be developed and potentially included in the document itself.

Errata Resolution (for RFC 7252)

The group reviewed several errata, with the following outcomes:

Errata 4895 (Payload Type Values): Sense of those present indicates Verified.
Errata 4946 & 4947 (Fragment Component in URI): Sense of those present indicates Rejected. These errata proposed explicitly mentioning the fragment component for CoAP/CoAPs URIs, but it was noted that HTTP (RFC 9110) does the opposite, and introducing it would create confusion and contradict the received interpretation of URIs. Further clarifications, if needed, will be addressed in the CoRCLR document. Klaus (the filer) agreed to the rejection.
Errata 4948 (CoAP Message Numbers): Sense of those present indicates Verified. This was acknowledged as a substantial protocol change but clarifies the original intent.
Errata 4949 (Error Response to Response): Sense of those present indicates Verified. (This was considered "very obviously true").
Errata 4954 (Content-Format Registry Columns): Proposed to be Edited and then Verified. The verifier (Francesca, if process allows) will edit the erratum to replace "media type" with "media type and parameter" in the "Content Type" column, enabling IANA to fix the registry.
Errata 5254 (Link Format URI Encoding): Sense of those present indicates Rejected. This erratum proposed changes to address error-prone URI variants, but it was determined that this would change the intended format and go beyond the scope of an erratum by invalidating existing HTTP URIs. It would require a document update to RFC 6690.
Errata 5284 (Token Uniqueness): Sense of those present indicates Rejected. The proposed addition of "per request" to clarify token uniqueness was deemed not helpful and potentially confusing; further clarification can be addressed in CoRCLR if needed.

Decisions and Action Items

CORESID:
- Decision: A design team meeting will be planned to discuss CORESID workflows, particularly the "stable" field.
- Action: Francesca to nudge Rob for feedback on Dash 19 (PR 146).
COMAI:
- Decision: In-room consensus to move forward with using URL-safe base64 of CBOR-encoded keys for the K query parameter, promoting uniformity.
- Action: A pull request for this change will be created, followed by mailing list discussion.
Target Attributes:
- Decision: Aim for a -01 revision to update pre-fill tables and then proceed to WG Last Call.
- Action: Discuss limiting the length of Target Attribute names in a GitHub issue.
Corrections and Clarifications (CoRCLR):
- Decision: Revive the CoRCLR document, incorporating errata explanations, CoAP FAQ content, and "Every CoAP" document text.
- Action: Klaus to make a pull request demonstrating how pulling in FAQ content might look.
- Action: Chairs to produce additional material for content selection guidelines.
Errata Resolution:
- Decision: Errata 4895, 4948, 4949 are Verified.
- Decision: Errata 4946, 4947, 5254, 5284 are Rejected.
- Decision: Errata 4954 will be Edited by the verifier (if process allows) and then Verified.
- Action: Francesca to perform a final sanity check on all Errata resolutions before proceeding with IANA actions.

Next Steps

Organize and hold the CORESID design team meeting.
Generate the COMAI K-parameter encoding pull request and initiate mailing list discussion.
Prepare the Target Attributes -01 revision and plan for WG Last Call.
Continue development of the CoRCLR document, focusing on content integration and document structure.
Francesca to finalize the Errata resolutions based on WG input.
The next regular CORE interim meeting is scheduled for Wednesday, January 18th.