[auth48] Re: AUTH48: RFC-to-be 9970 <draft-ietf-stir-rfc4916-update-07> for your review

[Chris Wendt <[e-mail]>]

Hi Rebecca,

Thanks for the reminders, and apologies for the delay, i didn’t recognize there was still outstanding questions for me or Jon. Responses to the two open followup questions below.

2) Updates relationship to RFC 4916

No formal Updates relationship is needed, please leave the document header as-is (no "Updates: 4916"), and no abstract change.

This document borrows the connected-identity concepts of RFC 4916 and recasts them in the context of STIR mechanisms; it doesn't revise or extend RFC 4916 itself. RFC 4916 also depends on RFC 4474, which has since been obsoleted by RFC 8224, so it stands as a legacy specification rather than something this document updates.

To keep the body consistent with that, please revise the one sentence that currently implies a supersede relationship:

OLD: With the obsolescence of [RFC4474] by [RFC8224], this specification supersedes the guidance of [RFC4916] to reflect the changes to the SIP Identity header field and the revised problem space of STIR.

NEW: With the obsolescence of [RFC4474] by [RFC8224], this specification adapts the connected-identity concepts of [RFC4916] to STIR, reflecting the changes to the SIP Identity header field and the revised problem space that STIR introduces.

(The remaining "updates prior guidance on the 'connected identity' problem" phrasing in the Introduction is meant in the general sense of updated guidance on the problem, not a formal RFC relationship, no change needed there.)

8) Inclusive language / "traditional"

For the two instances of "traditional," please update both to “conventional” and that should work:

Section 1 (Introduction) - OLD: ...provides no means for determining the identity of the called party in a traditional telephone-calling scenario. NEW: ...provides no means for determining the identity of the called party in a conventional telephone-calling scenario.

OLD: In a traditional telephone call, the called party receives an alerting signal and can make a decision about whether or not to pick up a phone. NEW: In a conventional telephone call, the called party receives an alerting signal and can make a decision about whether or not to pick up a phone.

Thanks

-Chris


