Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
From: Rebecca VanRheenen <rvanrheenen@staff.rfc-editor.org>
In-Reply-To: <30011438-B075-4D42-B488-E5F6EBD2501E@appliedbits.com>
Date: Tue, 12 May 2026 11:19:42 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <FCBC232D-EECB-445D-BAD7-2F48A24E839E@staff.rfc-editor.org>
References: <20260501185412.0CD7D315052@rfcpa.rfc-editor.org>
 <30011438-B075-4D42-B488-E5F6EBD2501E@appliedbits.com>
To: Chris Wendt <chris@appliedbits.com>,
 jon.peterson@transunion.com
Message-ID-Hash: HHAY2ULTLUOLEB2XHXGV7ZSJJOHGMT4R
CC: RFC Editor <rfc-editor@rfc-editor.org>, stir-ads@ietf.org,
 stir-chairs@ietf.org, housley@vigilsec.com, eckelcu@cisco.com,
 auth48archive@rfc-editor.org
Precedence: list
Subject: =?utf-8?q?=5Bauth48=5D_Re=3A_AUTH48=3A_RFC-to-be_9970_=3Cdraft-ietf-stir-rfc?=
 =?utf-8?q?4916-update-07=3E_for_your_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/auth48archive/_JXJFrhRSuBdP3Ct9NTtf5g8KAU>

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.
>=20
> 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 =
=E2=80=9Ctraditional=E2=80=9D be updated in the document? If so, please =
indicate how to update.

> 8) <!-- [rfced] Please review the "Inclusive Language" portion of the =
online=20
> 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.
>=20
> Note that our script did not flag any words in particular, but this =
should=20
> still be reviewed as a best practice.
>=20
> In addition, please consider whether "traditional" should be updated =
for clarity. =20
> While the NIST website =
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-rese=
arch-library/nist-technical-series-publications-author-instructions#table1=
>
> indicates that "tradition" is potentially biased, it is also =
ambiguous. =20
> "Traditional" is a subjective term, as it is not the same for =
everyone.
>=20
> 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.  =20
> =E2=80=94>


