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-stir-rfc4916-update-06
Reviewer: Elwyn Davies
Review Date: 2024-11-23
IETF LC End Date: 2024-11-19
IESG Telechat date: Not scheduled for a telechat

Summary: Essentially ready with a few minor nits except that I am not sure whether it should state that it updates RFC 4916 in the header and may need to be more explicit about exactly what it updates in RFC 4916.  The explanations seem sensible and are well explained but I am not a SIP guru so I am not able to vouch for the completeness or technical accuracy of the use cases.

Major issues:
None

Minor issues:
s1, para 3:  The document refers to superseding the guidance of RFC 4916 and fixing the interactions with SIPBRANDY.  Does this mean that thi document should declare that it updates RFC 4916.  If so, should it be more explicit about which parts of RFC 4916 are updated and how.

Nits/editorial comments:
General: s/e.g. /e.g., /  (3 places - one is an end of line)

Abstract:  Add a reference to RFC 8224 which features the introduction of the STIR framework, updating  SIP Identity and possibly to RFC 4474 that originally introduced SIP Identity.

s1, para 1: expand vishing - vishing (voice phishing) - I think the term is not used in RFC 7340.

s1, last para: s/This scope/The scope/

s3, para 2: s/various mechanisms like private ENUM [RFC6116] might be consulted/potentially using various mechanisms such as consulting a private ENUM [RFC6116]/

s3, para 3: s/just like dialog-forming requests/in the same way as dialog-forming requests/

s7, para 2: s/because the keys exchanges/because the keys exchanged/

s8, para 1: I think there may be a problem, with this sentence:
>    Some sort of directory service might exist advertising support for
>    connected identity which institutions could use to inform potential
>    callers that, if connected identity is supported when reaching them
>    with SIP, there is a potential security problem.
I think it is trying to say that the if a call to an identity in a location that supports connected identity, according to the directory, doesn't respond with appropriate connected identity type responses then the caller should be suspicious.  This may just be a missing 'not' thus:
          if connected identity is NOT supported when reaching them with SIP,