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

[Ted Hardie <[e-mail]>]

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".



>
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the title) for use on https://www.rfc-editor.org/search.
> -->
>
>
> 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.

>
> 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.




>
> 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].



> -->
>
>
> 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.



>
> 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.




>
> 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.



>
> 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.


> 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?



>
> 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.


>
> 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.



>
> 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.



>
> 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.



>
> 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://www.iab.org/about/iab-members/> unless you specify otherwise.
> -->
>
>
> 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.
> -->
>
>
> 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) :
>
>
>
>