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:
1. Regarding the use of <tt>:
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.
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:
1.
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.
2.
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.
2. 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)
[email protected] wrote:
Greetings, all,
Answers to editor questions inline, below.
On 19 Nov 2024, at 00:29, [email protected] 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
*
[email protected] (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).
*
[email protected], 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,
[email protected] 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
