Re: [auth48] [AD] AUTH48: RFC-to-be 9475 <draft-ietf-stir-messaging-08> for your review
"Murray S. Kucherawy" <superuser@gmail.com> Fri, 17 November 2023 15:12 UTC
Return-Path: <superuser@gmail.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BC8C151094; Fri, 17 Nov 2023 07:12:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCte8KYhddXc; Fri, 17 Nov 2023 07:12:02 -0800 (PST)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A28C151068; Fri, 17 Nov 2023 07:12:01 -0800 (PST)
Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-509469f552aso535569e87.0; Fri, 17 Nov 2023 07:12:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700233920; x=1700838720; darn=rfc-editor.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4YvzqtcF/MZiY+mXn+swMCDrsaU8M6eS24KCtAHcnBA=; b=mB2RvyMUoAjCkVWwrn9Zrwm3UxVNJC7tHchtRqag6eUB+ujKr2UvJvygRp83kBDiTG 2y9BmZwBAs2mmQZs3DMyHkKcEZTTdq8WltbAdxzhbu3bZgTxJp5jlAwxDsHoucsAvvGE VkdycHwblKTl/SzGsK7TE7VQIwltBeTienZaPasbrql/D5ewJCUshsfkTFm9yZsB/t90 N3qNQk90OlgZLzjxqAhdcqfOz8j91Ir590g2yKFGH0afcMbMzbpZP/6lQ367xhr29iMd q4bhuam73qbUZhRmiRsgcK9gPRPN+Qh6Db0523pF8u6e4jCr5OJC1jwLucVNqXi5Pw9Y Q2eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700233920; x=1700838720; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4YvzqtcF/MZiY+mXn+swMCDrsaU8M6eS24KCtAHcnBA=; b=OYcPKvzw+Yoxbma4D9PldVQLC+D4lGSHPPcizxXffnb6H9f/0XIQbmVnKBQ+SeWwoQ TngmbeqY/fjD0Dqc9xywt+lpSYYSKhj1I6IyC3Dt14u7k1PQauiZCzyTe7kdo2BmAKfE dXP326y0YDEEHFxULI6ZeBuy5Bz+RLYoL/YHehIrj4EsIonHrialimKo+9HOA5VXWEsd 0r5LPCCk7j815HfmkDpEKVdqiX4f/UbH6cVO0SpOWastjNg2cU2+iJR8LNuu/QS6jjJ7 Za8HAtzEWXxSbgZwX0ktE7FhHpOpYBDmzyzD2VtY8WBEJprzbK+3YCgBqP8XnM2G+eR6 8udg==
X-Gm-Message-State: AOJu0YyjcJdsxc/ITpgp5F8J6e0fcvPNlANYqmz1H4+hFBYGlxDWqIIx x7T6FpIyEKr7fwa1VWbN3XW5K31JdsNjefyH/pY=
X-Google-Smtp-Source: AGHT+IGnKeM8dlP3WLYCij4d1wtwGLDw/ShpDhNRT94K23KMoN4mP29W0Y6p84nBbunTEA4yMLMjBmDUlCk1YS+7Mm4=
X-Received: by 2002:a05:6512:3ca8:b0:508:1a9d:d768 with SMTP id h40-20020a0565123ca800b005081a9dd768mr8427145lfv.4.1700233919151; Fri, 17 Nov 2023 07:11:59 -0800 (PST)
MIME-Version: 1.0
References: <20230908220539.01450631CA3@rfcpa.amsl.com> <C7170A35-B3DB-4E08-B2DE-E532335B3FF1@amsl.com> <CO6PR17MB4978C738B2E68B613628A2E7FDD3A@CO6PR17MB4978.namprd17.prod.outlook.com> <57B13A1B-BC9C-472E-A0FC-BEF8062E30DC@amsl.com>
In-Reply-To: <57B13A1B-BC9C-472E-A0FC-BEF8062E30DC@amsl.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Fri, 17 Nov 2023 07:11:46 -0800
Message-ID: <CAL0qLwYvToNNDVJEK-xJv8KBUp0rq56ZcMughcgviEcuMD6xGA@mail.gmail.com>
To: Megan Ferguson <mferguson@amsl.com>
Cc: "Peterson, Jon" <Jon.Peterson@transunion.com>, "jon.peterson@team.neustar" <jon.peterson@team.neustar>, "chris-ietf@chriswendt.net" <chris-ietf@chriswendt.net>, "stir-ads@ietf.org" <stir-ads@ietf.org>, "stir-chairs@ietf.org" <stir-chairs@ietf.org>, "ben@nostrum.com" <ben@nostrum.com>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>, RFC Editor <rfc-editor@rfc-editor.org>
Content-Type: multipart/alternative; boundary="000000000000c9447c060a5a8e3a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/-rLbrOFSgqhFvOGQ3jwLoLDZzIg>
Subject: Re: [auth48] [AD] AUTH48: RFC-to-be 9475 <draft-ietf-stir-messaging-08> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Nov 2023 15:12:06 -0000
Hi, Please make it normative. -MSK, ART AD On Mon, Oct 16, 2023 at 4:45 PM Megan Ferguson <mferguson@amsl.com> wrote: > Greetings, > > *AD - please review the following question and provide guidance to the > authors on this point: > > > > --> > > > > > > > > > 10) <!-- [rfced] We have added RFC 4648 as an Informative Reference. > Please let us know if it should be Normative instead. > > > > > > Original: > > > The subsequent characters in the claim value are the base64 encoded > > > [RFC4648] digest of a canonicalized and concatenated string or > binary data > > > based MIME body of the message. --> > > > > > > > Um, I believe that’s okay as Informative, but I might ask our AD if he > agrees. > > > > Jon, > > Thank you for your reply. We have updated accordingly. > > 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/rfc9475.txt > https://www.rfc-editor.org/authors/rfc9475.pdf > https://www.rfc-editor.org/authors/rfc9475.html > https://www.rfc-editor.org/authors/rfc9475.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9475-diff.html (comprehensive > diff) > https://www.rfc-editor.org/authors/rfc9475-auth48diff.html (AUTH48 > changes only) > > 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/rfc9475 > > Thank you. > > RFC Editor/mf > > > On Oct 12, 2023, at 8:34 AM, Peterson, Jon <Jon.Peterson@transunion.com> > wrote: > > > > Sorry for the late reply, some comments inline. > > > > > > > On Sep 8, 2023, at 4:05 PM, rfc-editor@rfc-editor.org wrote: > > > > > > Authors, > > > > > > While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the XML file. > > > > > > 1) <!-- [rfced] 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: > > > Messaging Use Cases and Extensions for STIR > > > > > > Current: > > > Messaging Use Cases and Extensions for Secure Telephone Identity > > > Revisited (STIR) > > > > > > --> > > > > OK > > > > > > > > > > > > > 2) <!--[rfced] We had two questions about the first sentence in the > > > Abstract: > > > > > > a) Should "protocol" or "problem statement" or some other noun follow > > > the expansion of STIR in this text? If we cut "STIR" and just read > > > with the expansion, this sounds a bit odd. > > > > > > b) May we break up this sentence as suggested below for the ease of > > > the reader? > > > > > > Original: > > > Secure Telephone Identity Revisited (STIR) provides a means of > > > attesting the identity of a telephone caller via a signed token in > > > order to prevent impersonation of a calling party number, which is a > > > key enabler for illegal robocalling. > > > > > > Perhaps: > > > The Secure Telephone Identity Revisited (STIR) protocol provides a > > > means of attesting the identity of a telephone caller via a signed > > > token. This prevents impersonation of a calling party number, which > > > is a key enabler for illegal robocalling. > > > > > > > I think the original is better. > > > > > > > > > > --> > > > > > > > > > 3) <!--[rfced] FYI - we have broken up the information in the following > > > sentence to make it easier for the reader to digest. Please let > > > us know if these changes have deviated from your intended > > > meaning. > > > > > > Original: > > > For the first case, where SIP negotiates a session where the media > > > will be text messages or MIME content, as, for example, with the > > > Message Session Relay Protocol (MSRP) [RFC4975], the usage of STIR > > > would deviate little from [RFC8224]. > > > > > > Current: > > > In the first case described in Section 3, SIP negotiates a > > > session in which the media will be text messages or MIME content, as, > > > for example, with the Message Session Relay Protocol (MSRP) > > > [RFC4975]. This usage of STIR would deviate little from [RFC8224]. > > > --> > > > > > > > I would eliminate “described in Section 3” since this is the first > sentence of Section 3.1 – we know where we are. “In the first case, Sip > negotiates a session” etc. Otherwise current is fine. > > > > > > > > > > 4) <!--[rfced] Can the timestamp itself order things? Or can the > > > timestamp be used to order things? > > > > > > Original: > > > ...duplicate messages are easily detected, > > > and the timestamp can order messages displayed to the user inbox in a > > > way that precludes showing stale messages as fresh. > > > > > > Perhaps: > > > ...duplicate messages are easily detected, and the timestamp can be > > > used to order messages displayed in the user inbox in a way that > > > precludes showing stale messages as fresh. > > > --> > > > > > > > Your perhaps option looks good. > > > > > > > > > > 5) <!--[rfced] FYI - We have updated the expansion of MMS as follows to > > > match more common use in recent RFCs. Please let us know any > > > objections: > > > > > > Original: > > > multimedia message system (MMS) > > > > > > Current: > > > Multimedia Messaging Service (MMS) > > > --> > > > > OK > > > > > > > > > > > > > 6) <!--[rfced] How may we update this text for clarity? We do not see > > > "profiles" in RFC 8226. (Note that we have made the change from > > > "profiles defines" to "profiles define" pending more > > > information). > > > > > > Original: > > > The [RFC8226] STIR certificate profiles defines... > > > > > > Perhaps: > > > "Secure Telephone Identity Credentials: Certificates" [RFC8226] > defines... > > > > > > Or perhaps: > > > The STIR certificate profiles defined in [RFC8226]... > > > --> > > > > > > > I think “profiles” and “defines” in the original were just a redundant > typo. Your “Perhaps” is correct: “[RFC8226] defines”. > > > > > > > > > > 7) <!--[rfced] This sentence describes a lot of things being > "contain"ed. > > > Might a rephrase benefit the reader? If so, please let us know > > > how we may update. > > > > > > Original: > > > As the "orig" and "dest" field of PASSporTs may contain URIs > > > containing SIP URIs without telephone numbers, the STIR for messaging > > > mechanism contained in this specification is not inherently > > > restricted to the use of telephone numbers. > > > > > > > > > > Yeah that’s pretty bad. How about: > > > > As the “orig” and “dest” field of PASSporTs may contain SIP URIs without > telephone numbers, the STIR for… > > > > > > > > > > --> > > > > > > > > > 8) <!--[rfced] May we update the following to avoid awkward > hyphenation? > > > > > > Original: > > > This specification offers no guidance on certification authorities who > > > are appropriate to sign for non-telephone number "orig" values. > > > > > > Perhaps: > > > This specification offers no guidance on certification authorities who > > > are appropriate to sign for "orig" values that are not for use with > > > telephone numbers. > > > > > > > How about: This specification offers no guidance on appropriate > certification authorities for desigining “orig” values that do not contain > telephone numbers. > > > > > > > --> > > > > > > > > > 9) <!--[rfced] Please note the following about the IANA Considerations > > > and IANA-related text in the document: > > > > > > a) Please note that we have changed IESG to be IETF for the Change > > > Controller of the "msgi" registration at > > > > https://urldefense.com/v3/__https://www.iana.org/assignments/jwt/jwt.xhtml__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97iEEp1K0A$ > . This is in accordance > > > with the following note we received from IANA: > > > > > > "Note: in accordance with recent practice, the change controller for > > > this registration has been changed from the IESG to the IETF." > > > > OK > > > > > > > > > > b) We have cut the URL to the registry mentioned in Section 6.2 to > > > match Section 6.1. Please let us know any objections. > > > > OK > > > > > > > > > > c) We have removed the quote marks as they do not appear in the > > > corresponding registries. > > > > OK > > > > > > > > > > --> > > > > > > > > > 10) <!-- [rfced] We have added RFC 4648 as an Informative Reference. > Please let us know if it should be Normative instead. > > > > > > Original: > > > The subsequent characters in the claim value are the base64 encoded > > > [RFC4648] digest of a canonicalized and concatenated string or > binary data > > > based MIME body of the message. --> > > > > > > > Um, I believe that’s okay as Informative, but I might ask our AD if he > agrees. > > > > > > > > > > 11) <!--[rfced] We had the following questions related to terminology > use > > > throughout the document: > > > > > > a) We note the use of the following similar terms: > > > > > > SIP Identity header > > > Identity header > > > Identity > > > identity > > > > > > Please review these instances and let us know if any updates are > > > necessary for clarity (e.g., should all "Identity header"s be called > > > "SIP Identity header"s). > > > > > > > I mean, I tend to favor being readable over strict on these matters. > Scanning through the doc, I think it’s clear that referring to “Identity” > in these contexts means the SIP Identity header from the remainder of the > sentences in question. > > > > > > > b) We see both: > > > > > > "orig" field > > > "orig" values > > > > > > Should the latter be made "orig" field values? > > > > Where “orig” and “dest” and “iat” are referred to as “fields” (like in > 4) that should more properly be “claims”. Claims have a value, so talking > about the ‘“orig” value’ is fine. But we should say “claims” instead of > “fields” for the few instances where PASSporT elements are referred to as > “fields”: > > > > … the “dest” field of the PASSporT … > > > > … so that the “iat” field can be … > > > > … As the “orig” and “dest” field of… > > > > And also the last sentence in 1: … that specifies new fields for use in > PASSporTs… > > > > Those should be “claim” or “claims.” (No changes to places where > “Identity field” appears, though). > > > > > > > > > > c) We see the following uses of "baseline": > > > > > > i) At a high level, baseline PASSporT [RFC8225] claims provide > similar > > > value to... > > > > > > ii) Current usage of baseline [RFC8224] Identity is largely confined > to > > > INVITE requests that initiate telephone calls. > > > > > > iii) Per baseline [RFC8224], this specifications leaves it to local > policy > > > to determine how messages are handled after verification succeeds or > > > fails. > > > > “Baseline” is being used in all three of cases in its naïve sense, to > mean just “as the specification is written.” I would just eliminate the > word in all three cases, it isn’t adding much value. > > > > > > > > > > For i), we see the use of "baseline claims" in RFC 8225, so we would > > > simply suggest moving the citation tag as follows: > > > > > > Perhaps: > > > At a high level, baseline PASSporT claims (see [RFC8225]) provide > similar > > > value to... > > > > > > For ii), we note that "baseline Identity" is not mentioned in RFC > > > 8224. Please review this text and let us know how to update. > > > > > > For iii), we see RFC 8225 referred to as "the baseline PASSporT > > > specification" in RFC 8224. Please review this text and let us know > > > how to update. > > > > > > Perhaps: > > > Per the guidance in the baseline PASSporT specification [RFC8225], > this > > > specification leaves it to local policy to determine how messages > > > are handled after verification succeeds or fails. > > > > > > d) We see both PASSporT Type and PASSporT type. We updated to use the > > > lowercase "type" throughout. Please let us know any objections. > > > > OK > > > > > > > > > > --> > > > > > > > > > 12) <!-- [rfced] Please review the "Inclusive Language" portion of the > > > online Style Guide > > > < > https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97ip7soJ18$ > > > > > and let us know if any changes are needed. > > > > > > For example, please consider whether the following should be updated: > > > > > > > > > ...authorized to use the calling party number (or, for native SIP > cases,... > > > > I would delete “native”, yes. > > > > > > > > > > > > > In addition, please consider whether "tradition" should be updated for > > > clarity. While the NIST website > > > < > https://urldefense.com/v3/__https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions*table1__;Iw!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97iC0E6QT4$ > > > > > indicates that this term is potentially biased, it is also ambiguous. > > > "Tradition" is a subjective term, as it is not the same for everyone. > > > > > > > > > ...value to number-based messaging as they do to traditional > > > telephone... > > > > > > ...treatment that differs from traditional delivery expectations of > > > SIP... > > > > > > ...the traditional telephone network and those based on > > > over-the-top... > > > --> > > > > I might just remove “traditional” in all three cases. > > > > Thanks, > > > > - J > > > > > > > > > > > > > Thank you. > > > > > > RFC Editor/kf/mf > > > > > > *****IMPORTANT***** > > > > > > Updated 2023/09/08 > > > > > > 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97i6VbbRHo$ > ). > > > > > > 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://urldefense.com/v3/__https://trustee.ietf.org/license-info/__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97ivv60mCc$ > ). > > > > > > * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97i3kdQ3dg$ > >. > > > > > > * 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 > > > > > > * rfc-editor@rfc-editor.org (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). > > > > > > * auth48archive@rfc-editor.org, which is a new archival mailing > list > > > to preserve AUTH48 conversations; it is not an active discussion > > > list: > > > > > > * More info: > > > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97iYlnOK50$ > > > > > > * The archive itself: > > > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97i78oCEgc$ > > > > > > * 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, > > > auth48archive@rfc-editor.org 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9475.xml__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97iEylmKUA$ > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9475.html__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97iWg_ouFg$ > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9475.pdf__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97iTy29TMw$ > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9475.txt__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97ilLQIE8A$ > > > > > > Diff file of the text: > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9475-diff.html__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97it_L51nM$ > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9475-rfcdiff.html__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97i-zUhmzc$ > (side by side) > > > > > > Diff of the XML: > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9475-xmldiff1.html__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97i9m1ultE$ > > > > > > The following files are provided to facilitate creation of your own > > > diff files of the XML. > > > > > > Initial XMLv3 created using XMLv2 as input: > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9475.original.v2v3.xml__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97iZpfo5Z8$ > > > > > > > XMLv3 file that is a best effort to capture v3-related format updates > > > only: > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9475.form.xml__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97igEa1vTg$ > > > > > > > > > Tracking progress > > > ----------------- > > > > > > The details of the AUTH48 status of your document are here: > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9475__;!!N14HnBHF!-Go8giMg3oYK7EPYfukRw6EkY7aHj0rvYHbmI9FCnanwAGz_gT_tRpk8nMNJ7HikD5JH3xv-VATz_97izp6fZsY$ > > > > > > Please let us know if you have any questions. > > > > > > Thank you for your cooperation, > > > > > > RFC Editor > > > > > > -------------------------------------- > > > RFC9475 (draft-ietf-stir-messaging-08) > > > > > > Title : Messaging Use Cases and Extensions for STIR > > > Author(s) : J. Peterson, C. Wendt > > > WG Chair(s) : Ben Campbell, Robert Sparks, Russ Housley > > > Area Director(s) : Murray Kucherawy, Francesca Palombini > > > > > > > > > >
- [auth48] AUTH48: RFC-to-be 9475 <draft-ietf-stir-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9475 <draft-ietf-s… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9475 <draft-ietf-s… Megan Ferguson
- Re: [auth48] AUTH48: RFC-to-be 9475 <draft-ietf-s… Megan Ferguson
- Re: [auth48] AUTH48: RFC-to-be 9475 <draft-ietf-s… Megan Ferguson
- Re: [auth48] AUTH48: RFC-to-be 9475 <draft-ietf-s… Peterson, Jon
- Re: [auth48] [AD] AUTH48: RFC-to-be 9475 <draft-i… Megan Ferguson
- Re: [auth48] [AD] AUTH48: RFC-to-be 9475 <draft-i… Megan Ferguson
- Re: [auth48] [AD] AUTH48: RFC-to-be 9475 <draft-i… Megan Ferguson
- Re: [auth48] [AD] AUTH48: RFC-to-be 9475 <draft-i… Ben Campbell
- Re: [auth48] [AD] AUTH48: RFC-to-be 9475 <draft-i… Megan Ferguson
- Re: [auth48] [AD] AUTH48: RFC-to-be 9475 <draft-i… Peterson, Jon
- Re: [auth48] [AD] AUTH48: RFC-to-be 9475 <draft-i… Murray S. Kucherawy
- Re: [auth48] [AD] AUTH48: RFC-to-be 9475 <draft-i… Ben Campbell
- Re: [auth48] [AD] AUTH48: RFC-to-be 9475 <draft-i… Peterson, Jon
- Re: [auth48] AUTH48: RFC-to-be 9475 <draft-ietf-s… Megan Ferguson
- Re: [auth48] AUTH48: RFC-to-be 9475 <draft-ietf-s… Megan Ferguson
- Re: [auth48] AUTH48: RFC-to-be 9475 <draft-ietf-s… Ben Campbell
- Re: [auth48] AUTH48: RFC-to-be 9475 <draft-ietf-s… Chris Wendt
- Re: [auth48] AUTH48: RFC-to-be 9475 <draft-ietf-s… Megan Ferguson
- Re: [auth48] AUTH48: RFC-to-be 9475 <draft-ietf-s… Peterson, Jon
- Re: [auth48] AUTH48: RFC-to-be 9475 <draft-ietf-s… Megan Ferguson