=E2=80=94 FILES (please refresh) =E2=80=94

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=E2=80=AFAM, Chris Wendt =
<chris@appliedbits.com> wrote:
>=20
> I am good with all of the suggested changes including:=20
> 4 should use proposal 2
> 6a should be Session Description Protocol
> 7a an =E2=80=9Crsp=E2=80=9D sounds right to me but i=E2=80=99m ok with =
either decision
> 7b lowercase is probably appropriate if it=E2=80=99s not directly =
referring to Identity header field.
>=20
> Thanks!
>=20
> -Chris
>=20
>=20
>> On May 1, 2026, at 2:54=E2=80=AFPM, rfc-editor@rfc-editor.org wrote:
>>=20
>> Authors,
>>=20
>> While reviewing this document during AUTH48, please resolve (as =
necessary) the following questions, which are also in the source file.
>>=20
>> 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.
>>=20
>> a) Email address for Chris
>>=20
>> OLD:
>> chris-ietf@chriswendt.net
>>=20
>> NEW:
>> chris@appliedbits.com
>>=20
>>=20
>> 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.
>>=20
>> OLD:
>>  ... the only difference is in semantics, as the certificate
>>  signs for the "dest" header field rather than the "orig".
>>=20
>> NEW:
>>  ... the only difference is in semantics, as the PASSporT is
>>  signed to authenticate the "dest" claim value rather than the =
"orig".
>>=20
>> OLD:
>>  ... is eligible to sign responses/requests for
>>  the number in the "dest" field of the "rsp" PASSporT.
>>=20
>> NEW:
>>  ... is eligible to sign responses/requests for
>>  the number in the "dest" claim of the "rsp" PASSporT.
>>=20
>>=20
>> c) Change to sourcecode in Section 9
>>=20
>> OLD:
>> "x5u":"https://www.example.com/cert.cer"
>>=20
>> NEW:
>> "x5u":"https://www.example.com/cert.pem"
>> -->
>>=20
>>=20
>> 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.
>>=20
>> 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.
>> -->
>>=20
>>=20
>> 3) <!-- [rfced] Document title
>>=20
>> 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.
>>=20
>> Original:
>> Connected Identity for STIR
>>=20
>> Updated:
>> Connected Identity for Secure Telephone Identity Revisited (STIR)
>>=20
>>=20
>> b) We have also updated the abbreviated title as shown below to more =
closely align with the document title.
>>=20
>> Original:
>> Connected Identity
>>=20
>> Updated:
>> Connected Identity for STIR
>> -->
>>=20
>>=20
>> 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?
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>> -->
>>=20
>>=20
>> 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?
>>=20
>> 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.
>>=20
>> 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.
>> -->
>>=20
>>=20
>> 6) <!-- [rfced] Abbreviations
>>=20
>> a) How should SDP be expanded in this document? As "Session =
Description Protocol" or "Service Demarcation Point"?
>>=20
>> 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.
>>=20
>> Provisional Response Acknowledgement (PRACK)
>> Personal Assertion Token (PASSporT)=20
>> -->
>>=20
>>=20
>> 7) <!-- [rfced] Terminology
>>=20
>> 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:
>>=20
>> a "rsp"
>> an "rsp"
>>=20
>>=20
>> 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".
>>=20
>> However, we see the following inconsistency. May we update to use the =
lowercase form?
>>=20
>>  Identity mechanism - 1 instance
>>  identity mechanism - 2 instances
>>=20
>> Also, the capitalized form is used in the following sentences. Is =
this correct, or should the lowercase form be used here?
>>=20
>> 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, ...
>> -->
>>=20
>>=20
>> 8) <!-- [rfced] Please review the "Inclusive Language" portion of the =
online=20
>> 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.
>>=20
>> Note that our script did not flag any words in particular, but this =
should=20
>> still be reviewed as a best practice.
>>=20
>> In addition, please consider whether "traditional" should be updated =
for clarity. =20
>> While the NIST website =
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-rese=
arch-library/nist-technical-series-publications-author-instructions#table1=
>
>> indicates that "tradition" is potentially biased, it is also =
ambiguous. =20
>> "Traditional" is a subjective term, as it is not the same for =
everyone.
>>=20
>> 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.  =20
>> -->=20
>>=20
>>=20
>> Thank you.
>>=20
>> Rebecca VanRheenen
>> RFC Production Center
>>=20
>>=20
>>=20
>> On May 1, 2026, at 11:51=E2=80=AFAM, rfc-editor@rfc-editor.org wrote:
>>=20
>> *****IMPORTANT*****
>>=20
>> Updated 2026/05/01
>>=20
>> RFC Author(s):
>> --------------
>>=20
>> Instructions for Completing AUTH48
>>=20
>> Your document has now entered AUTH48.  Once it has been reviewed and=20=

>> approved by you and all coauthors, it will be published as an RFC. =20=

>> If an author is no longer available, there are several remedies=20
>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>=20
>> You and you coauthors are responsible for engaging other parties=20
>> (e.g., Contributors or Working Group) as necessary before providing=20=

