draft-iab-path-signals-collaboration-02.txt   draft-iab-path-signals-collaboration.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational T. Hardie Intended status: Informational T. Hardie
Expires: April 22, 2023 Cisco Expires: August 27, 2023 Cisco
T. Pauly T. Pauly
Apple Apple
M. Kuehlewind M. Kuehlewind
Ericsson Ericsson
October 19, 2022 February 23, 2023
Considerations on Application - Network Collaboration Using Path Signals Considerations on Application - Network Collaboration Using Path Signals
draft-iab-path-signals-collaboration-02 draft-iab-path-signals-collaboration-03
Abstract Abstract
This document discusses principles for designing mechanisms that use This document discusses principles for designing mechanisms that use
or provide path signals, and calls for standards action in specific or provide path signals, and calls for standards action in specific
valuable cases. RFC 8558 describes path signals as messages to or valuable cases. RFC 8558 describes path signals as messages to or
from on-path elements, and points out that visible information will from on-path elements, and points out that visible information will
be used whether it is intended as a signal or not. The principles in be used whether it is intended as a signal or not. The principles in
this document are intended as guidance for the design of explicit this document are intended as guidance for the design of explicit
path signals, which are encouraged to be authenticated and include a path signals, which are encouraged to be authenticated and include a
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2023. This Internet-Draft will expire on August 27, 2023.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 8, line 34 skipping to change at page 8, line 34
Many Internet communications are not performed on behalf of the Many Internet communications are not performed on behalf of the
applications, but are ultimately made on behalf of users. However, applications, but are ultimately made on behalf of users. However,
not all information that may be shared directly relates to user not all information that may be shared directly relates to user
actions or other sensitive data. All information shared must be actions or other sensitive data. All information shared must be
evaluated carefully to identify potential privacy implications for evaluated carefully to identify potential privacy implications for
users. Information that directly relates to the user should not be users. Information that directly relates to the user should not be
shared without the user's consent. It should be noted that the shared without the user's consent. It should be noted that the
interests of the user and other parties, such as the application interests of the user and other parties, such as the application
developer, may not always coincide; some applications may wish to developer, may not always coincide; some applications may wish to
collect more information about the user than the user would like. collect more information about the user than the user would like. As
How to achieve a balance of control between the actual user and an discussed in [RFC8890], from an IETF point view, the interests of the
application representing an user's interest is out of scope for this user should be prioritized over those of the application developer.
document. The general issue of how to achieve a balance of control between the
actual user and an application representing an user's interest is out
of scope for this document.
2.3. Protecting Information and Authentication 2.3. Protecting Information and Authentication
Some simple forms of information often exist in cleartext form, e.g, Some simple forms of information often exist in cleartext form, e.g,
ECN bits from routers are generally not authenticated or integrity ECN bits from routers are generally not authenticated or integrity
protected. This is possible when the information exchanges do not protected. This is possible when the information exchanges do not
carry any significantly sensitive information from the parties. carry any significantly sensitive information from the parties.
Often these kind of interactions are also advisory in their nature Often these kind of interactions are also advisory in their nature
(see also section Section 2.5). (see also section Section 2.5).
skipping to change at page 14, line 16 skipping to change at page 14, line 16
The authors would like to thank everyone at the IETF, the IAB, and The authors would like to thank everyone at the IETF, the IAB, and
our day jobs for interesting thoughts and proposals in this space. our day jobs for interesting thoughts and proposals in this space.
Fragments of this document were also in Fragments of this document were also in
[I-D.per-app-networking-considerations] and [I-D.per-app-networking-considerations] and
[I-D.arkko-path-signals-information] that were published earlier. We [I-D.arkko-path-signals-information] that were published earlier. We
would also like to acknowledge [I-D.trammell-stackevo-explicit-coop] would also like to acknowledge [I-D.trammell-stackevo-explicit-coop]
for presenting similar thoughts. Finally, the authors would like to for presenting similar thoughts. Finally, the authors would like to
thank Adrian Farrell, Toerless Eckert, Martin Thomson, Mark thank Adrian Farrell, Toerless Eckert, Martin Thomson, Mark
Nottingham, Luis M. Contreras, Watson Ladd, Vittorio Bertola, Andrew Nottingham, Luis M. Contreras, Watson Ladd, Vittorio Bertola, Andrew
Campling, Eliot Lear, Spencer Dawkins, Christian Huitema, Mallory Campling, Eliot Lear, Spencer Dawkins, Christian Huitema, David
Knodel, Zhenbin Li, Chris Box, and Jeffrey Haas for useful feedback Schinazi, Cullen Jennings, Mallory Knodel, Zhenbin Li, Chris Box, and
on this topic and this draft. Jeffrey Haas for useful feedback on this topic and this draft.
5. Informative References 5. Informative References
[Claffy2015] [Claffy2015]
kc Claffy, . and D. Clark, "Adding Enhanced Services to kc Claffy, . and D. Clark, "Adding Enhanced Services to
the Internet: Lessons from History", TPRC 43: The 43rd the Internet: Lessons from History", TPRC 43: The 43rd
Research Conference on Communication, Information and Research Conference on Communication, Information and
Internet Policy Paper , April 2015. Internet Policy Paper , April 2015.
[I-D.arkko-dns-confidential] [I-D.arkko-dns-confidential]
Jari Arkko, and Jiri Novotny, "Privacy Improvements for Arkko, J. and J. Novotny, "Privacy Improvements for DNS
DNS Resolution with Confidential Computing", draft-arkko- Resolution with Confidential Computing", draft-arkko-dns-
dns-confidential-02 (work in progress), July 2021, confidential-02 (work in progress), July 2021,
<https://www.ietf.org/archive/id/draft-arkko-dns- <https://datatracker.ietf.org/doc/html/draft-arkko-dns-
confidential-02.txt>. confidential-02>.
[I-D.arkko-path-signals-information] [I-D.arkko-path-signals-information]
Jari Arkko, , "Considerations on Information Passed Arkko, J., "Considerations on Information Passed between
between Networks and Applications", draft-arkko-path- Networks and Applications", draft-arkko-path-signals-
signals-information-00 (work in progress), February 2021, information-00 (work in progress), February 2021,
<https://www.ietf.org/archive/id/draft-arkko-path-signals- <https://datatracker.ietf.org/doc/html/draft-arkko-path-
information-00.txt>. signals-information-00>.
[I-D.flinck-mobile-throughput-guidance] [I-D.flinck-mobile-throughput-guidance]
Ankur Jain, , Andreas Terzis, , Hannu Flinck, , Nurit Jain, A., Terzis, A., Flinck, H., Sprecher, N.,
Sprecher, , Swaminathan Arunachalam, , Kevin Smith, , Arunachalam, S., Smith, K., Devarapalli, V., and R. Yanai,
Vijay Devarapalli, , and Roni Bar Yanai, "Mobile "Mobile Throughput Guidance Inband Signaling Protocol",
Throughput Guidance Inband Signaling Protocol", draft- draft-flinck-mobile-throughput-guidance-04 (work in
flinck-mobile-throughput-guidance-04 (work in progress), progress), March 2017,
March 2017, <https://www.ietf.org/archive/id/draft-flinck- <https://datatracker.ietf.org/doc/html/draft-flinck-
mobile-throughput-guidance-04.txt>. mobile-throughput-guidance-04>.
[I-D.ietf-quic-manageability] [I-D.ietf-quic-manageability]
Mirja Kuehlewind, and Brian Trammell, "Manageability of Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
the QUIC Transport Protocol", draft-ietf-quic- Transport Protocol", draft-ietf-quic-manageability-18
manageability-18 (work in progress), July 2022, (work in progress), July 2022,
<https://www.ietf.org/archive/id/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
manageability-18.txt>. manageability-18>.
[I-D.per-app-networking-considerations] [I-D.per-app-networking-considerations]
Lorenzo Colitti, and Tommy Pauly, "Per-Application Colitti, L. and T. Pauly, "Per-Application Networking
Networking Considerations", draft-per-app-networking- Considerations", draft-per-app-networking-
considerations-00 (work in progress), November 2020, considerations-00 (work in progress), November 2020,
<https://www.ietf.org/archive/id/draft-per-app-networking- <https://datatracker.ietf.org/doc/html/draft-per-app-
considerations-00.txt>. networking-considerations-00>.
[I-D.thomson-http-oblivious] [I-D.thomson-http-oblivious]
Martin Thomson, and A. Christopher Wood, "Oblivious HTTP", Thomson, M. and C. Wood, "Oblivious HTTP", draft-thomson-
draft-thomson-http-oblivious-02 (work in progress), August http-oblivious-02 (work in progress), August 2021,
2021, <https://www.ietf.org/archive/id/draft-thomson-http- <https://datatracker.ietf.org/doc/html/draft-thomson-http-
oblivious-02.txt>. oblivious-02>.
[I-D.trammell-stackevo-explicit-coop] [I-D.trammell-stackevo-explicit-coop]
Brian Trammell, , "Architectural Considerations for Trammell, B., "Architectural Considerations for Transport
Transport Evolution with Explicit Path Cooperation", Evolution with Explicit Path Cooperation", draft-trammell-
draft-trammell-stackevo-explicit-coop-00 (work in stackevo-explicit-coop-00 (work in progress), September
progress), September 2015, 2015, <https://datatracker.ietf.org/doc/html/draft-
<https://www.ietf.org/archive/id/draft-trammell-stackevo- trammell-stackevo-explicit-coop-00>.
explicit-coop-00.txt>.
[I-D.yiakoumis-network-tokens] [I-D.yiakoumis-network-tokens]
Yiannis Yiakoumis, , Nick McKeown, , and Frode Sorensen, Yiakoumis, Y., McKeown, N., and F. Sorensen, "Network
"Network Tokens", draft-yiakoumis-network-tokens-02 (work Tokens", draft-yiakoumis-network-tokens-02 (work in
in progress), December 2020, progress), December 2020,
<https://www.ietf.org/archive/id/draft-yiakoumis-network- <https://datatracker.ietf.org/doc/html/draft-yiakoumis-
tokens-02.txt>. network-tokens-02>.
[Oblivious] [Oblivious]
Schmitt, P., "Oblivious DNS: Practical privacy for DNS Schmitt, P., "Oblivious DNS: Practical privacy for DNS
queries", Proceedings on Privacy Enhancing Technologies queries", Proceedings on Privacy Enhancing Technologies
2019.2: 228-244 , 2019. 2019.2: 228-244 , 2019.
[PDoT] Nakatsuka, Y., Paverd, A., and G. Tsudik, "PDoT: Private [PDoT] Nakatsuka, Y., Paverd, A., and G. Tsudik, "PDoT: Private
DNS-over-TLS with TEE Support", Digit. Threat.: Res. DNS-over-TLS with TEE Support", Digit. Threat.: Res.
Pract., Vol. 2, No. 1, Article 3, https://dl.acm.org/doi/ Pract., Vol. 2, No. 1, Article 3, https://dl.acm.org/doi/
fullHtml/10.1145/3431171 , February 2021. fullHtml/10.1145/3431171 , February 2021.
skipping to change at page 16, line 37 skipping to change at page 16, line 37
[RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet
Technology Adoption and Transition (ITAT)", RFC 7305, Technology Adoption and Transition (ITAT)", RFC 7305,
DOI 10.17487/RFC7305, July 2014, <https://www.rfc- DOI 10.17487/RFC7305, July 2014, <https://www.rfc-
editor.org/info/rfc7305>. editor.org/info/rfc7305>.
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
RFC 8558, DOI 10.17487/RFC8558, April 2019, RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/info/rfc8558>. <https://www.rfc-editor.org/info/rfc8558>.
[RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890,
DOI 10.17487/RFC8890, August 2020, <https://www.rfc-
editor.org/info/rfc8890>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, <https://www.rfc- DOI 10.17487/RFC9000, May 2021, <https://www.rfc-
editor.org/info/rfc9000>. editor.org/info/rfc9000>.
[RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to [RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to
Deployment (A Bestiary of Roads Not Taken)", RFC 9049, Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
DOI 10.17487/RFC9049, June 2021, <https://www.rfc- DOI 10.17487/RFC9049, June 2021, <https://www.rfc-
editor.org/info/rfc9049>. editor.org/info/rfc9049>.
 End of changes. 17 change blocks. 
53 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/