Telechat Review of draft-ietf-asap-sip-auto-peer-20
review-ietf-asap-sip-auto-peer-20-tsvart-telechat-ott-2025-02-26-00

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
tsv-art@ietf.org if you reply to or forward this review.

This document presents an HTTPS-based mechanism to automatically discover
and retrieve capability information of peer providers of SIP services to
enable appropriate local configuration.  The capability information set is
represented in JSON encoding (with proper models defined) and can be
retrieved in full or as delta using a well-defined configuration workflow.
The capability exchange runs on top of HTTPS and uses well-defined local
URIs to identify the retrieved content.

The document relies on existing transport and application layer protocols
with appropriate congestion control and reliability mechanisms in place.
Capabilities are retrieved on a recurring basis each 24 hours so that no
undue traffic of system load is expected.  The configuration information
shared is related to what SIP services would expect.  Hence, there are no
transport issues expected.

The only bit to note is that the document makes just a brief reference to
QUIC in section 4.2.  Is this sufficient?  I am curious if a dedicated ALPN
should be used for this capability retrieval protocol or if general h3 is 
deemed sufficient.  The capability descriptions only refer to UDP, TCP,
and TLS, probably because SIP over QUIC wasn‘t defined yet.  Is there a
clear path on how such future transport would be integrated?  If so, would
it make sense to capture this already now?  (I don‘t know how much QUIC 
has made it into SIP signaling specifications, while RTP-over-QUIC is 
already being defined in AVT.)

That said, if QUIC is no immediate concern for the deployment of SIP
services, the document seems good to go.