> On Jun 3, 2026, at 5:20 PM, Rebecca VanRheenen <[e-mail]> wrote:
> 
> Hi Chris and Jon,
> 
> This is a friendly weekly reminder that this document awaits your review and approval. 
> 
> Chris responded to the initial questions, but three followup questions (see email thread below) still need to be addressed.
> 
> Best regards,
> 
> Rebecca VanRheenen
> RFC Production Center
> 
> 
> 
>> On May 27, 2026, at 12:22 PM, Rebecca VanRheenen <[e-mail]> wrote:
>> 
>> Hi Chris and Jon,
>> 
>> This is another friendly weekly reminder that this document awaits your review and approval. 
>> 
>> Note that Chris responded to the initial questions (thank you!); the email thread below contains three followup questions that still need to be addressed.
>> 
>> Best regards,
>> 
>> Rebecca VanRheenen
>> RFC Production Center
>> 
>> 
>> 
>>> On May 20, 2026, at 4:30 PM, Rebecca VanRheenen <[e-mail]> wrote:
>>> 
>>> Hi Chris and Jon,
>>> 
>>> This is a friendly weekly reminder that this document awaits your attention. 
>>> 
>>> Chris responded to the initial questions; the followup questions are in the email thread below.
>>> 
>>> We look forward to hearing from you.
>>> 
>>> Best regards,
>>> 
>>> Rebecca VanRheenen
>>> RFC Production Center
>>> 
>>> 
>>>> On May 12, 2026, at 11:19 AM, Rebecca VanRheenen <[e-mail]> wrote:
>>>> 
>>>> Hi Chris,
>>>> 
>>>> Thanks for the reply! We have updated the document accordingly (see list of updated files below). We also have a few followup questions and comments:
>>>> 
>>>> a) We will wait for Jon to review the changes in questions #1b and #1c:
>>>> 
>>>> b) Are any changes needed per the question below? That is, should the document header and abstract indicate that this document updates RFC 4916?
>>>> 
>>>>> 2) <!-- [rfced] The document header does not indicate that this document updates RFC 4916. However, some text in the document (see below) seems to indicate a possible Updates relationship with RFC 4916. Please review and let us know if any changes are needed.
>>>>> 
>>>>> Original:
>>>>> This document
>>>>> updates prior guidance on the "connected identity" problem to reflect
>>>>> the changes to SIP Identity that accompanied STIR, ...
>>>>> ...
>>>>> With the obsolescence of [RFC4474] by [RFC8224], this specification
>>>>> supersedes the guidance of [RFC4916] to reflect the changes to the
>>>>> SIP Identity header field and the revised problem space of STIR.
>>>>> -->
>>>> 
>>>> c) Per the following question, should the two instances of “traditional” be updated in the document? If so, please indicate how to update.
>>>> 
>>>>> 8) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
>>>>> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>>>>> and let us know if any changes are needed.  Updates of this nature typically
>>>>> result in more precise language, which is helpful for readers.
>>>>> 
>>>>> Note that our script did not flag any words in particular, but this should 
>>>>> still be reviewed as a best practice.
>>>>> 
>>>>> In addition, please consider whether "traditional" should be updated for clarity.  
>>>>> While the NIST website <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
>>>>> indicates that "tradition" is potentially biased, it is also ambiguous.  
>>>>> "Traditional" is a subjective term, as it is not the same for everyone.
>>>>> 
>>>>> Original:
>>>>> The Secure Telephone Identity Revisited (STIR) framework,
>>>>> however, provides no means for determining the identity of the called
>>>>> party in a traditional telephone-calling scenario.
>>>>> ...
>>>>> In a traditional telephone call, the called party receives an
>>>>> alerting signal and can make a decision about whether or not to pick
>>>>> up a phone.   
>>>>> —>
>>>> 
>>>> 
>>>> — FILES (please refresh) —
>>>> 
>>>> Updated XML file:
>>>> https://www.rfc-editor.org/authors/rfc9970.xml
>>>> 
>>>> Updated output files:
>>>> https://www.rfc-editor.org/authors/rfc9970.txt
>>>> https://www.rfc-editor.org/authors/rfc9970.pdf
>>>> https://www.rfc-editor.org/authors/rfc9970.html
>>>> 
>>>> Diff files showing all changes made during AUTH48:
>>>> https://www.rfc-editor.org/authors/rfc9970-auth48diff.html
>>>> https://www.rfc-editor.org/authors/rfc9970-auth48rfcdiff.html (side by side)
>>>> 
>>>> Diff files showing all changes:
>>>> https://www.rfc-editor.org/authors/rfc9970-diff.html
>>>> https://www.rfc-editor.org/authors/rfc9970-rfcdiff.html (side by side)
>>>> 
>>>> For the AUTH48 status of this document, please see:
>>>> https://www.rfc-editor.org/auth48/rfc9970
>>>> 
>>>> Thank you,
>>>> 
>>>> Rebecca VanRheenen
>>>> RFC Production Center
>>>> 
>>>> 
>>>> 
>>>>> On May 11, 2026, at 11:48 AM, Chris Wendt <[e-mail]> wrote:
>>>>> 
>>>>> I am good with all of the suggested changes including: 
>>>>> 4 should use proposal 2
>>>>> 6a should be Session Description Protocol
>>>>> 7a an “rsp” sounds right to me but i’m ok with either decision
>>>>> 7b lowercase is probably appropriate if it’s not directly referring to Identity header field.
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> -Chris
>>>>> 
>>>>> 
>>>>>> On May 1, 2026, at 2:54 PM, [e-mail] wrote:
>>>>>> 
>>>>>> Authors,
>>>>>> 
>>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
>>>>>> 
>>>>>> 1) <!-- [rfced] We made the following changes per Chris's reply to the document intake form. Chris indicated that he would like for Jon to confirm that he agrees with the changes in b) and c) below; please review and confirm.
>>>>>> 
>>>>>> a) Email address for Chris
>>>>>> 
>>>>>> OLD:
>>>>>> [e-mail]
>>>>>> 
>>>>>> NEW:
>>>>>> [e-mail]
>>>>>> 
>>>>>> 
>>>>>> b) Changes to text. Please also review to let us know if any other similar changes should be made; we see other instances of '"dest" header field' and '"dest" field' in the document.
>>>>>> 
>>>>>> OLD:
>>>>>> ... the only difference is in semantics, as the certificate
>>>>>> signs for the "dest" header field rather than the "orig".
>>>>>> 
>>>>>> NEW:
>>>>>> ... the only difference is in semantics, as the PASSporT is
>>>>>> signed to authenticate the "dest" claim value rather than the "orig".
>>>>>> 
>>>>>> OLD:
>>>>>> ... is eligible to sign responses/requests for
>>>>>> the number in the "dest" field of the "rsp" PASSporT.
>>>>>> 
>>>>>> NEW:
>>>>>> ... is eligible to sign responses/requests for
>>>>>> the number in the "dest" claim of the "rsp" PASSporT.
>>>>>> 
>>>>>> 
>>>>>> c) Change to sourcecode in Section 9
>>>>>> 
>>>>>> OLD:
>>>>>> "x5u":"https://www.example.com/cert.cer"
>>>>>> 
>>>>>> NEW:
>>>>>> "x5u":"https://www.example.com/cert.pem"
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> 2) <!-- [rfced] The document header does not indicate that this document updates RFC 4916. However, some text in the document (see below) seems to indicate a possible Updates relationship with RFC 4916. Please review and let us know if any changes are needed.
>>>>>> 
>>>>>> Original:
>>>>>> This document
>>>>>> updates prior guidance on the "connected identity" problem to reflect
>>>>>> the changes to SIP Identity that accompanied STIR, ...
>>>>>> ...
>>>>>> With the obsolescence of [RFC4474] by [RFC8224], this specification
>>>>>> supersedes the guidance of [RFC4916] to reflect the changes to the
>>>>>> SIP Identity header field and the revised problem space of STIR.
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> 3) <!-- [rfced] Document title
>>>>>> 
>>>>>> a) Please note that the title of the document has been updated as follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review.
>>>>>> 
>>>>>> Original:
>>>>>> Connected Identity for STIR
>>>>>> 
>>>>>> Updated:
>>>>>> Connected Identity for Secure Telephone Identity Revisited (STIR)
>>>>>> 
>>>>>> 
>>>>>> b) We have also updated the abbreviated title as shown below to more closely align with the document title.
>>>>>> 
>>>>>> Original:
>>>>>> Connected Identity
>>>>>> 
>>>>>> Updated:
>>>>>> Connected Identity for STIR
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> 4) <!-- [rfced] How may we revise this sentence to clarify how the text starting with "as well as ..." connects to the rest of the sentence?
>>>>>> 
>>>>>> Original:
>>>>>> This document
>>>>>> updates prior guidance on the "connected identity" problem to reflect
>>>>>> the changes to SIP Identity that accompanied STIR, and considers a
>>>>>> revised problem space for connected identity as a means of detecting
>>>>>> calls that have been retargeted to a party impersonating the intended
>>>>>> destination, as well as the spoofing of mid-dialog or dialog-
>>>>>> terminating events by intermediaries or third parties.
>>>>>> 
>>>>>> Perhaps 1 ("detecting both calls ... and the spoofing"):
>>>>>> This document
>>>>>> updates prior guidance on the "connected identity" problem to reflect
>>>>>> the changes to SIP Identity that accompanied STIR. It also considers a
>>>>>> revised problem space for connected identity as a means of detecting
>>>>>> both calls that have been retargeted to a party impersonating the intended
>>>>>> destination and the spoofing of mid-dialog or dialog-
>>>>>> terminating events by intermediaries or third parties.
>>>>>> 
>>>>>> Perhaps 2 ("detecting calls ... and preventing the spoofing"):
>>>>>> This document
>>>>>> updates prior guidance on the "connected identity" problem to reflect
>>>>>> the changes to SIP Identity that accompanied STIR. It also considers a
>>>>>> revised problem space for connected identity as a means of detecting
>>>>>> calls that have been retargeted to a party impersonating the intended
>>>>>> destination and preventing the spoofing of mid-dialog or dialog-
>>>>>> terminating events by intermediaries or third parties.
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> 5) <!-- [rfced] The following phrase in this sentence is difficult to follow: "upon receiving an INVITE with no SDP, carrying a PASSporT, with a 100rel in the Require header field value". How may we update for clarity?
>>>>>> 
>>>>>> Original:
>>>>>> STIR-aware UASes that support
>>>>>> this specification, upon receiving an INVITE with no SDP, carrying a
>>>>>> PASSporT, with a 100rel in the Require header field value, SHOULD
>>>>>> follow the mechanism described in Section 4 to send a provisional
>>>>>> response carrying a PASSporT in the backwards direction.
>>>>>> 
>>>>>> Perhaps:
>>>>>> When a STIR-aware UAS that supports this specification receives an
>>>>>> INVITE that has no SDP, carries a PASSporT, and includes 100rel in the
>>>>>> Require header field, it SHOULD follow the mechanism described in
>>>>>> Section 4 to send a provisional response carrying a PASSporT in the
>>>>>> backwards direction.
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> 6) <!-- [rfced] Abbreviations
>>>>>> 
>>>>>> a) How should SDP be expanded in this document? As "Session Description Protocol" or "Service Demarcation Point"?
>>>>>> 
>>>>>> b) We have added expansions for the following abbreviation(s) per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness.
>>>>>> 
>>>>>> Provisional Response Acknowledgement (PRACK)
>>>>>> Personal Assertion Token (PASSporT) 
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> 7) <!-- [rfced] Terminology
>>>>>> 
>>>>>> a) How is "rsp" pronounced? We ask in order to choose the appropriate indefinite article for it to follow (i.e., "a" or "an"). We see both of the following forms in the document:
>>>>>> 
>>>>>> a "rsp"
>>>>>> an "rsp"
>>>>>> 
>>>>>> 
>>>>>> b) We see both "identity" (lowercase) and "Identity" (capitalized) used in this document. The lowercase form is used consistently in the context of "connected identity", and the capitalized form is used consistently in the context of "Identity header field".
>>>>>> 
>>>>>> However, we see the following inconsistency. May we update to use the lowercase form?
>>>>>> 
>>>>>> Identity mechanism - 1 instance
>>>>>> identity mechanism - 2 instances
>>>>>> 
>>>>>> Also, the capitalized form is used in the following sentences. Is this correct, or should the lowercase form be used here?
>>>>>> 
>>>>>> Original:
>>>>>> This document updates prior guidance on the "connected identity" problem
>>>>>> to reflect the changes to SIP Identity that accompanied STIR ...
>>>>>> ...
>>>>>> While a mid-dialog request in the backwards direction (e.g., UPDATE)
>>>>>> can be signed with Identity like any other SIP request, ...
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> 8) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
>>>>>> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>>>>>> and let us know if any changes are needed.  Updates of this nature typically
>>>>>> result in more precise language, which is helpful for readers.
>>>>>> 
>>>>>> Note that our script did not flag any words in particular, but this should 
>>>>>> still be reviewed as a best practice.
>>>>>> 
>>>>>> In addition, please consider whether "traditional" should be updated for clarity.  
>>>>>> While the NIST website <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
>>>>>> indicates that "tradition" is potentially biased, it is also ambiguous.  
>>>>>> "Traditional" is a subjective term, as it is not the same for everyone.
>>>>>> 
>>>>>> Original:
>>>>>> The Secure Telephone Identity Revisited (STIR) framework,
>>>>>> however, provides no means for determining the identity of the called
>>>>>> party in a traditional telephone-calling scenario.
>>>>>> ...
>>>>>> In a traditional telephone call, the called party receives an
>>>>>> alerting signal and can make a decision about whether or not to pick
>>>>>> up a phone.   
>>>>>> --> 
>>>>>> 
>>>>>> 
>>>>>> Thank you.
>>>>>> 
>>>>>> Rebecca VanRheenen
>>>>>> RFC Production Center
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On May 1, 2026, at 11:51 AM, [e-mail] wrote:
>>>>>> 
>>>>>> *****IMPORTANT*****
>>>>>> 
>>>>>> Updated 2026/05/01
>>>>>> 
>>>>>> RFC Author(s):
>>>>>> --------------
>>>>>> 
>>>>>> Instructions for Completing AUTH48
>>>>>> 
>>>>>> Your document has now entered AUTH48.  Once it has been reviewed and 
>>>>>> approved by you and all coauthors, it will be published as an RFC.  
>>>>>> If an author is no longer available, there are several remedies 
>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/)
>>>>>> 
>>>>>> You and you coauthors are responsible for engaging other parties 
>>>>>> (e.g., Contributors or Working Group) as necessary before providing 
>>>>>> your approval.
>>>>>> 
>>>>>> Planning your review 
>>>>>> ---------------------
>>>>>> 
>>>>>> Please review the following aspects of your document:
>>>>>> 
>>>>>> *  RFC Editor questions
>>>>>> 
>>>>>> Please review and resolve any questions raised by the RFC Editor 
>>>>>> that have been included in the XML file as comments marked as 
>>>>>> follows:
>>>>>> 
>>>>>> <!-- [rfced] ... -->
>>>>>> 
>>>>>> These questions will also be sent in a subsequent email.
>>>>>> 
>>>>>> *  Changes submitted by coauthors 
>>>>>> 
>>>>>> Please ensure that you review any changes submitted by your 
>>>>>> coauthors.  We assume that if you do not speak up that you 
>>>>>> agree to changes submitted by your coauthors.
>>>>>> 
>>>>>> *  Content 
>>>>>> 
>>>>>> Please review the full content of the document, as this cannot 
>>>>>> change once the RFC is published.  Please pay particular attention to:
>>>>>> - IANA considerations updates (if applicable)
>>>>>> - contact information
>>>>>> - references
>>>>>> 
>>>>>> *  Copyright notices and legends
>>>>>> 
>>>>>> Please review the copyright notice and legends as defined in
>>>>>> RFC 5378 and the Trust Legal Provisions 
>>>>>> (TLP – https://trustee.ietf.org/license-info)
>>>>>> 
>>>>>> *  Semantic markup
>>>>>> 
>>>>>> Please review the markup in the XML file to ensure that elements of  
>>>>>> content are correctly tagged.  For example, ensure that <sourcecode> 
>>>>>> and <artwork> are set correctly.  See details at 
>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>>>>> 
>>>>>> *  Formatted output
>>>>>> 
>>>>>> Please review the PDF, HTML, and TXT files to ensure that the 
>>>>>> formatted output, as generated from the markup in the XML file, is 
>>>>>> reasonable.  Please note that the TXT will have formatting 
>>>>>> limitations compared to the PDF and HTML.
>>>>>> 
>>>>>> 
>>>>>> Submitting changes
>>>>>> ------------------
>>>>>> 
>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
>>>>>> the parties CCed on this message need to see your changes. The parties 
>>>>>> include:
>>>>>> 
>>>>>> *  your coauthors
>>>>>> 
>>>>>> *  [e-mail] (the RPC team)
>>>>>> 
>>>>>> *  other document participants, depending on the stream (e.g., 
>>>>>> IETF Stream participants are your working group chairs, the 
>>>>>> responsible ADs, and the document shepherd).
>>>>>> 
>>>>>> *  [e-mail], which is a new archival mailing list 
>>>>>> to preserve AUTH48 conversations; it is not an active discussion 
>>>>>> list:
>>>>>> 
>>>>>> *  More info:
>>>>>>   https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>>>> 
>>>>>> *  The archive itself:
>>>>>>   https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>> 
>>>>>> *  Note: If only absolutely necessary, you may temporarily opt out 
>>>>>>   of the archiving of messages (e.g., to discuss a sensitive matter).
>>>>>>   If needed, please add a note at the top of the message that you 
>>>>>>   have dropped the address. When the discussion is concluded, 
>>>>>>   [e-mail] will be re-added to the CC list and 
>>>>>>   its addition will be noted at the top of the message. 
>>>>>> 
>>>>>> You may submit your changes in one of two ways:
>>>>>> 
>>>>>> An update to the provided XML file
>>>>>> — OR —
>>>>>> An explicit list of changes in this format
>>>>>> 
>>>>>> Section # (or indicate Global)
>>>>>> 
>>>>>> OLD:
>>>>>> old text
>>>>>> 
>>>>>> NEW:
>>>>>> new text
>>>>>> 
>>>>>> You do not need to reply with both an updated XML file and an explicit 
>>>>>> list of changes, as either form is sufficient.
>>>>>> 
>>>>>> We will ask a stream manager to review and approve any changes that seem
>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, 
>>>>>> and technical changes.  Information about stream managers can be found in 
>>>>>> the FAQ.  Editorial changes do not require approval from a stream manager.
>>>>>> 
>>>>>> 
>>>>>> Approving for publication
>>>>>> --------------------------
>>>>>> 
>>>>>> To approve your RFC for publication, please reply to this email stating
>>>>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>>>>>> as all the parties CCed on this message need to see your approval.
>>>>>> 
>>>>>> 
>>>>>> Files 
>>>>>> -----
>>>>>> 
>>>>>> The files are available here:
>>>>>> https://www.rfc-editor.org/authors/rfc9970.xml
>>>>>> https://www.rfc-editor.org/authors/rfc9970.html
>>>>>> https://www.rfc-editor.org/authors/rfc9970.pdf
>>>>>> https://www.rfc-editor.org/authors/rfc9970.txt
>>>>>> 
>>>>>> Diff file of the text:
>>>>>> https://www.rfc-editor.org/authors/rfc9970-diff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9970-rfcdiff.html (side by side)
>>>>>> 
>>>>>> Diff of the XML: 
>>>>>> https://www.rfc-editor.org/authors/rfc9970-xmldiff1.html
>>>>>> 
>>>>>> 
>>>>>> Tracking progress
>>>>>> -----------------
>>>>>> 
>>>>>> The details of the AUTH48 status of your document are here:
>>>>>> https://www.rfc-editor.org/auth48/rfc9970
>>>>>> 
>>>>>> Please let us know if you have any questions.  
>>>>>> 
>>>>>> Thank you for your cooperation,
>>>>>> 
>>>>>> RFC Editor
>>>>>> 
>>>>>> --------------------------------------
>>>>>> RFC9970 (draft-ietf-stir-rfc4916-update-07)
>>>>>> 
>>>>>> Title            : Connected Identity for STIR
>>>>>> Author(s)        : J. Peterson, C. Wendt
>>>>>> WG Chair(s)      : Ben Campbell, Robert Sparks, Russ Housley
>>>>>> Area Director(s) : Andy Newton, Charles Eckel
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>