I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-asap-sip-auto-peer-18
Reviewer: Joel Halpern
Review Date: 2025-02-08
IETF LC End Date: 2025-02-21
IESG Telechat date: 2025-03-06

Summary: This document is ready for publication as a proposed standard.  Some minor issues caught my eye as I was reading the document.

Major issues: N/A

Minor issues:
    Section 4 on Transport discusses using HTTP.  That is the point of the document.  What caught my eye is that the section specifies the use of HTTP 1.1.  My understanding is that the current IETF standard is HTTP/3 using QUIC.  I can understand wanting to permit use of 1.1, but I would think there would be a discussion of using HTTP/3?  For example, the security requirements are structured a little differently as one doesn't need to check for / configure use of TLS, as security is a mandatory part of QUIC?  I presume resolving this is mostly just a matter of noting that NTTP/3 works.

    Is there an assumption in section 4.5 that the webfinger server host name is more aasily knowable than than capability server host name itself?  I suspect that there is a good reason for such an assumption, but it is not obvious to this reader what assumption that needs?

    I presume that the inclusion of syntax definitions for IP addresses is a deliberate choice so that this YANG definition provides a free-standing definition for the JSON, not requiring access to the YANG repositories?  If so, that should be explicitly stated.

     This is probably a naive question that is obvious to aa frequent SIP user.  Is there some reference to the meaning and usage of "realm" in the YANG encoding of capabilities that explains why including a password in a world-readable JSON document is a good thing?

    As I read this, it seems that the SIP server capabilities is a common document served to all SIP enterprise users.   However, tucked into the YANG is the numranges to represent the direct inward dial prefixes for the client.  If the server is expected to serve different capabilities documents to different client, then this should be explained.  (I can see that this can be done securely, given the requirements for oAuth authentication of the client.)  That would also answer the above question, since then presumably the user name and password are specific to the client, and only sent via HTTPS to the specific client?  Not sure where the4 best place in the document to clarify this would be?   Maybe the opening paragraph of 7.3 if not before that?

Nits/editorial comments: