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.
1) <!-- [rfced] Please insert any keywords (beyond those that appear
in the
title) for use on <https://www.rfc-editor.org/search> . -->
2) <!-- [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"
3) <!-- [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]."
4) <!-- [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.
5) <!-- [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.
6) <!-- [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"
7) <!-- [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.
8) <!-- [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.
9) <!-- [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!
10) <!-- [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
11) <!-- [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).
12) <!-- [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!
13) <!-- [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!
14) <!-- [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!
15) <!-- [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!
16) <!-- [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.
17) <!-- [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
