ALPN ID Specification for CoAP over DTLS
draft-ietf-core-coap-dtls-alpn-05

Yes

Mike Bishop

No Objection

Andy Newton
Deb Cooley
Erik Kline
Gorry Fairhurst
Gunter Van de Velde
Jim Guichard
Ketan Talaulikar
Mohamed Boucadair
Paul Wouters
Éric Vyncke

Note: This ballot was opened for revision 04 and is now closed.

Mike Bishop
Yes
Andy Newton
No Objection
Comment (2025-08-05 for -04) Not sent 
# Andy Newton, ART AD, comments for draft-ietf-core-coap-dtls-alpn-04
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-core-coap-dtls-alpn-04.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## No Objection

I echo Barry Lieba's ARTART review: "Simple, straightforward, ready.  No further comment."
Deb Cooley
No Objection
Comment (2025-08-05 for -04) Sent 
Thanks to Joe Salowey for their secdir reviews.

Section 1:  Instead of just referencing DTLS with two RFCs, perhaps say that 'DTLS 1.2 or 1.3' and then add the RFC references.  Do the same for TLS - add the 1.3.
Erik Kline
No Objection
Gorry Fairhurst
No Objection
Comment (2025-08-01 for -04) Not sent 
Thank you for this short I-D, I have no transport-related concerns.
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
Ketan Talaulikar
No Objection
Mohamed Boucadair
No Objection
Comment (2025-07-12 for -04) Sent 
Hi Martine, Christian, Thomas, and Matthias, 

Thank you for the effort put into this document.

I do fully support a separate ALPN ID for CoAP-over-DTLS.

As already indicated in [1], my initial take was that this is better merged with I-D.ietf-core-dns-over-coap. That approach has the merit to bind it to a case that motivated the registration at the first place. Doing so does not restrict by any means the applicability of the new ALPN ID. That's said, I consider that point "closed" as this point was discussed early in the process and the WG decided to keep the registration separate. Ack!

# Better ID?

Compared to "coap", "co" is ambiguous.

I understand the rationale is to have a short ID. "cod" (for CoAP over DTLS) or simply "cd" would reflect better the intended usage, IMO.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/core/f4vW-60UyFfnq60zFCYR4QGJeLg/
Paul Wouters
No Objection
Comment (2025-08-06 for -04) Sent 
I am a bit surprised this is not Standards Track, as it is the output of a WG, and seems to apply ti various other protocol documents that will use it.
Éric Vyncke
No Objection
Comment (2025-07-30 for -04) Sent 
Thanks for the work done in short but useful document.

Like Med Boucadair, I wonder about the choice of "co" as I would expect either "c" (the smallest possible to be used in constrained environment) or "coap" like the TLS version as I do not understand why different transports require different ALPN.