On Dec 6, 2024, at 10:16 AM, Colin Perkins<c...@csperkins.org> wrote:
Hi,
Thanks for all the work on this. I have just one nit: in the bullet points at
the end of Section 2, just before the Section 2.1 heading: “is asynchronous and
event-driven” was changed to “is asynchronous and driven by events”. I think
the original is correct, “Event-driven” is the usual term for these types of
system.
Otherwise, I approve publication.
Cheers,
Colin
On 6 Dec 2024, at 16:42, Megan Ferguson wrote:
Brian and Gorry,
Thanks for the replies. We have updated our current version of the document
with the short/running title suggested by Brian.
The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9621.txt
https://www.rfc-editor.org/authors/rfc9621.pdf
https://www.rfc-editor.org/authors/rfc9621.html
https://www.rfc-editor.org/authors/rfc9621.xml
The relevant diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9621-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9621-auth48diff.html (AUTH48 changes
only)
https://www.rfc-editor.org/authors/rfc9621-lastdiff.html (last to current
version only)
Please contact us with any further updates/questions/comments you may have.
We will await approvals from each of the parties listed on the AUTH48 status
page prior to moving forward to publication.
The AUTH48 status page for this document is available here:
https://www.rfc-editor.org/auth48/rfc9621
Thank you.
RFC Editor/mf
On Dec 6, 2024, at 6:02 AM, Gorry fairhurstgo...@erg.abdn.ac.uk wrote:
On 06/12/2024 12:47, Brian Trammell (IETF) wrote:
Not the document title, the short / footer title (which currently reads TAPS
Architecture).
Aha.
Yes, I strongly agree with THAT proposal to change "<title abbrev="...:
Gorry
On 6 Dec 2024, at 13:43, Gorry fairhurstgo...@erg.abdn.ac.uk wrote:
On 06/12/2024 12:37, Brian Trammell (IETF) wrote:
I’d prefer to update the running title to “Transport Services Architecture” to
reflect the other documents.
We debated this in some detail earlier and arrived at:
Architecture and Requirements for Transport Services
I'm just asking why we need a change now?
Gorry
With that change, I approve this revision.
Thanks! Cheers,
Brian
On 5 Dec 2024, at 19:49, Megan fergusonmfergu...@amsl.com wrote:
Authors,
Just an FYI that we have updated the files to include the title change to
RFC-to-be 9622 in the reference entry. You may review the change in the files
below.
Please also review the short/running title using TAPS and let us know if/how
this should be updated as it has been changed in the other docs in this cluster.
The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9621.txt
https://www.rfc-editor.org/authors/rfc9621.pdf
https://www.rfc-editor.org/authors/rfc9621.html
https://www.rfc-editor.org/authors/rfc9621.xml
The relevant diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9621-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9621-auth48diff.html (AUTH48 changes
only)
https://www.rfc-editor.org/authors/rfc9621-lastdiff.html (last to current
version only)
Please contact us with any further updates/questions/comments you may have.
We will await approvals from each of the parties listed on the AUTH48 status
page prior to moving forward to publication.
The AUTH48 status page for this document is available here:
https://www.rfc-editor.org/auth48/rfc9621
Thank you.
RFC Editor/mf
On Nov 29, 2024, at 12:50 PM, Gorry fairhurstgo...@erg.abdn.ac.uk wrote:
On 29/11/2024 13:17, Colin Perkins wrote:
Hi Megan,
Happy with the changes so far.
Regarding the <tt> query: I actually think the use of <tt> helps readability,
provided we can be sure it’s consistent. It’s not critical, but it helps.
Colin
+1 It helps, the render I see looks good.
Gorry
On 21 Nov 2024, at 20:43, Megan Ferguson wrote:
Hi Brian and Colin,
Thanks for the quick replies. We have a few comments/questions to follow up on:
• Regarding the use of <tt>:
• <!-- [rfced] Please review usage of <tt> in this document, and let us
know if any updates are needed. For example, we see
"to initiate a connection" (no <tt>) and "to Initiate a Connection"
in the XML file. -->
The usage here is not consistent.
The intention is that terms appearing in Figure 4 representing methods are
rendered in monospace (this is an implementation of the backtick notation in
Markdown, from which these XML files are generated).
<tt> around Listen, Initiate, Rendezvous, Rendezvous, Receive, Send, Close,
Abort (as capitalized) should remain; I see some around Connection that are spurious
and can be removed.
If this styling isn’t supported by the RFC Editor’s renderings of the XML, <tt>
can also be safely removed.
Before we make any updates to the use of <tt> in this document, we suggest the
authors have a look at both:
-the related <tt> query for RFC-to-be 9622 and
-the html output for RFC-to-be 9622
and consider how to handle them with the following in mind:
• Whether the large volume of <tt> tags in RFC-to-be 9622, in addition to a
heavy amount of capped terms, might actually be distracting to readers.
• The author workload necessary to make the use of <tt> tags consistent within
RFC-to-be 9622 itself and among the docs in the cluster. Because many of these terms
vary in capitalization (see the example in our original query above) or are used
sometimes in a general sense or without labels, locating and applying these fixes may
prove somewhat difficult.
Note: We are currently completing our review of RFC-to-be 9623, which also uses
<tt>.
Please let us know how best to proceed.
• Regarding the [POSIX] reference, should we update to the 2017 or 2024 version?
All other updates are available for you to review.
Please review the files carefully as we do not make changes after publication.
The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9621.txt
https://www.rfc-editor.org/authors/rfc9621.pdf
https://www.rfc-editor.org/authors/rfc9621.html
https://www.rfc-editor.org/authors/rfc9621.xml
The relevant diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9621-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9621-auth48diff.html (AUTH48 changes
only)
https://www.rfc-editor.org/authors/rfc9621-lastdiff.html (last to current
version only)
Please contact us with any further updates/questions/comments you may have.
We will await approvals from each of the parties listed on the AUTH48 status
page prior to moving forward to publication.
The AUTH48 status page for this document is available here:
https://www.rfc-editor.org/auth48/rfc9621
Thank you.
RFC Editor/mf
On Nov 19, 2024, at 11:03 AM, Brian Trammell (IETF)i...@trammell.ch wrote:
Greetings, all,
Answers to editor questions inline, below.
On 19 Nov 2024, at 00:29,rfc-edi...@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.
Note: Further questions that affect multiple documents in this cluster (C508)
will be sent in separate mail.
Please see cluster info at:https://www.rfc-editor.org/auth48/C508.
• <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use onhttps://www.rfc-editor.org/search . -->
• <!-- [rfced] Section 1: Per Internet searches, it appears that some
consider the BSD Socket API to be distinct from the POSIX Socket API.
Please confirm that this text will be clear to readers.
Original:
Many application programming interfaces (APIs) to provide transport
interfaces to networks have been deployed, perhaps the most widely
known and imitated being the BSD Socket [POSIX] interface (Socket
API). -->
We can remove BSD here “…the Socket [POSIX] interface"
• <!-- [rfced] Section 1.4: We do not see the terms/words
"Transport Property" or any form of "prohib*" in RFC 8095.
Please confirm that this citation is correct and will be clear to
readers.
Original:
• Transport Property: A property that expresses requirements,
prohibitions and preferences [RFC8095]. -->
I suspect this is vestigial.
“A property of a transport protocol and the services it provides [RFC8095]."
• <!-- [rfced] Section 2.3: To what does "which are" refer in this
sentence - the identifiers, the IP addresses, or something else?
Original:
This
requires applications to specify identifiers for the Local and Remote
Endpoint that are higher-level than IP addresses, such as a hostname
or URL, which are used by a Transport Services Implementation for
resolution, path selection, and racing. -->
The identifiers.
• <!-- [rfced] Please review usage of <tt> in this document, and let us
know if any updates are needed. For example, we see
"to initiate a connection" (no <tt>) and "to Initiate a Connection"
in the XML file. -->
The usage here is not consistent.
The intention is that terms appearing in Figure 4 representing methods are
rendered in monospace (this is an implementation of the backtick notation in
Markdown, from which these XML files are generated).
<tt> around Listen, Initiate, Rendezvous, Rendezvous, Receive, Send, Close,
Abort (as capitalized) should remain; I see some around Connection that are spurious
and can be removed.
If this styling isn’t supported by the RFC Editor’s renderings of the XML, <tt>
can also be safely removed.
• <!-- [rfced] Section 4.1.1: To what does "this" refer in this
sentence?
Original (the previous sentence is included for context):
A Remote Endpoint Identifier can also
represent a multicast group or anycast address. In the case of
multicast, this selects a multicast transport for communication. -->
NEW: “In the case of multicast, a multicast transport will be selected"
• <!-- [rfced] Section 4.1.2: We do not see "Remote Endpoint
Identifier" mentioned in Section 4.1.3. Please confirm that this
citation is correct and will be clear to readers.
Original:
It has state that
describes parameters of the Connection: the Local Endpoint
Identifier from which that Connection will be established, the
Remote Endpoint Identifier (Section 4.1.3) to which it will
connect, and Transport Properties that influence the paths and
protocols a Connection will use. -->
The citation is spurious (probably vestigial) and can be removed.
• <!-- [rfced] Section 4.1.3: We changed "fast open support" to
"support for TCP Fast Open" per usage elsewhere in this cluster and
per post-6000 published RFCs. Please let us know any objections.
Original:
Examples of properties
that influence protocol selection and configuration of transport
protocol features include reliability, multipath support, and fast
open support.
Currently:
Examples of properties
that influence protocol selection and configuration of transport
protocol features include reliability, multipath support, and
support for TCP Fast Open. -->
While TCP is the only transport protocol supporting a fast open feature, the
choice here was deliberate to refer to the class of transport protocol features
containing TCP Fast Open in the abstract. Either is fine.
• <!-- [rfced] Section 4.1.7: We had trouble parsing this sentence.
We updated it as follows. If this is incorrect, please clarify the
text.
Original:
• Close: The action an application takes on a Connection to indicate
that it no longer intends to send data, is no longer willing to
receive data, and that the protocol should signal this state to
the Remote Endpoint if the transport protocol allows this.
Currently:
Close: The action an application takes on a Connection to indicate
that it no longer intends to send data or is no longer willing to
receive data. The protocol should signal this state to the Remote
Endpoint if the transport protocol permits it. -->
yep this is better (and remains as intended), thanks!
• <!-- [rfced] Section 4.1.7: This sentence does not parse. If the
suggested text is not correct, please clarify how "and immediately
drop the connection" relates to the rest of the sentence.
Original:
• Abort: The action the application takes on a Connection to
indicate a Close and also indicate that the Transport Services
System should not attempt to deliver any outstanding data, and
immediately drop the connection.
Suggested:
Abort: The action the application takes on a Connection to indicate
a Close and also indicate that the Transport Services System
should not attempt to deliver any outstanding data and should
immediately drop the connection. -->
Better, but I think this could be made clearer:
NEW:
Abort: The action the application takes on a Connection
to indicate that the Transport Services System
should not attempt to deliver any outstanding data, and should
immediately close and drop the connection
• <!-- [rfced] Section 4.2: This sentence does not parse. Please
clarify "going through a single security and transport protocol,
over IP; or, a multi-path transport protocol".
Original:
A single stack can be simple (a single transport
protocol instance over IP), or it can be complex (multiple
application protocol streams going through a single security and
transport protocol, over IP; or, a multi-path transport protocol
over multiple transport sub-flows). -->
Suggested rework:
A single stack can be simple (e.g. one application stream carried TCP running
over IP), or complex (e.g. multiple application streams carried over a
multipath transport protocol using multiple subflows over IP).
• <!-- [rfced] Section 4.2.3: What can lead to linkability - the
cached protocol state itself or the act of reusing it? If the
suggested text (the act of reusing cached protocol state) is not
correct, please provide clarifying text.
Original (previous text is included for context; also, we
restructured the list):
Possible reasons to isolate Connections using separate
Connection Contexts include:
• Privacy concerns about re-using cached protocol state that can
lead to linkability.
Suggested:
Possible reasons to isolate Connections using separate
Connection Contexts include privacy concerns regarding:
• reusing cached protocol state, as this can lead to linkability.
-->
This is good, thanks!
• <!-- [rfced] Section 6: We changed "other another security protocol
handshake that is" to "other security protocol handshakes that are".
If this is incorrect, please clarify the text.
Original:
For example, if an
application provides a certificate to only be used as client
authentication for outbound TLS and QUIC connections, the Transport
Services System MUST NOT use this automatically in other contexts
(such as server authentication for inbound connections, or in other
another security protocol handshake that is not equivalent to TLS).
Currently:
For example, if an
application provides a certificate to only be used as client
authentication for outbound TLS and QUIC connections, the Transport
Services System MUST NOT use this automatically in other contexts
(such as server authentication for inbound connections or in other
security protocol handshakes that are not equivalent to TLS). -->
yep, thanks!
• <!-- [rfced] The 2008 version of [POSIX] is marked "Superseded".
There is a 2017 revision (https://ieeexplore.ieee.org/document/8277153)
and a 2024 revision (https://ieeexplore.ieee.org/document/10555529).
Please let us know if you would like to update this reference to one
of these revisions; if yes, please let us know which revision is
appropriate for this document.
Original (double dash changed to single in order to avoid xml2rfc's
"Double hyphen within comment" error):
[POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology
• Portable Operating System Interface (POSIX). Open
group Technical Standard: Base Specifications, Issue 7",
2008. -->
Please update the reference, thanks!
• <!-- [rfced] RFC 5389 has been obsoleted by RFC 8489
(https://www.rfc-editor.org/info/rfc8489). As the citation in
Section 4.1.4 appears to be general in nature, we updated this
document to list and cite RFC 8489 instead, per companion document
draft-ietf-taps-interface. Please let us know any objections.
Original:
However, if the set of Local Endpoints includes
server reflexive candidates, such as those provided by STUN
(Session Traversal Utilities for NAT) [RFC5389], a Rendezvous
action will race candidates in the style of the ICE (Interactive
Connection Establishment) algorithm [RFC8445] to perform NAT
binding discovery and initiate a peer-to-peer connection.
...
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
https://www.rfc-editor.org/rfc/rfc5389 .
Currently:
However, if the set of Local Endpoints includes
server-reflexive candidates, such as those provided by STUN
(Session Traversal Utilities for NAT) [RFC8489], a Rendezvous
action will race candidates in the style of the ICE (Interactive
Connectivity Establishment) algorithm [RFC8445] to perform NAT
binding discovery and initiate a peer-to-peer connection.
...
[RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
D., Mahy, R., and P. Matthews, "Session Traversal
Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489,
February 2020,https://www.rfc-editor.org/info/rfc8489 . -->
Please update the reference, thanks!
• <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
https://www.rfc-editor.org/styleguide/part2/#inclusive_language ,
and let us know if any changes are needed. Updates of this nature
typically result in more precise language, which is helpful for
readers.
In addition, please consider whether "tradition" should be updated
for clarity (possibly "commonly used", "typical", or
"long-established"). While the NIST website
(https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1)
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone. -->
The use of “traditional” here is meant to refer to the UNIX programming
tradition; I believe this is inclusive of all networking systems programmers
using UNIX systems or those systems compatible with and/or inspired by them
(and the insight, and indeed the entirety of the TAPS work, is irrelevant to
people who are not networking systems prorgammers), so IMO this is fine to keep.
• <!-- [rfced] The following terms were used inconsistently in this
document. We chose to use the latter forms. Please let us know
any objections.
Transport Feature / transport feature (in running text)
(per usage elsewhere in this document, in the rest of this
cluster, and in RFC 8303)
Transport Service API (1 instance in Cluster 508) /
Transport Services API (per the rest of this document and the
cluster)
Transport Service System (1 instance in Cluster 508) /
Transport Services System (per the rest of this document and the
cluster) -->
These are fine, thanks.
Thank you.
RFC Editor/lb/mf
IMPORTANT
Updated 2024/11/18
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-edi...@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/rfc9621.xml
https://www.rfc-editor.org/authors/rfc9621.html
https://www.rfc-editor.org/authors/rfc9621.pdf
https://www.rfc-editor.org/authors/rfc9621.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9621-diff.html
https://www.rfc-editor.org/authors/rfc9621-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9621-xmldiff1.html
Tracking progress
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9621
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
RFC9621 (draft-ietf-taps-arch-19)
Title : Architecture and Requirements for Transport Services
Author(s) : T. Pauly, Ed., B. Trammell, Ed., A. Brunstrom, G. Fairhurst, C. S.
Perkins
WG Chair(s) : Reese Enghardt, Aaron Falk
Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini
