Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-iab-path-signals-collaboration-03> for your review

[Ted Hardie <[e-mail]>]

Howdy,

On Fri, Jun 30, 2023 at 3:41 PM Mirja Kuehlewind <[e-mail]>
wrote:

> Hi Karen,
>
> So I think that means we all agree to keep the initial title.
>
> However, please consider if removing the white spaces before and after the
> “-“ would help to remove some of the ambiguity that you tried to address?
> Like this:
>
> OLD
>
> Considerations on Application - Network Collaboration Using Path Signals
>
>
> NEW
>
> Considerations on Application-Network Collaboration Using Path Signals
>
>
I would prefer not to make that change; at least to my somewhat
old-fashioned thinking, using the two without the space makes it seem like
a reference to a single thing (an "application-network") rather than a
collaborating pair.

I am otherwise happy to see this published.

regards,

Ted




> Please also record me as approving all other changes in that version.
>
> Mirja
>
>
>
> On 30. Jun 2023, at 13:48, Jari Arkko <[e-mail]> wrote:
>
> Hi Karen,
>
> I agree with the other authors about the title.
>
> I have also reviewed the current state of the RFC-to-be, the changes from
> the approved version, and I have no concerns. On my behalf you are ready to
> publish.
>
> Jari
>
>
> *Lähettäjä: *Karen Moore <[e-mail]>
> *Päivämäärä: *keskiviikkona, 28. kesäkuuta 2023 klo 20.56
> *Vastaanottaja: *Ted Hardie <[e-mail]>, Tommy Pauly <
> tpauly=[e-mail]>, Mirja Kuehlewind <[e-mail]>,
> Jari Arkko <[e-mail]>
> *Kopio: *RFC Editor <[e-mail]>,
> [e-mail] <[e-mail]>, IAB <
> [e-mail]>
> *Aihe: *Re: [IAB] AUTH48: RFC-to-be 9419
> <draft-iab-path-signals-collaboration-03> for your review
> Mirja and Ted,
>
> We reverted the title to the original.  If Jari has a different opinion,
> we would be happy to make further updates.
>
> 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
>
> For the AUTH48 status of this document, please see:
>  https://www.rfc-editor.org/auth48/rfc9419
>
> 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 27, 2023, at 4:53 AM, Ted Hardie <[e-mail]> wrote:
> >
> > On Tue, Jun 27, 2023 at 10:52 AM Mirja Kuehlewind <[e-mail]>
> 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" <[e-mail]> 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 <
> [e-mail]> 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=[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
> 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 <[e-mail]>
> 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=[e-mail]> 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=[e-mail]>
> >     >>>>> Date: Thursday, 8. June 2023 at 17:51
> >     >>>>> To: Karen Moore <[e-mail]>, Ted Hardie <
> [e-mail]>
> >     >>>>> Cc: Mirja Kuehlewind <[e-mail]>, Jari
> Arkko <[e-mail]>, RFC Editor <[e-mail]>, "
> [e-mail]" <[e-mail]>, IAB <
> [e-mail]>
> >     >>>>> 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 <[e-mail]>
> 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=[e-mail]> 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 <[e-mail]>
> wrote:
> >     >>>>>>>>
> >     >>>>>>>> Some personal answers to the questions in-line.
> >     >>>>>>>>
> >     >>>>>>>> On Thu, Jun 1, 2023 at 7:53 PM <[e-mail]>
> 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, [e-mail]
> 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
> >     >>>>>>>>
> >     >>>>>>>> *  [e-mail] (the RPC team)
> >     >>>>>>>>
> >     >>>>>>>> *  other document participants, depending on the stream
> (e.g.,
> >     >>>>>>>>  IETF Stream participants are your working group chairs, the
> >     >>>>>>>>  responsible ADs, and the document shepherd).
> >     >>>>>>>>
> >     >>>>>>>> *  [e-mail], which is a new archival
> mailing list
> >     >>>>>>>>  to preserve AUTH48 conversations; it is not an active
> discussion
> >     >>>>>>>>  list:
> >     >>>>>>>>
> >     >>>>>>>> *  More info:
> >     >>>>>>>>
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> >     >>>>>>>>
> >     >>>>>>>> *  The archive itself:
> >     >>>>>>>>    https://mailarchive.ietf.org/arch/browse/auth48archive/
> >     >>>>>>>>
> >     >>>>>>>> *  Note: If only absolutely necessary, you may temporarily
> opt out
> >     >>>>>>>>    of the archiving of messages (e.g., to discuss a
> sensitive matter).
> >     >>>>>>>>    If needed, please add a note at the top of the message
> that you
> >     >>>>>>>>    have dropped the address. When the discussion is
> concluded,
> >     >>>>>>>>    [e-mail] will be re-added to the CC
> list and
> >     >>>>>>>>    its addition will be noted at the top of the message.
> >     >>>>>>>>
> >     >>>>>>>> You may submit your changes in one of two ways:
> >     >>>>>>>>
> >     >>>>>>>> An update to the provided XML file
> >     >>>>>>>> — OR —
> >     >>>>>>>> An explicit list of changes in this format
> >     >>>>>>>>
> >     >>>>>>>> Section # (or indicate Global)
> >     >>>>>>>>
> >     >>>>>>>> OLD:
> >     >>>>>>>> old text
> >     >>>>>>>>
> >     >>>>>>>> NEW:
> >     >>>>>>>> new text
> >     >>>>>>>>
> >     >>>>>>>> You do not need to reply with both an updated XML file and
> an explicit
> >     >>>>>>>> list of changes, as either form is sufficient.
> >     >>>>>>>>
> >     >>>>>>>> We will ask a stream manager to review and approve any
> changes that seem
> >     >>>>>>>> beyond editorial in nature, e.g., addition of new text,
> deletion of text,
> >     >>>>>>>> and technical changes.  Information about stream managers
> can be found in
> >     >>>>>>>> the FAQ.  Editorial changes do not require approval from a
> stream manager.
> >     >>>>>>>>
> >     >>>>>>>>
> >     >>>>>>>> Approving for publication
> >     >>>>>>>> --------------------------
> >     >>>>>>>>
> >     >>>>>>>> To approve your RFC for publication, please reply to this
> email stating
> >     >>>>>>>> that you approve this RFC for publication.  Please use
> ‘REPLY ALL’,
> >     >>>>>>>> as all the parties CCed on this message need to see your
> approval.
> >     >>>>>>>>
> >     >>>>>>>>
> >     >>>>>>>> Files
> >     >>>>>>>> -----
> >     >>>>>>>>
> >     >>>>>>>> The files are available here:
> >     >>>>>>>> https://www.rfc-editor.org/authors/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) :
> >     >>>>>>>>
> >     >>>>
> >     >>>
> >     >>>
> >     >>
> >     >>
> >     >
> >     >
> >
> >
> >
>
>
>