[Last-Call] Re: [Tsv-art] Re: Tsvart telechat review of draft-ietf-asap-sip-auto-peer-20

[Jörg Ott <ott@xxxxxxxxx>]

Hi Sreekanth,

Yes, this works for me, mostly curious.

Best,

Jörg

Sent from my iPhone

On 27. Feb 2025, at 18:58, Sreekanth Narayanan (sreenara) <sreenara=40cisco.com@xxxxxxxxxxxxxx> wrote:



Hi Joerg,

 

Thanks for your review. We did not specifically mention QUIC because this draft primarily focuses on enabling an enterprise network to peer with a service provider network and successfully complete SIP registration and calls. Once RTP-over-QUIC is more widespread, we will certainly consider extending or enhancing the capability set model to cover QUIC as a transport mechanism as well.

 

Does this sound like an acceptable way to proceed?

 

Regards

Sreekanth

 

From: Joerg Ott via Datatracker <noreply@xxxxxxxx>
Date: Wednesday, 26 February 2025 at 4:56 PM
To: tsv-art@xxxxxxxx <tsv-art@xxxxxxxx>
Cc: asap@xxxxxxxx <asap@xxxxxxxx>, draft-ietf-asap-sip-auto-peer.all@xxxxxxxx <draft-ietf-asap-sip-auto-peer.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: Tsvart telechat review of draft-ietf-asap-sip-auto-peer-20

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