[Asap] Opsdir last call review of draft-ietf-asap-siptrunkingcapability-link-03

Joe Clarke via Datatracker <noreply@ietf.org> Fri, 10 March 2023 15:46 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: asap@ietf.org
Delivered-To: asap@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0415BC1CCCBF; Fri, 10 Mar 2023 07:46:51 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joe Clarke via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: asap@ietf.org, draft-ietf-asap-siptrunkingcapability-link.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.14.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <167846321100.24549.16402590137064715749@ietfa.amsl.com>
Reply-To: Joe Clarke <jclarke@cisco.com>
Date: Fri, 10 Mar 2023 07:46:51 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/asap/mGfpTmVRRVVizmVvQRXheS2XR4Q>
Subject: [Asap] Opsdir last call review of draft-ietf-asap-siptrunkingcapability-link-03
X-BeenThere: asap@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Automatic SIP trunking And Peering WG <asap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/asap>, <mailto:asap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/asap/>
List-Post: <mailto:asap@ietf.org>
List-Help: <mailto:asap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/asap>, <mailto:asap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Mar 2023 15:46:51 -0000

Reviewer: Joe Clarke
Review result: Has Nits

I have been tasked to review this document on behalf of the OPS directorate. 
This document describes a means by which link relationships may be used to
advertise SIP trunking capabilities for an ITSP.  The document is short, sweet,
to the point, and clear.  Overall, I had one question and a small nit.

In section 3, it is stated that an ITSP may use an authentication framework...

Should this language be stronger and normative?  That is, should this be a
SHOULD?  Or perhaps this is best left to the document on the capability set
document.  As it stands now, it felt like an aside as I read it.

My nit is that in the example href, should the URL be
https://capserver.ssp1.example.com?