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

Tim Bray via Datatracker <noreply@ietf.org> Fri, 10 March 2023 17:42 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 495C3C16B5AE; Fri, 10 Mar 2023 09:42:56 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Tim Bray via Datatracker <noreply@ietf.org>
To: art@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: <167847017629.24446.1620622805905245537@ietfa.amsl.com>
Reply-To: Tim Bray <tbray@textuality.com>
Date: Fri, 10 Mar 2023 09:42:56 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/asap/Kw_1BLPh9tv0hG1XrWvRWLi5wuo>
Subject: [Asap] Artart 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 17:42:56 -0000

Reviewer: Tim Bray
Review result: Ready with Nits

I am the designated Artart Last Call reviewer for
draft-ietf-asap-siptrunkingcapability-link-03.

This document is good; I remember almost nothing about SIP and it was still
easy to understand. Nits:

- Reading section 1, I wondered what dereferencing a URI with this link type
would yield. Following the reference to draft-ietf-asap-sip-auto-peer-07, I
eventually found the YANG definition, but I was a little surprised that it
didn't seem to register a media type?  Now, RFC8288 is careful to decouple link
types and media types, but the lack of a media type does feel like a gap. - In
the GET example in section 3, maybe a note that the line-breaks & indentation
are there for clarity? As presented it's not a valid GET request. - In the
security considerations, perhaps a reference to
draft-ietf-asap-sip-auto-peer#name-security-considerations would be helpful?