[core] Re: draft-ietf-core-oscore-groupcomm-27 telechat Tsvart review

[Marco Tiloca <[e-mail]>]

Hello Joerg,

Thanks for the follow-up comments!

We have addressed those when addressing the review from Gorry Fairhurst at [1], also including similar comments.

The approach to use for enforcing congestion control really depends on the specific transport used when doing key distribution. Since the distributed keying material is for Group OSCORE, it is likely and most expected that such a traffic is also based on CoAP.

If CoAP over UDP is used, one can enforce congestion control as defined in RFC 7252 and draft-ietf-core-groupcomm-bis. Otherwise, it really depends on the specific transport used. A general congestion-control mechanism is DCCP (RFC 4340). If QUIC is specifically used (RFC 9000), its specific congestion control mechanisms are defined in RFC 9002.

We have addressed this point by updating the text in Section 12.2 as below. This is tracked in the PR at [2] addressing Gorry's review.

OLD
> The use of an unreliable transport MUST NOT forego enforcing congestion control as appropriate for that transport.

NEW
> Irrespective of the transport used being reliable or unreliable, appropriate congestion control MUST be enforced. If the key distribution traffic uses CoAP over UDP or over other unreliable transports, mechanisms for enforcing congestion control are specified in Section 4.7 of [RFC7252] and in Section 3.6 of [I-D.ietf-core-groupcomm-bis] for the case of group communication (e.g., over UDP/IP multicast). If, irrespective of using CoAP, the key distribution traffic relies on alternative setups with unreliable transports, one can rely on general congestion-control mechanisms such as DCCP [RFC4340], or on dedicated congestion control mechanisms for the transport specifically used (e.g., those defined in [RFC9002] for QUIC [RFC9000]).


Best,
/Marco

[1] https://mailarchive.ietf.org/arch/msg/core/gEsEOl2IV40YkY36hIwMaT4gvXM/

[2] https://github.com/core-wg/oscore-groupcomm/pull/119
________________________________
From: Joerg Ott via Datatracker <[e-mail]>
Sent: Monday, October 6, 2025 11:23 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: draft-ietf-core-oscore-groupcomm-27 telechat Tsvart review

Document: draft-ietf-core-oscore-groupcomm
Title: Group Object Security for Constrained RESTful Environments (Group OSCORE)
Reviewer: Joerg Ott
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[e-mail] if you reply to or forward this review.

I just reviewed the proposed changes and they seem to address my concerns.

One bit to note: when pointing at unreliable messaging and stating that
congestion control would still be required is the right way to go:

"The use of an unreliable transport MUST NOT forego enforcing congestion
control as appropriate for that transport."

The question is: does this lead to any interoperable outcome unless it
is specified how to realise this.  Should one point to DCCP, QUIC Datagrams,
or something else concrete rather than leaving this up open.  What would
an implementer do?