Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-iab-path-signals-collaboration-03> for your review
Ted Hardie <ted.ietf@gmail.com> Tue, 27 June 2023 11:53 UTC
Return-Path: <ted.ietf@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 27557C13AE33; Tue, 27 Jun 2023 04:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 6lm4562J18jF; Tue, 27 Jun 2023 04:53:45 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 06B36C16B5B5; Tue, 27 Jun 2023 04:53:40 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-51d9890f368so2570987a12.2; Tue, 27 Jun 2023 04:53:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687866818; x=1690458818; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8fmccIc69HVFN4W0lrM3Gwf5sRJPSaXrAIGlm9wg1l4=; b=Qb7/b8PReeiWei766NJ9Eb7chIh0AJVa27FYvEZXwntcmmFsPW0gmAWovPjk6hisZE X4vtknGNVxhdAG3c+XQeHjEAN+N2WKC2VnNiAcpSUS1N9M/hGos4zXvLJqq2LT7Bpivj P08QMjjpKHvruBlZXRbMI6H3PtBT7s9/qvs8PehMCxkyEW0DObeoJGvZNMGsx7ElHI7H p6J89K8g6XfGTRvIbxtthOAWqXmryNntgVjxnnVGZNGlqp9DsnJUXmSu7I7uy4FyXQJI UV1MBe/ZW927iBdAM3floFJ7w50jbWA4KHSzQfEPGW2XSvyZm/UOp3K0nhFj5jkB3DUu UKtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687866818; x=1690458818; 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=8fmccIc69HVFN4W0lrM3Gwf5sRJPSaXrAIGlm9wg1l4=; b=cwzFTnOFs047UeohJWnsTR89+n8hECGAFjk5sU5am5V3VZP6cyHyucwhpDcCXWIrlW Jf3gCQpI2u+ErRBGD3Fc2nbHMVTArKC0PIjf0LbG9sngFdIhXC1uAXK0DzLUkfx9rEmD NiNilBUIqPMC9WDXfHn5taTeC/0K6isKl3+frRTwVfsiSKY/ZZKOIJYFEv3LdYTlcwX6 OtHYdFfWzdT3il5T6KGl7Doha6qnsnKJLJJQVbYRNWjrrRxEixzJRWRp1PsMmdd4yYyX IG7rkX53kBJjqMaEq1blvarN0YHR/JmfSEWpixgjv4k5G5w2UGtBEl1pzNNt0BKGWZxG SI6g==
X-Gm-Message-State: AC+VfDx4+NQwEprigSq6k7+5rLNRldPPapdR+qA62kkKKfthTa7QntcK tB59n2tMuIHQWAhIQ6qXIOrB3CLhMwGhya4zdxERE1de
X-Google-Smtp-Source: ACHHUZ5gvFyRxnVqR2C6dVhzeHIlwWhQDZObCT2LjjyuROUtlvmVqMuUDD8h5GAUDZ5izlS4Ju6D0mFksHhh/RzODuE=
X-Received: by 2002:a50:ed8d:0:b0:51d:9ddf:f0f6 with SMTP id h13-20020a50ed8d000000b0051d9ddff0f6mr3357878edr.36.1687866817877; Tue, 27 Jun 2023 04:53:37 -0700 (PDT)
MIME-Version: 1.0
References: <6BAFE486-BA00-481E-A038-88D51C6FB172@amsl.com> <C62836E8-A31D-4115-9ADB-6DD7B13430E3@apple.com> <33F20266-91AA-4BD2-9EC3-DCCF2067ED97@ericsson.com> <1F3C0782-5F47-4B3A-A41B-B2DF9DD5206E@amsl.com> <7606443F-7C0F-4508-AA4B-2703E72CF109@ericsson.com>
In-Reply-To: <7606443F-7C0F-4508-AA4B-2703E72CF109@ericsson.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 27 Jun 2023 12:53:11 +0100
Message-ID: <CA+9kkMByYMDyC2CSFEQj586MtuxQpMqoHwB9O5VmdyxSKqVTeA@mail.gmail.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: Karen Moore <kmoore@amsl.com>, Jari Arkko <jari.arkko@ericsson.com>, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>, IAB <iab@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001b9ece05ff1b1e8e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/TU21Uo-xpbgZpTlpTOr-4MlTHVY>
Subject: Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-iab-path-signals-collaboration-03> 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: Tue, 27 Jun 2023 11:53:50 -0000
On Tue, Jun 27, 2023 at 10:52 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote: > Hi Karen, > > regarding the title, based on the discussion below, it seems that both > Tommy and I would prefer the original title (maybe with removing the spaces > before and after the "-"). So I don’t think we fully agreed to change the > title (to option B). @Ted @Jari and thoughts from your side? > > I don't have a strong opinion here, and I'm happy to go with what you and Tommy prefer. Ted > Mirja > > > > On 26.06.23, 20:48, "Karen Moore" <kmoore@amsl.com> wrote: > > Hi Mirja, > > We have updated “spin bit” to Spin Bit” (1 instance) in the text. > Links to the updated files are below. > > Regarding the title, please see what was discussed below (the title > currently reflects “B”). If the authors would like to make additional > changes, please let us know. > > >> ... > >> 2) For the document title, would it be correct to add “and” (option > A) or to rephrase for clarity (option B) as follows? > >> > >> Perhaps: > >> A) Considerations on Application and Network Collaboration Using > Path Signals > >> or > >> B) Considerations on the Collaboration between Applications and > Networks Using Path Signals > > > > [TP] I consider option (B) to be the more accurate interpretation > here. I would be fine with this version of the title if everyone else > agrees, although I’m also happy with the existing title. Does the RFC > editor consider the existing title to be too confusing? > > > > [RFC Editor] Correct; the meaning is ambiguous due to the hyphen. > > > > Original: > > Considerations on Application - Network Collaboration Using Path > Signals > > > > Updated: > > Considerations on the Collaboration between Applications and > Networks Using Path Signals > > > > However, you might consider: > > Considerations on Using Path Signals for Collaboration between > Applications and Networks > > > FILES (please refresh): > > The updated XML file is here: > https://www.rfc-editor.org/authors/rfc9419.xml > > The updated output files are here: > https://www.rfc-editor.org/authors/rfc9419.txt > https://www.rfc-editor.org/authors/rfc9419.pdf > https://www.rfc-editor.org/authors/rfc9419.html > > This diff file shows all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9419-auth48diff.html > > This diff file shows all changes made to date: > https://www.rfc-editor.org/authors/rfc9419-diff.html > > Please contact us with any further updates or with your approval of > the document in its current form. We will await approvals from Jari, > Mirja, and Ted prior to moving forward in the publication process. > > Best regards, > > RFC Editor/kc > > > > On Jun 26, 2023, at 1:21 AM, Mirja Kuehlewind < > mirja.kuehlewind@ericsson.com> wrote: > > > > Hi all, > > > > I approve the changes from Ted. > > > > I have two more small things: > > > > 1) Did we actually now decide to change the title? If not and we > want to keep the old title, I think the problem is actually with the dash: > may it should be “Application-Network Collaboration” instead of > "Application - Network Collaboration”? > > > > 2) The Spin Bit is actually a name in RFC9000 and should be written > with upper case letters. However both the S and B should be upper laters > which was wrong in the initial text (“bit” was lower case). > > > > Mirja > > > > > > > >> On 21. Jun 2023, at 20:21, Tommy Pauly <tpauly= > 40apple.com@dmarc.ietf.org> wrote: > >> > >> Hi Karen, > >> > >> This version looks good to me. Please put me down as approving this! > >> > >> Best, > >> Tommy > >> > >>> On Jun 21, 2023, at 10:55 AM, Karen Moore <kmoore@amsl.com> wrote: > >>> > >>> Hello authors, > >>> > >>> Please review Ted’s rewrite of bullet points 4, 5, and 6 in > Section 3 (to make them complete sentences) and let us know if the wording > is agreeable or if further changes are needed (note that we rephrased the > first sentence of point 4 slightly for clarity). For ease, the update is > below. To view a diff of only this change, see > https://www.rfc-editor.org/authors/rfc9419-lastdiff.html or > https://www.rfc-editor.org/authors/rfc9419-lastrfcdiff.html > (side-by-side). > >>> > >>> Section 3 > >>> Old: > >>> * Ways of protecting information when held by network elements or > >>> servers, beyond communications security. For instance, host > >>> applications commonly share sensitive information about the > user's > >>> actions with other parties, starting from basic data, such as > >>> domain names learned by DNS infrastructure or source and > >>> destination addresses and protocol header information learned by > >>> all routers on the path, to detailed end-user identity and other > >>> information learned by the servers. Some solutions are starting > >>> to exist for this but are not widely deployed, at least not > today > >>> [Oblivious] [PDoT] [DNS-CONFIDENTIAL] [HTTP-OBLIVIOUS]. These > >>> solutions address also very specific parts of the issue, and > more > >>> work remains. > >>> > >>> * Sharing information from networks to applications. There are > some > >>> working examples of this, e.g., ECN. A few other proposals have > >>> been made (see, e.g., [MOBILE-THROUGHPUT-GUIDANCE]), but very > few > >>> of those have seen deployment. > >>> > >>> * Sharing information from applications to networks. There are a > >>> few working examples of this (see Section 1). Numerous > proposals > >>> have been made in this space, but most of them have not > progressed > >>> through standards or been deployed for a variety of reasons > >>> [RFC9049]. However, several current or recent proposals exist, > >>> such as [NETWORK-TOKENS]. > >>> > >>> New: > >>> * Work has begun on mechanisms that dissociate the information > held > >>> by servers from knowledge of the user's network location and > >>> behavior. Among the solutions that exist for this but are not > >>> widely deployed are [Oblivious] [PDoT] [DNS-CONFIDENTIAL] > >>> [HTTP-OBLIVIOUS]. These solutions address specific parts of the > >>> issue, and more work remains to find ways to limit the spread of > >>> information about the user's actions. Host applications > currently > >>> share sensitive information about the user's action with a > variety > >>> of infrastructure and path elements, starting from basic data, > >>> such as domain names, source and destination addresses, and > >>> protocol header information. This can expand to detailed > end-user > >>> identity and other information learned by the servers. Work to > >>> protect all of this information is needed. > >>> > >>> * Work is needed to explore how to increase the deployment of > >>> mechanisms for sharing information from networks to > applications. > >>> There are some working examples of this, e.g., ECN. A few other > >>> proposals have been made (see, e.g., > >>> [MOBILE-THROUGHPUT-GUIDANCE]), but very few of those have seen > >>> deployment. > >>> > >>> * Additional work on sharing information from applications to > >>> networks would also be valuable. There are a few working > examples > >>> of this (see Section 1). Numerous proposals have been made in > >>> this space, but most of them have not progressed through > standards > >>> or been deployed for a variety of reasons [RFC9049]. However, > >>> several current or recent proposals exist, such as > >>> [NETWORK-TOKENS]. > >>> > >>> FILES (please refresh): > >>> > >>> The updated XML file is here: > >>> https://www.rfc-editor.org/authors/rfc9419.xml > >>> > >>> The updated output files are here: > >>> https://www.rfc-editor.org/authors/rfc9419.txt > >>> https://www.rfc-editor.org/authors/rfc9419.pdf > >>> https://www.rfc-editor.org/authors/rfc9419.html > >>> > >>> These diff files show only the changes made during the last edit > round: > >>> https://www.rfc-editor.org/authors/rfc9419-lastdiff.html > >>> https://www.rfc-editor.org/authors/rfc9419-lastrfcdiff.html > (side-by-side) > >>> > >>> This diff file shows all changes made during AUTH48: > >>> https://www.rfc-editor.org/authors/rfc9419-auth48diff.html > >>> > >>> This diff file shows all changes made to date: > >>> https://www.rfc-editor.org/authors/rfc9419-diff.html > >>> > >>> Please contact us with any further updates or with your approval > of the document in its current form. We will await approvals from each > author prior to moving forward in the publication process. > >>> > >>> Thank you, > >>> > >>> RFC Editor/kc > >>> > >>> > >>>> On Jun 14, 2023, at 1:42 AM, Ted Hardie <ted.ietf@gmail.com> > wrote: > >>>> > >>>> Some suggested changes for the fragmented introductions to > Section 3's items 4,5, and 6: > >>>> > >>>> Work has begun on mechanisms on dissociating the information held > by servers from knowledge of the user's network location and behavior. > Among the solutions which exist for this but are not widely deployed are > [Oblivious] [PDoT] [DNS-CONFIDENTIAL] [HTTP-OBLIVIOUS]. These solutions > address specific parts of the issue, and more work remains to find ways to > limit the spread of information about the user's actions. Host > applications currently share sensitive information about the user's action > with a variety of infrastructure and path elements, starting from basic > data, such as domain names, source and destination addresses, and protocol > header information. This can exland to detailed end-user identity and > other information learned by the servers. Work to protect all of this > information is needed. > >>>> > >>>> Work is needed to explore how to increase the deployment of > mechanisms for sharing information from networks to applications. There are > some working examples of this, e.g., ECN. A few other proposals have been > made (see, e.g., [MOBILE-THROUGHPUT-GUIDANCE]), but very few of those have > seen deployment. > >>>> > >>>> Additional work on sharing information from applications to > networks would also be valuable. There are a few working examples of this > (see Section 1). Numerous proposals have been made in this space, but most > of them have not progressed through standards or been deployed for a > variety of reasons [RFC9049]. However, several current or recent proposals > exist, such as [NETWORK-TOKENS]. > >>>> > >>>> > >>>> The rewrite for 4 (the first one above) is pretty major, so the > other authors should be sure it reflects what they want. > >>>> > >>>> regards, > >>>> > >>>> Ted > >>>> > >>>>> On Mon, Jun 12, 2023 at 10:04 PM Alice Russo <arusso@amsl.com> > wrote: > >>>>> Mirja, Tommy, > >>>>> > >>>>> Thank you for your replies. The updated files are here (please > refresh): > >>>>> https://www.rfc-editor.org/authors/rfc9419.txt > >>>>> https://www.rfc-editor.org/authors/rfc9419.pdf > >>>>> https://www.rfc-editor.org/authors/rfc9419.html > >>>>> https://www.rfc-editor.org/authors/rfc9419.xml (source) > >>>>> > >>>>> Diff showing all changes from the approved I-D: > >>>>> https://www.rfc-editor.org/authors/rfc9419-rfcdiff.html > >>>>> > >>>>> Diff showing only the most recent changes (for items 2 and 4 > below): > >>>>> https://www.rfc-editor.org/authors/rfc9419-lastrfcdiff.html > >>>>> > >>>>> To summarize: > >>>>> > >>>>> 1) no change re: 'evolvability'. > >>>>> > >>>>> 2) Each of you prefer the current title, but are OK with Option > B. > >>>>> We have updated the title to Option B (with 's' added to > 'Application'). > >>>>> > >>>>> Tommy wrote: > >>>>> Does the RFC editor consider the existing title to be too > confusing? > >>>> > >>>> > >>>> Correct; the meaning is ambiguous due to the hyphen. > >>>> > >>>> Original: > >>>> Considerations on Application - Network Collaboration Using Path > Signals > >>>> > >>>> Updated: > >>>> Considerations on the Collaboration between Applications and > Networks Using Path Signals > >>>> > >>>> However, you might consider: > >>>> Considerations on Using Path Signals for Collaboration between > Applications and Networks > >>>> > >>>> > >>>> 3) awaiting reply re: rephrase in Section 2.1. > >>>> > >>>> 4) Tommy wrote: > >>>>> Is this list correct? The document was approved in our 12/07/22 > meeting: > https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-eb0318a38933d8d7&q=1&e=cc45abf9-d14e-4cfa-b2a0-031a6b9c7a4e&u=https%3A%2F%2Fwww.iab.org%2Fdocuments%2Fminutes%2Fminutes-2022%2Fiab-minutes-2022-12-07%2F > >>>>> > >>>>> At that time, it was the previous IAB that approved the document. > >>>> > >>>> > >>>> Thank you for pointing this out. We have updated the list of "IAB > Members at the Time of Approval” to match the IAB members in the minutes > from 7 Dec 2022. Please review to ensure correctness. > >>>> > >>>> 5) awaiting reply re: complete sentences for the list in Section > 3. > >>>> > >>>> > >>>> The AUTH48 status of this document is here: > >>>> https://www.rfc-editor.org/auth48/rfc9419 > >>>> > >>>> Thank you. > >>>> RFC Editor/ar > >>>> > >>>>>> On Jun 8, 2023, at 9:35 AM, Mirja Kuehlewind <mirja.kuehlewind= > 40ericsson.com@dmarc.ietf.org> wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> regarding the title. I would be okay with option B. I think > option A is not correct. But I also slightly prefer the existing title but > don’t have a strong opinion. > >>>>> > >>>>> Mirja > >>>>> > >>>>> > >>>>> > >>>>> From: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> > >>>>> Date: Thursday, 8. June 2023 at 17:51 > >>>>> To: Karen Moore <kmoore@amsl.com>, Ted Hardie < > ted.ietf@gmail.com> > >>>>> Cc: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, Jari > Arkko <jari.arkko@ericsson.com>, RFC Editor <rfc-editor@rfc-editor.org>, " > auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>, IAB < > iab@ietf.org> > >>>>> Subject: Re: [IAB] AUTH48: RFC-to-be 9419 > <draft-iab-path-signals-collaboration-03> for your review > >>>>> > >>>>> Hello, > >>>>> > >>>>> First of all, thanks very much for the edits. They look good in > general, and I agree with everything Mirja and Ted have said! > >>>>> > >>>>> Some responses inline. > >>>>> > >>>>> > >>>>>> On Jun 2, 2023, at 3:31 PM, Karen Moore <kmoore@amsl.com> > wrote: > >>>>>> > >>>>>> Hello Mira and Ted, > >>>>>> > >>>>>> Thank you for the quick replies; we have updated our files > accordingly. Note that we have a few follow-up questions/clarifications. > >>>>>> > >>>>>> 1) Regarding “evolvability”, this term has been used in earlier > RFCs (e.g., RFCs 1077, 2276, 3426, and 6077). Since it is an established > technical term per Mira’s comment, and because Ted included it within a > suggested rephrase, we went ahead and reverted to the original text (only 3 > instances). However, if you prefer to use "ability for protocols to > evolve”, please let us know. > >>>>> > >>>>> Please keep “evolvability” as you have it now. This reads > cleanly, I think. > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>>> [MK] I also noticed in the xml that you replaced > “evolvability” with "ability for protocols to evolve”. I think this is not > wrong but I see evolvability actually as a technical term that has been > established in the mean time. What do the other authors think? > >>>>>> > >>>>>> > >>>>>> ... > >>>>>> 2) For the document title, would it be correct to add “and” > (option A) or to rephrase for clarity (option B) as follows? > >>>>>> > >>>>>> Perhaps: > >>>>>> A) Considerations on Application and Network Collaboration > Using Path Signals > >>>>>> or > >>>>>> B) Considerations on the Collaboration between Application > and Networks Using Path Signals > >>>>> > >>>>> I consider option (B) to be the more accurate interpretation > here. I would be fine with this version of the title if everyone else > agrees, although I’m also happy with the existing title. Does the RFC > editor consider the existing title to be too confusing? > >>>>> > >>>>> > >>>>>> > >>>>>> ... > >>>>>> 3) To make this sentence grammatically correct, may we rephrase > it slightly as follows? > >>>>>> > >>>>>> Original: > >>>>>> The goal is that any information should be provided knowingly, > for a > >>>>>> specific purpose, sent in signals designed for that purpose, > and that > >>>>>> any use of information should be done within that purpose. In > addition... > >>>>>> > >>>>>> Perhaps: > >>>>>> The goal is that any information should be provided knowingly, > for a > >>>>>> specific purpose, and sent in signals designed for that > purpose, and any > >>>>>> use of information should be done within that purpose. In > addition… > >>>>>> > >>>>>> ... > >>>>>> 4) FYI: We have added the "IAB Members at the Time of Approval” > section before the Acknowledgements. > >>>>> > >>>>> Is this list correct? The document was approved in our 12/07/22 > meeting: > https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-eb0318a38933d8d7&q=1&e=cc45abf9-d14e-4cfa-b2a0-031a6b9c7a4e&u=https%3A%2F%2Fwww.iab.org%2Fdocuments%2Fminutes%2Fminutes-2022%2Fiab-minutes-2022-12-07%2F > >>>>> > >>>>> At that time, it was the previous IAB that approved the document. > >>>>> > >>>>>> > >>>>>> ... > >>>>>> 5) FYI: We will await your rephrasing of the bullet points in > Section 3 (to make them complete sentences). > >>>>> > >>>>> Ted, let me know if you’re working on that or if you’d like me > to take a stab instead! > >>>>> > >>>>> Best, > >>>>> Tommy > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> FILES > >>>>>> The updated XML file is here: > >>>>>> https://www.rfc-editor.org/authors/rfc9419.xml > >>>>>> > >>>>>> The updated output files are here: > >>>>>> https://www.rfc-editor.org/authors/rfc9419.txt > >>>>>> https://www.rfc-editor.org/authors/rfc9419.pdf > >>>>>> https://www.rfc-editor.org/authors/rfc9419.html > >>>>>> > >>>>>> This diff file shows all changes made during AUTH48: > >>>>>> https://www.rfc-editor.org/authors/rfc9419-auth48diff.html > >>>>>> > >>>>>> This diff file shows all changes made to date: > >>>>>> https://www.rfc-editor.org/authors/rfc9419-diff.html > >>>>>> > >>>>>> Note that it may be necessary for you to refresh your browser > to view the most recent version. Please review the document carefully to > ensure satisfaction as we do not make changes once it has been published as > an RFC. > >>>>>> > >>>>>> Please contact us with any further updates or with your > approval of the document in its current form. We will await approvals from > each author prior to moving forward in the publication process. > >>>>>> > >>>>>> For the AUTH48 status of this document, please see: > >>>>>> https://www.rfc-editor.org/auth48/rfc9419 > >>>>>> > >>>>>> Thank you, > >>>>>> > >>>>>> RFC Editor/kc > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Jun 2, 2023, at 7:10 AM, Mirja Kuehlewind <mirja.kuehlewind= > 40ericsson.com@dmarc.ietf.org> wrote: > >>>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> My replies inline as well. > >>>>>>> > >>>>>>> I also noticed in the xml that you replaced “evolvability” > with "ability for protocols to evolve”. I think this is not wrong but I see > evolvability actually as a technical term that has been established in the > mean time. What do the other authors think? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On 2. Jun 2023, at 11:29, Ted Hardie <ted.ietf@gmail.com> > wrote: > >>>>>>>> > >>>>>>>> Some personal answers to the questions in-line. > >>>>>>>> > >>>>>>>> On Thu, Jun 1, 2023 at 7:53 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] Would it be correct to rephrase the document > title as > >>>>>>>> follows for clarity (i.e., "Application Considerations for" > >>>>>>>> instead of "Considerations on Application -")? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Considerations on Application - Network Collaboration > >>>>>>>> Using Path Signals > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> Application Considerations for Network Collaboration > >>>>>>>> Using Path Signals > >>>>>>>> --> > >>>>>>>> > >>>>>>>> No, I don't think this change is correct; both the network > and applications have this to consider here so it isn't just "application > considerations". > >>>>>>> > >>>>>>> This change would not be correct. It’s about the collaboration > between application and networks. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that > appear in the title) for use on https://www.rfc-editor.org/search. > >>>>>>>> --> > >>>>>>> > >>>>>>> I can’t really come up with any additional keys. I think the > titles covers everything well. > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 3) <!--[rfced] Informative reference RFC 793 has been > obsoleted by RFC 9293. > >>>>>>>> Per Section 4.8.6 in the RFC Style Guide (RFC 7322), we > recommend > >>>>>>>> replacing RFC 793 with RFC 9293. May we update the reference? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> For instance, on-path elements use various fields of the > >>>>>>>> TCP header [RFC0793] to derive information about > >>>>>>>> end-to-end latency as well as congestion. > >>>>>>>> > >>>>>>>> Suggested: > >>>>>>>> For instance, on-path elements use various fields of the > >>>>>>>> TCP header [RFC9293] to derive information about > >>>>>>>> end-to-end latency as well as congestion. > >>>>>>>> --> > >>>>>>>> > >>>>>>>> > >>>>>>>> I am okay with this change. > >>>>>>> > >>>>>>> Yes, thanks! > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> 4) <!-- [rfced] FYI, to make the two categories easier to > read, we > >>>>>>>> formatted this text as a list. Please let us know of any > >>>>>>>> objections. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Many protocol mechanisms throughout the stack fall into one > of two > >>>>>>>> categories: authenticated and private communication that is > only > >>>>>>>> visible to a very limited set of parties, often one on each > "end"; > >>>>>>>> and unauthenticated public communication that is also visible > to all > >>>>>>>> network elements on a path. > >>>>>>>> > >>>>>>>> Current: > >>>>>>>> Many protocol mechanisms throughout the stack fall into one > of two > >>>>>>>> categories: > >>>>>>>> > >>>>>>>> * authenticated private communication that is only visible > to a > >>>>>>>> very limited set of parties, often one on each "end", and > >>>>>>>> > >>>>>>>> * unauthenticated public communication that is visible to all > >>>>>>>> network elements on a path. > >>>>>>>> --> > >>>>>>>> > >>>>>>>> > >>>>>>>> I prefer the first, but if the other authors prefer the > second I can agree. The reason I prefer the first is that we were not > trying to create an exhaustive enumeration but were introducing a common > pair of patterns. I believe the list form will tend to lure the reader > into assuming the list is exhaustive when it is not. I do recognize that > this is explicitly disclaimed, which is why I will agree if the other > authors prefer this formulation. > >>>>>>> > >>>>>>> I agree with Ted and also prefer the original version. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 5) <!--[rfced] To avoid using "ensures" and "ensuring" in > close > >>>>>>>> proximity, may we rephrase this sentence as follows? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> For instance, QUIC replaces TCP for various applications and > ensures > >>>>>>>> end-to-end signals are only accessible by the endpoints, > ensuring > >>>>>>>> evolvability [RFC9000]. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> For instance, QUIC replaces TCP for various applications so > that > >>>>>>>> end-to-end signals are only accessible by the endpoints, > ensuring > >>>>>>>> the ability to evolve [RFC9000]. > >>>>>>>> > >>>>>>>> I don't think this captures the sense of the original. Would > this work: > >>>>>>>> > >>>>>>>> For instance, QUIC replaces TCP for various applications and > protects end-to-end signals so that they are only accessible by the > endpoints, ensuring evolvability [RFC9000]. > >>>>>>> > >>>>>>> Ted proposals looks good! > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> --> > >>>>>>>> > >>>>>>>> > >>>>>>>> 6) <!-- [rfced] FYI, to make the items easier to read, we > formatted this text > >>>>>>>> as a list. Please let us know of any objections. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Authentication and trust > >>>>>>>> must be considered in both directions: how endpoints trust and > >>>>>>>> authenticate signals from network path elements, and how > network path > >>>>>>>> elements trust and authenticate signals from endpoints. > >>>>>>>> > >>>>>>>> Current: > >>>>>>>> Authentication and trust > >>>>>>>> must be considered in both directions: > >>>>>>>> > >>>>>>>> * how endpoints trust and authenticate signals from network > path > >>>>>>>> elements and > >>>>>>>> > >>>>>>>> * how network path elements trust and authenticate signals > from > >>>>>>>> endpoints. > >>>>>>>> --> > >>>>>>>> > >>>>>>>> > >>>>>>>> I do not personally believe this improves the readability. > >>>>>>> > >>>>>>> I also prefer the original. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 7) <!--[rfced] We rephrased this sentence for clarity; please > let us know > >>>>>>>> of any objections. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> This section also provides some examples and explanation > >>>>>>>> of situations that not following the principles can lead to. > >>>>>>>> > >>>>>>>> Current: > >>>>>>>> This section also provides some examples and explanation > >>>>>>>> of situations that can arise when the principles are not > >>>>>>>> followed. > >>>>>>>> --> > >>>>>>>> > >>>>>>>> > >>>>>>>> Would this work: > >>>>>>>> > >>>>>>>> This section also provides examples and explores the > consequences of not following these principles in those examples. > >>>>>>> > >>>>>>> Ted’s proposal works for me. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 8) <!-- [rfced] Please clarify "they are from and to other > parties". Would "they > >>>>>>>> are coming from and going to other parties" help clarify? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Note that these communications are conceptually > >>>>>>>> independent of the base flow, even if they share a packet; > they are > >>>>>>>> from and to other parties, rather than creating a multiparty > >>>>>>>> communication. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> Note that these communications are conceptually > >>>>>>>> independent of the base flow, even if they share a packet; > they are > >>>>>>>> coming from and going to other parties, rather than creating a > >>>>>>>> multiparty communication. > >>>>>>>> --> > >>>>>>>> > >>>>>>>> > >>>>>>>> I am fine with this change. > >>>>>>> > >>>>>>> Okay. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 9) <!-- [rfced] We would like to rephrase this information as > follows for > >>>>>>>> clarity and to reduce redundancy. Please let us know if the > >>>>>>>> preferred text is agreeable or if you prefer otherwise. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> The goal is that any information should be provided > knowingly, for a > >>>>>>>> specific purpose, sent in signals designed for that purpose, > and that > >>>>>>>> any use of information should be done within that purpose. > And that > >>>>>>>> an analysis of the security and privacy implications of the > specific > >>>>>>>> purpose and associated information is needed. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> The goal is that any information should be provided knowingly > for a > >>>>>>>> specific purpose, sent in signals designed for that purpose, > and used > >>>>>>>> within that purpose. In addition, an analysis of the security > and privacy > >>>>>>>> implications of the specific purpose and associated > information is needed. > >>>>>>>> --> > >>>>>>>> > >>>>>>>> I think the phrasing of the second sentence is an > improvement, but I prefer the original formulation of the first sentence. > In particular, I believe "should be provided knowingly, for a specific > purpose," is clearer that the two elements are distinct characteristics of > the goal. > >>>>>>> > >>>>>>> Yes, knowingly and specific purpose are two separate points. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 10) <!--[rfced] Would it be clearer to say "Even if" instead > of "Whether" > >>>>>>>> and "it does not mean" instead of "it does not follow" in the > >>>>>>>> following sentence? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Whether a communication is with an application server or > >>>>>>>> network element that can be shown to be associated with a > particular > >>>>>>>> domain name, it does not follow that information about the > user can > >>>>>>>> be safely sent to it. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> Even if communication with an application server or network > >>>>>>>> element can be shown to be associated with a particular > >>>>>>>> domain name, it does not mean that information about the > >>>>>>>> user can be safely sent to it. > >>>>>>>> --> > >>>>>>>> > >>>>>>>> I don't have a suggestion here--Jari, any thoughts on this > one? > >>>>>>>> > >>>>>>> > >>>>>>> This change would not be correct. The domain name part only > applies to network elements. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 11) <!--[rfced] The following list is not parallel. Please > let us know if > >>>>>>>> the perhaps text captures the intended meaning. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> And of course we need to choose such cases where the > collaboration > >>>>>>>> can be performed safely, is not a privacy concern, and the > >>>>>>>> incentives of the relevant parties are aligned. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> And, of course, we need to choose such cases where the > collaboration > >>>>>>>> can be performed safely, there are no privacy concerns, and > the > >>>>>>>> incentives of the relevant parties are aligned. > >>>>>>>> --> > >>>>>>>> > >>>>>>>> > >>>>>>>> Would this work: > >>>>>>>> > >>>>>>>> And of course we need to choose cases where the collaboration > >>>>>>>> can be performed safely, where it is not a privacy concern, > and where the > >>>>>>>> incentives of the relevant parties are aligned. > >>>>>>>> > >>>>>>>> The original had a specific focus: the collaboration not > being a privacy concern. I'm a bit concerned that "there are no privacy > concerns" is too expansive. > >>>>>>> > >>>>>>> Agree this Ted. > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 12) <!--[rfced] Some of the bullet points in this list begin > with a > >>>>>>>> complete sentence and some begin with a fragmented sentence > (see > >>>>>>>> #4, #5, and #6). Please let us know if/how we may make the > list > >>>>>>>> parallel. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> * Some forms of collaboration may depend on business > arrangements, > >>>>>>>> which may or may not be easy to put in place. > >>>>>>>> > >>>>>>>> * Secure communications with path elements is needed as > discussed in > >>>>>>>> Section 2.3. > >>>>>>>> > >>>>>>>> * The use of path signals for reducing the effects of > denial-of- > >>>>>>>> service attacks, e.g., perhaps modern forms of "source > quench" > >>>>>>>> designs could be developed. > >>>>>>>> > >>>>>>>> * Ways of protecting information when held by network > elements or > >>>>>>>> servers, beyond communications security. > >>>>>>>> > >>>>>>>> * Sharing information from networks to applications. > >>>>>>>> > >>>>>>>> * Sharing information from applications to networks. > >>>>>>>> > >>>>>>>> * Data privacy regimes generally deal with more issues than > merely > >>>>>>>> whether some information is shared with another party or > not. > >>>>>>>> > >>>>>>>> * The present work has focused on the technical aspects of > making > >>>>>>>> collaboration safe and mutually beneficial, but of course, > >>>>>>>> deployments need to take into account various regulatory > and other > >>>>>>>> policy matters. > >>>>>>>> --> > >>>>>>>> > >>>>>>>> I think these should all be complete sentences; if everyone > agrees, I can take a whack at some suggested expansions. > >>>>>>> > >>>>>>> Sure we can do that. Please do! > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 13) <!--[rfced] For better readability, we combined the > following > >>>>>>>> sentences. Please let us know if this is accurate or please > clarify. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Finding practical ways for this has been difficult, both from > the > >>>>>>>> mechanics and scalability point view. And also because there > >>>>>>>> is no easy way to find out which parties to trust or what > trust > >>>>>>>> roots would be appropriate. > >>>>>>>> > >>>>>>>> Current: > >>>>>>>> Finding practical ways for this has been difficult, both from > the > >>>>>>>> mechanics and scalability point of view, especially because > there > >>>>>>>> is no easy way to find out which parties to trust or what > trust > >>>>>>>> roots would be appropriate. > >>>>>>>> --> > >>>>>>>> > >>>>>>>> > >>>>>>>> I think it would be "partially because" rather than > "especially because" if you combine them, but I'm okay with keeping > "especially because" if others prefer it. > >>>>>>> > >>>>>>> Yes, are that “partially because” would be better. > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 14) <!--[rfced] May we rephrase this sentence for clarity as > follows? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Data privacy regimes generally deal with more issues than > merely > >>>>>>>> whether some information is shared with another party or not. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> Data privacy regimes generally deal with multiple issues, not > just > >>>>>>>> whether or not some information is shared with another party. > >>>>>>>> --> > >>>>>>>> > >>>>>>>> > >>>>>>>> I am okay with this change. > >>>>>>> > >>>>>>> Okay for me. > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 15) <!-- [rfced] IAB Formatting > >>>>>>>> > >>>>>>>> a) Please review the guidance for IAB documents > >>>>>>>> <https://www.rfc-editor.org/materials/iab-format.txt> and > let us know if any > >>>>>>>> changes are needed. > >>>>>>>> > >>>>>>>> Note that if you include an "IAB Members at the Time of > Approval" section > >>>>>>>> (since this document has IAB consensus), it will appear > before the > >>>>>>>> Acknowledgements section and will list the members listed on < > https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-61ecd4ae9402f3ac&q=1&e=cc45abf9-d14e-4cfa-b2a0-031a6b9c7a4e&u=https%3A%2F%2Fwww.iab.org%2Fabout%2Fiab-members%2F> > unless you specify otherwise. > >>>>>>>> --> > >>>>>>> > >>>>>>> Yes, please include this section. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 16) <!-- [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. > >>>>>>>> > >>>>>>>> Note that our script did not flag any words in particular, > but this should > >>>>>>>> still be reviewed as a best practice. > >>>>>>>> --> > >>>>>>> > >>>>>>> Thanks! > >>>>>>> > >>>>>>> Mirja > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Thank you. > >>>>>>>> > >>>>>>>> RFC Editor/st/kc > >>>>>>>> > >>>>>>>> > >>>>>>>> On Jun 1, 2023, at 11:52 AM, rfc-editor@rfc-editor.org wrote: > >>>>>>>> > >>>>>>>> *****IMPORTANT***** > >>>>>>>> > >>>>>>>> Updated 2023/06/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 > >>>>>>>> > >>>>>>>> * 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://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, > >>>>>>>> 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://www.rfc-editor.org/authors/rfc9419.xml > >>>>>>>> https://www.rfc-editor.org/authors/rfc9419.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9419.pdf > >>>>>>>> https://www.rfc-editor.org/authors/rfc9419.txt > >>>>>>>> > >>>>>>>> Diff file of the text: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9419-diff.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9419-rfcdiff.html > (side by side) > >>>>>>>> > >>>>>>>> Diff of the XML: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9419-xmldiff1.html > >>>>>>>> > >>>>>>>> The following files are provided to facilitate creation of > your own > >>>>>>>> diff files of the XML. > >>>>>>>> > >>>>>>>> Initial XMLv3 created using XMLv2 as input: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9419.original.v2v3.xml > >>>>>>>> > >>>>>>>> XMLv3 file that is a best effort to capture v3-related format > updates > >>>>>>>> only: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9419.form.xml > >>>>>>>> > >>>>>>>> > >>>>>>>> Tracking progress > >>>>>>>> ----------------- > >>>>>>>> > >>>>>>>> The details of the AUTH48 status of your document are here: > >>>>>>>> https://www.rfc-editor.org/auth48/rfc9419 > >>>>>>>> > >>>>>>>> Please let us know if you have any questions. > >>>>>>>> > >>>>>>>> Thank you for your cooperation, > >>>>>>>> > >>>>>>>> RFC Editor > >>>>>>>> > >>>>>>>> -------------------------------------- > >>>>>>>> RFC9419 (draft-iab-path-signals-collaboration-03) > >>>>>>>> > >>>>>>>> Title : Considerations on Application - Network > Collaboration Using Path Signals > >>>>>>>> Author(s) : J. Arkko, T. Hardie, T. Pauly, M. > Kuehlewind > >>>>>>>> WG Chair(s) : > >>>>>>>> Area Director(s) : > >>>>>>>> > >>>> > >>> > >>> > >> > >> > > > > > > > >
- [auth48] AUTH48: RFC-to-be 9419 <draft-iab-path-s… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9419 <draft-iab-pa… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9419 <draft-iab-pa… Ted Hardie
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Mirja Kuehlewind
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Mirja Kuehlewind
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Karen Moore
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Tommy Pauly
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Mirja Kuehlewind
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Alice Russo
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Ted Hardie
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Karen Moore
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Tommy Pauly
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Karen Moore
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Mirja Kuehlewind
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Mirja Kuehlewind
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Karen Moore
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Mirja Kuehlewind
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Ted Hardie
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Karen Moore
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Jari Arkko
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Mirja Kuehlewind
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Ted Hardie
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Mirja Kuehlewind
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-… Karen Moore