Hi Joel,
Thanks for the comments. We’ll go through them and provide a revised version as soon as possible.
Regards
Sreekanth
From:
Joel Halpern via Datatracker <noreply@xxxxxxxx>
Date: Sunday, 9 February 2025 at 6:24 PM
To: gen-art@xxxxxxxx <gen-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: Genart last call review of draft-ietf-asap-sip-auto-peer-18
Reviewer: Joel Halpern
Review result: Ready with Issues
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:
|
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
