**Session Date/Time:** 03 Sep 2024 14:00 # [SCHC](../wg/schc.html) ## Summary The SCHC working group held an interim meeting to discuss administrative items, ongoing document status, and engage in key technical discussions. Topics included the concept of proxies within SCHC, potential collaboration with the Deep Space BUF, and feedback received on the SCHC Protocol Numbers draft. Decisions were made regarding IETF 121 slot request and a call for adoption for the SCHC OAM document. ## Key Discussion Points * **Administrative Updates** * The working group will request a two-hour slot for IETF 121 in Dublin, a request that received broad support from attendees. * Interim meetings are scheduled bi-weekly, with specific dates for October provided to align with draft submission deadlines. * **Document Status Updates**: * `draft-ietf-schc-networks-prone-to-disruptions`: Submitted as a working group document following last call and adoption. * **RFC 8824 Update**: Work is ongoing. * **SCHC Architecture**: Work is ongoing. * **SCHC OAM**: The document is considered stable after removing the "actions" part. * **SCHC F-Port**: Chairs will follow up with authors on its status. * Access control and PPP discussions deferred to the next interim. * **SCHC over Networks Prone to Disruptions: Proxy Concept** * Pascal introduced a discussion on the concept of a "proxy" as described in the `draft-ietf-schc-networks-prone-to-disruptions` document. * The discussion revolved around how this proxy relates to the existing SCHC Gateway (which primarily handles compression/fragmentation) and whether it performs Layer 4 (e.g., terminating fragmentation, converting CoAP to HTTP) or Layer 5 functions (e.g., handling application-level liveness/keep-alive). * It was noted that the SCHC Gateway operates at Layer 3, but the proposed proxy functions could extend to Layer 4 or 5. * The impact of encryption on proxy functionality (e.g., inspecting CoAP objects) was also raised. * There was agreement that the concept of a proxy needs to be better defined and positioned within the SCHC architecture document. * **Deep Space BUF and SCHC** * Laura and Mark Blan presented on the Deep Space BUF, highlighting parallels between LPWAN networks and deep space communication regarding challenges like long delays (e.g., 5-45 minutes round trip to Mars) and communication interruptions (e.g., due to orbital mechanics). * Deep space links are often point-to-point with limited bandwidth, making SCHC's efficiency and datagram concept potentially very beneficial. * Mark described the use case, focusing on deep space scenarios (Mars, Moon) where IP was previously deemed unsuitable but is now being re-evaluated. * The proposed architecture includes all-IP within celestial bodies (using 3GPP/Wi-Fi) and SCHC for deep space links. * Key technical outputs requested for collaboration include a **SCHC profile for QUIC** and a **SCHC profile for UDP** to help reduce overhead. * The Deep Space BUF is planned for the next IETF meeting in Dublin. * **SCHC Protocol Numbers Draft (`draft-ietf-schc-protocol-numbers`) Reviews** * Pascal provided an update on the reviews received for the `draft-ietf-schc-protocol-numbers` from Eric Vyncke, Joe Touch, and Mia. * **General Feedback**: The draft needs stronger justification (more use cases) for allocating an IP protocol number, an EtherType, and a UDP port number. * **Eric Vyncke's points**: * The discussion on UDP port numbers is too light and includes TBD sections. * IANA/IEEE considerations were not fully followed, specifically referencing RFC 9542 (for EtherTypes) which requires a version field at a fixed offset in the protocol header. This implies a potential need to define a SCHC protocol version. * The existing aviation use case was considered too narrow. * **Joe Touch's points**: * Clarification is needed on how the "Internet Protocol number" would be used, especially in the context of compressed IP headers and the `Next Header` field in IPv6. * Challenged the justification for a fixed UDP port number, stating that it's "highly unfashionable" and typically applications negotiate ports dynamically. * Firewall traversal was seen as a weak justification for a fixed UDP port. * **Mia's points**: * Questioned why this work isn't done within the SCHC architecture document, given concerns about the architecture's long-term timeline versus the need for quick number assignments. * Echoed concerns about firewall traversal as a weak use case for UDP ports. * The current draft structure regarding IANA/IEEE requests needs significant work to align with IETF best practices and RFCs (e.g., RFC 742). ## Decisions and Action Items * **Decision**: Request a 2-hour slot for the SCHC WG at IETF 121 in Dublin. * **Decision**: Chairs will initiate a working group adoption call for the SCHC OAM document on the mailing list. * **Action Item**: Chairs/Pascal to start a discussion on the mailing list regarding the "proxy" concept and its place within SCHC architecture. * **Action Item**: Chairs to ensure the Deep Space BUF is included in IETF 121 scheduling conflict avoidance. * **Action Item**: Authors of `draft-ietf-schc-protocol-numbers` to update the draft based on review feedback, specifically: * Provide stronger and more diverse use cases for IP protocol numbers, EtherTypes, and UDP port numbers. * Address IANA/IEEE considerations (e.g., version field requirement). * Revisit the justification for a fixed UDP port number, potentially exploring dynamic negotiation or alternative use cases. ## Next Steps * Continue discussions on the proxy concept, potentially leading to integration into the SCHC architecture document or a separate document if significant interest arises. * Progress the `draft-ietf-schc-protocol-numbers` by addressing reviewer comments and refining justifications for allocations. * Conduct the working group adoption call for the SCHC OAM document. * Monitor progress of the Deep Space BUF and prepare for potential collaboration with the SCHC working group, especially concerning profiles for QUIC and UDP. * Prepare the agenda and presentations for the upcoming interim meetings and IETF 121.