Hi Jon, This is a friendly weekly reminder that we await your approval before proceeding with publication. We have listed the updated files below for convenience. Please review the files carefully as we do not make changes after publication.
The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9888.txt https://www.rfc-editor.org/authors/rfc9888.pdf https://www.rfc-editor.org/authors/rfc9888.html https://www.rfc-editor.org/authors/rfc9888.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9888-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9888-rfcdiff.html (comprehensive side by side) https://www.rfc-editor.org/authors/rfc9888-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9888-auth48rfcdiff.html (AUTH48 side by side) Please contact us with any further updates/questions/comments you may have. The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9888. Thank you! Madison Church RFC Production Center > On Nov 18, 2025, at 1:36 PM, Megan Ferguson <[email protected]> > wrote: > > Hi Jon, > > Just a friendly reminder that we await your approval of this document. > > Please see the thread for further information and let us know if you’d like > us to implement any further changes or proceed with the document in its > current form. > > Thank you. > > RFC Editor/mf > >> On Nov 10, 2025, at 10:17 AM, Megan Ferguson >> <[email protected]> wrote: >> >> Hi Jon, >> >> Just a ping that we are awaiting your review/approval of the implementation >> of the updates requested prior to moving this document forward in the >> publication process. >> >> Please see the message below for further info. >> >> Thank you. >> >> Megan Ferguson >> RFC Production Center >> >>> On Oct 23, 2025, at 1:55 PM, Megan Ferguson >>> <[email protected]> wrote: >>> >>> Hi Jon, >>> >>> Thank you for your reply. We have updated according to your preferences. >>> >>> Please review the files carefully as we do not make changes after >>> publication. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9888.txt >>> https://www.rfc-editor.org/authors/rfc9888.pdf >>> https://www.rfc-editor.org/authors/rfc9888.html >>> https://www.rfc-editor.org/authors/rfc9888.xml >>> >>> The relevant diff files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9888-diff.html (comprehensive diff) >>> https://www.rfc-editor.org/authors/rfc9888-rfcdiff.html (comprehensive side >>> by side) >>> https://www.rfc-editor.org/authors/rfc9888-auth48diff.html (AUTH48 changes >>> only) >>> https://www.rfc-editor.org/authors/rfc9888-auth48rfcdiff.html (AUTH48 side >>> by side) >>> >>> Please contact us with any further updates/questions/comments you may have. >>> >>> >>> We will await approvals from each of the parties listed on the AUTH48 >>> status page prior to moving forward to publication. >>> >>> The AUTH48 status page for this document is available here: >>> >>> https://www.rfc-editor.org/auth48/rfc9888 >>> >>> Thank you. >>> >>> Megan Ferguson >>> RFC Production Center >>> >>> >>>> On Oct 22, 2025, at 1:04 PM, Peterson, Jon >>>> <[email protected]> wrote: >>>> >>>> 1) <!-- [rfced] We had the following questions/comments about the 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: Out-of-Band STIR for Service >>>> Providers Current: Out-of-Band Secure Telephone Identity Revisited (STIR) >>>> for Service Providers b) Should "Framework" or something be added after >>>> (STIR) (once expanded, it doesn't seem like a noun anymore...). >>>> >>>> JFP: I don’t think “Framework” is necessary in the title. >>>> >>>> See also our change to the first sentence of the Introduction. Perhaps: >>>> Out-of-Band Secure Telephone Identity Revisited (STIR) Framework for >>>> Service Providers >>>> >>>> JFP: The first sentence of the intro is talking about STIR in general, not >>>> this out-of-band framework. So, it is okay as it reads in your initial >>>> change, >>>> >>>> --> 2) <!--[rfced] We had a few questions about the following sentence: >>>> Original: Moreover, any additional information included in a PASSporT >>>> which is not strictly redundant with the contents of a SIP request >>>> increases data collection concerns; while baseline [RFC8225] PASSporTs >>>> only contain information otherwise in the SIP request. a) Please help us >>>> clarify the subject of "which". Is it "information" or is it "PASSporT”? >>>> >>>> JFP: It is “information”. You can s/which/that >>>> >>>> b) Could the "while" be removed? This seems to be further information, not >>>> contrasting information? >>>> >>>> JFP: Really the semicolon before the “while” should be a comma. This is >>>> contrasting information: the baseline PASSporT only contains information >>>> that is strictly redundant with the contents of a SIP request. >>>> >>>> c) Please clarify "only contain information otherwise in the SIP request". >>>> Does this mean only redundant information? Perhaps: Moreover, in a >>>> PASSporT, any additional information that is not strictly redundant with >>>> the contents of a SIP request increases data collection concerns; >>>> baseline [RFC8225] PASSporTs only contain information redundant with the >>>> SIP request. >>>> >>>> JFP: I think converting the semicolon to a comma, and perhaps >>>> s/which/that, would be sufficient to clarify, but this proposed wording is >>>> also OK. >>>> >>>> --> 3) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>> online Style Guide 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 "tradition" should be updated for clarity. While the NIST >>>> website <> indicates that this term is potentially biased, it is also >>>> ambiguous. "Tradition" is a subjective term, as it is not the same for >>>> everyone. Original: ..may send SIP INVITEs to a gateway in front of a >>>> traditional PSTN… >>>> >>>> JFP: The usage of “traditional” here is OK I think. >>>> >>>> --> 4) <!-- [rfced] We had the following questions/comments about >>>> abbreviation use throughout the document: a) FYI - We have added >>>> expansions for abbreviations upon first use per Section 3.6 of RFC 7322 >>>> ("RFC Style Guide"). Please review each expansion in the document >>>> carefully to ensure correctness. b) FYI - We will update to use the >>>> abbreviation only after the first use for the following abbreviations in >>>> accordance with the online Style Guide: OOB-AS SPC >>>> >>>> JFP: OK >>>> >>>> --> 5) <!--[rfced] Please review the use of citation tags throughout the >>>> document: some are read as part of the sentence while others are not >>>> syntactically relevant. Please see the online Style Guide for further >>>> information/guidance. >>>> >>>> JFP: I think it’s OK. >>>> >>>> --> 6) <!--[rfced] We see the following similar terminology used >>>> throughout the document. Please let us know if/how we may make these >>>> consistent. STIR credential vs. STIR certificate vs. STIR [RFC8816] >>>> certificate out-of-band STIR vs. STIR out-of-band vs. STIR out-of-band >>>> framework [RFC8816] >>>> >>>> JFP: I’ve reviewed these instances and I think the usage in the doc is OK. >>>> >>>> Thanks! >>>> >>>> --> Thank you. Megan Ferguson RFC Production Center >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
