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 tsv-art@xxxxxxxx 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
