Last Call Review of draft-ietf-asap-siptrunkingcapability-link-03
review-ietf-asap-siptrunkingcapability-link-03-artart-lc-bray-2023-03-10-00

Request Review of draft-ietf-asap-siptrunkingcapability-link
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2023-03-22
Requested 2023-03-08
Authors Kaustubh Inamdar , Sreekanth Narayanan , Derek Engi , Gonzalo Salgueiro
I-D last updated 2023-03-10
Completed reviews Genart Last Call review of -03 by Dan Romascanu (diff)
Secdir Last Call review of -03 by Christopher A. Wood (diff)
Artart Last Call review of -03 by Tim Bray (diff)
Opsdir Last Call review of -03 by Joe Clarke (diff)
Assignment Reviewer Tim Bray
State Completed
Review review-ietf-asap-siptrunkingcapability-link-03-artart-lc-bray-2023-03-10
Posted at https://mailarchive.ietf.org/arch/msg/art/_Tn_lZnEn7OyYL-vaYNySKdrHlk
Reviewed revision 03 (document currently at 05)
Result Ready w/nits
Completed 2023-03-10
review-ietf-asap-siptrunkingcapability-link-03-artart-lc-bray-2023-03-10-00
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?