>> your approval.
>>=20
>> Planning your review=20
>> ---------------------
>>=20
>> Please review the following aspects of your document:
>>=20
>> *  RFC Editor questions
>>=20
>>  Please review and resolve any questions raised by the RFC Editor=20
>>  that have been included in the XML file as comments marked as=20
>>  follows:
>>=20
>>  <!-- [rfced] ... -->
>>=20
>>  These questions will also be sent in a subsequent email.
>>=20
>> *  Changes submitted by coauthors=20
>>=20
>>  Please ensure that you review any changes submitted by your=20
>>  coauthors.  We assume that if you do not speak up that you=20
>>  agree to changes submitted by your coauthors.
>>=20
>> *  Content=20
>>=20
>>  Please review the full content of the document, as this cannot=20
>>  change once the RFC is published.  Please pay particular attention =
to:
>>  - IANA considerations updates (if applicable)
>>  - contact information
>>  - references
>>=20
>> *  Copyright notices and legends
>>=20
>>  Please review the copyright notice and legends as defined in
>>  RFC 5378 and the Trust Legal Provisions=20
>>  (TLP =E2=80=93 https://trustee.ietf.org/license-info).
>>=20
>> *  Semantic markup
>>=20
>>  Please review the markup in the XML file to ensure that elements of =20=

>>  content are correctly tagged.  For example, ensure that <sourcecode>=20=

>>  and <artwork> are set correctly.  See details at=20
>>  <https://authors.ietf.org/rfcxml-vocabulary>.
>>=20
>> *  Formatted output
>>=20
>>  Please review the PDF, HTML, and TXT files to ensure that the=20
>>  formatted output, as generated from the markup in the XML file, is=20=

>>  reasonable.  Please note that the TXT will have formatting=20
>>  limitations compared to the PDF and HTML.
>>=20
>>=20
>> Submitting changes
>> ------------------
>>=20
>> To submit changes, please reply to this email using =E2=80=98REPLY =
ALL=E2=80=99 as all=20
>> the parties CCed on this message need to see your changes. The =
parties=20
>> include:
>>=20
>>  *  your coauthors
>>=20
>>  *  rfc-editor@rfc-editor.org (the RPC team)
>>=20
>>  *  other document participants, depending on the stream (e.g.,=20
>>     IETF Stream participants are your working group chairs, the=20
>>     responsible ADs, and the document shepherd).
>>=20
>>  *  auth48archive@rfc-editor.org, which is a new archival mailing =
list=20
>>     to preserve AUTH48 conversations; it is not an active discussion=20=

>>     list:
>>=20
>>    *  More info:
>>       =
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P=
8O4Zc
>>=20
>>    *  The archive itself:
>>       https://mailarchive.ietf.org/arch/browse/auth48archive/
>>=20
>>    *  Note: If only absolutely necessary, you may temporarily opt out=20=

>>       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=20=

>>       have dropped the address. When the discussion is concluded,=20
>>       auth48archive@rfc-editor.org will be re-added to the CC list =
and=20
>>       its addition will be noted at the top of the message.=20
>>=20
>> You may submit your changes in one of two ways:
>>=20
>> An update to the provided XML file
>> =E2=80=94 OR =E2=80=94
>> An explicit list of changes in this format
>>=20
>> Section # (or indicate Global)
>>=20
>> OLD:
>> old text
>>=20
>> NEW:
>> new text
>>=20
>> You do not need to reply with both an updated XML file and an =
explicit=20
>> list of changes, as either form is sufficient.
>>=20
>> 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,=20
>> and technical changes.  Information about stream managers can be =
found in=20
>> the FAQ.  Editorial changes do not require approval from a stream =
manager.
>>=20
>>=20
>> Approving for publication
>> --------------------------
>>=20
>> To approve your RFC for publication, please reply to this email =
stating
>> that you approve this RFC for publication.  Please use =E2=80=98REPLY =
ALL=E2=80=99,
>> as all the parties CCed on this message need to see your approval.
>>=20
>>=20
>> Files=20
>> -----
>>=20
>> 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
>>=20
>> 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)
>>=20
>> Diff of the XML:=20
>>  https://www.rfc-editor.org/authors/rfc9970-xmldiff1.html
>>=20
>>=20
>> Tracking progress
>> -----------------
>>=20
>> The details of the AUTH48 status of your document are here:
>>  https://www.rfc-editor.org/auth48/rfc9970
>>=20
>> Please let us know if you have any questions. =20
>>=20
>> Thank you for your cooperation,
>>=20
>> RFC Editor
>>=20
>> --------------------------------------
>> RFC9970 (draft-ietf-stir-rfc4916-update-07)
>>=20
>> 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
>>=20
>>=20
>=20