Dear RFC Editor, dear all, Please find below the answers to the questions regarding draft-ietf-taps-impl. I hope that my co-authors react in case they disagree with something - and I hope that sharing this in that way does not produce too much email traffic at this point. I tried to strike a balance between involving others offline (by first copy+pasting this into a Google Docs document and working there), and giving the answers sooner rather than later - so at least the number of further emails should be reduced somewhat (I hope).
Best regards, Michael Welzl ============== 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. --> MW: Happy Eyeballs, Transport Selection 2) <!-- [rfced] We are having trouble understanding "finally" - perhaps "finally" can be removed? Otherwise, perhaps "ultimately" would be more clear? Original: To avoid allocating resources that are not finally needed, it is important that configuration-time errors fail as early as possible. --> MW: Yes, it can be removed and doing so makes it clearer. So, I suggest: NEW: To avoid allocating resources that are not needed, it is important that configuration-time errors fail as early as possible. 3) <!-- [rfced] We are having trouble parsing "only after waiting for failures". Please consider whether the suggested text conveys the intended meaning. Original: These attempts are usually staggered, starting each next option after a delay, but they can also be performed in parallel or only after waiting for failures. Perhaps: These attempts are usually staggered, with each next option starting after a delay; however, they can also be performed in parallel or after failures occur. → MW: yes, thank you. 4) <!--[rfced] We have attempted to break this long sentence up using a list for the ease of the reader. Please review and let us know if further updates are necessary (particularly, is the second bullet also talking about cases of a hostname and port?): Original: However, each step may also differ depending on the requirements of the connection: if the Endpoint Identifier is a hostname and port, then there may be multiple resolved addresses that are available; there may also be multiple paths available, (in this case using an interface other than the default system interface); and some protocols may not need any transport handshake to be considered "established" (such as UDP), while other connections may utilize layered protocol handshakes, such as TLS over TCP. Current: However, each step may also differ depending on the requirements of the connection: * if the Endpoint Identifier is a hostname and port, then there may be multiple resolved addresses that are available; * there may also be multiple paths available (in this case using an interface other than the default system interface); and * some protocols may not need any transport handshake to be considered "established" (such as UDP), while other connections may utilize layered protocol handshakes, such as TLS over TCP. --> MW: This update is correct, and indeed much better, many thanks. 5) <!--[rfced] Can we update this list as follows? Original: The hostname resolves to a single IPv4 address on the Wi-Fi network, and resolves to the same IPv4 address on the LTE network, as well as a single IPv6 address. Perhaps: The hostname resolves to a single IPv4 address on the Wi-Fi network, to the same IPv4 address on the LTE network, and to a single IPv6 address. --> MW: yes. 6) <!-- [rfced] The following extends beyond the 72 character margin. Please review and let us know how the artwork may be adjusted. FYI: This is a 72 character ruler: 123456789012345678901234567890123456789012345678901234567890123456789012 A) Section 4: Aggregate [Endpoint Identifier: www.example.com:443] [Interface: Any] [Protocol: TCP] |-> [Endpoint Identifier: [2001:db8:23::1]:443] [Interface: Wi-Fi] [Protocol: TCP] |-> [Endpoint Identifier: 192.0.2.1:443] [Interface: LTE] [Protocol: TCP] |-> [Endpoint Identifier: [2001:db8:42::1]:443] [Interface: LTE] [Protocol: TCP] MW: NEW: Aggregate [EId: example.com:443] [Interface: Any] [Protocol: TCP] |-> [EId: [3fff:23::1]:443] [Interface: Wi-Fi] [Protocol: TCP] |-> [EId: 192.0.2.1:443] [Interface: LTE] [Protocol: TCP] |-> [EId: [3fff:42::1]:443] [Interface: LTE] [Protocol: TCP] NEW - shown in "Courier New” font: Aggregate [EId: example.com:443 <http://www.example.com:443/>] [Interface: Any] [Protocol: TCP] |-> [EId: [3fff:23::1]:443] [Interface: Wi-Fi] [Protocol: TCP] |-> [EId: 192.0.2.1:443] [Interface: LTE] [Protocol: TCP] |-> [EId: [3fff:42::1]:443] [Interface: LTE] [Protocol: TCP] Also, please replace the sentence just above this: OLD: The aggregate set of connection establishment options can be viewed as follows: NEW: The aggregate set of connection establishment options can be viewed as follows, with the Endpoint Identifier abbreviated as “EId”: B) Section 4.1: || +==============================+ | www.example.com:443/any path | +==============================+ // \\ +===========================+ +===========================+ | www.example.com:443/Wi-Fi | | www.example.com:443/LTE | +===========================+ +===========================+ || // \\ +========================+ +=====================+ +======================+ | [3fff:23::1]:443/Wi-Fi | | 192.0.2.1:443/LTE | | [3fff:42::1]:443/LTE | +========================+ +=====================+ +======================+ MW: NEW: || +============================+ www.example.com:443/any path +============================+ // \\ +=========================+ +=======================+ www.example.com:443/Wi-Fi www.example.com:443/LTE +=========================+ +=======================+ || // \\ +======================+ +=================+ +====================+ [3fff:23::1]:443/Wi-Fi 192.0.2.1:443/LTE [3fff:42::1]:443/LTE +======================+ +=================+ +====================+ NEW - shown in "Courier New” font: || +============================+ www.example.com:443/any <http://www.example.com:443/any> path +============================+ // \\ +=========================+ +=======================+ www.example.com:443/Wi-Fi <http://www.example.com:443/Wi-Fi> www.example.com:443/LTE <http://www.example.com:443/LTE> +=========================+ +=======================+ || // \\ +======================+ +=================+ +====================+ [3fff:23::1]:443/Wi-Fi 192.0.2.1:443/LTE [3fff:42::1]:443/LTE +======================+ +=================+ +====================+ C) Section 6.3: MessageFramer.AdvanceReceiveCursor(connection, length) MessageFramer.DeliverAndAdvanceReceiveCursor(connection, messageContext, length, endOfMessage) MessageFramer.Deliver(connection, messageContext, messageData, endOfMessage) --> MW: for the last entry, entitled C) Section 6.3: OLD: C) Section 6.3: MessageFramer.AdvanceReceiveCursor(connection, length) MessageFramer.DeliverAndAdvanceReceiveCursor(connection, messageContext, length, endOfMessage) MessageFramer.Deliver(connection, messageContext, messageData, endOfMessage) NEW: C) Section 6.3: MessageFramer.AdvanceReceiveCursor(connection, length) MessageFramer.DeliverAndAdvanceReceiveCursor(connection, messageContext, length, endOfMessage) MessageFramer.Deliver(connection, messageContext, messageData, endOfMessage) 7) <!--[rfced] We have updated to match the way characters appear in RFC-to-be 9622. Please note that RFC-to-be 9622 enclosing these types of characters in tt tags. Should the same convention be applied here? Original: That child node will be uniquely identified by concatenating its integer to its parent's identifier with a dot in between, such as "1.1" and "1.2". and In Protocol Stacks, the layers are separated by '/' and ordered with the protocol closest to the application first. Current: That child node will be uniquely identified by concatenating its integer to its parent's identifier with a dot character (".") in between, such as "1.1" and "1.2". and In Protocol Stacks, the layers are separated by a slash character ("/") and ordered with the protocol closest to the application first. --> MW: yes, for all of the cases above. 8) <!--[rfced] Might it be helpful to the reader to list the three types of branching here? Original: 4.1.1. Branch Types There are three types of branching from a parent node into one or more child nodes. Any parent node of the tree must only use one type of branching. 4.1.1.1. Derived Endpoints --> MW: yes. Suggestion: NEW: There are three types of branching from a parent node into one or more child nodes: Derived Endpoints, Network Paths and Protocol Options. Any parent node of the tree must only use one type of branching. 9) <!--[rfced] Please review the multiple uses of "first" in this sentence about ordering. It may be helpful to the reader to clarify. Original: ..branches will be first sorted accord to path selection, with WiFi attempted first. Then, branches with SCTP will be attempted first within their subtree according to the properties influencing protocol selection. --> MW: I suggest: NEW: ..branches will be first sorted accord to path selection, with WiFi attempted as the first path. Then, branches with SCTP will be attempted within their subtree according to the properties influencing protocol selection. 10) <!-- [rfced] May we update this text for clarity? Original: - Low Latency/Non-Interactive: Prefer paths with a low expected Round Trip Time, but can tolerate delay variation; Perhaps: - Low Latency/Non-Interactive: Prefer paths with a low expected Round Trip Time (RTT) that can tolerate delay variation; --> MW: I suggest instead: NEW: - Low Latency/Non-Interactive: Prefer paths with a low expected Round Trip Time (RTT) and possible delay variation; 11) <!--[rfced] Are the terms in the following sentence related to those mentioned two paragraphs above (from RFC-to-be 9622)? If so, should they take the same form and/or should avoidance be added? Original: This list is determined by the requirements, prohibitions, and preferences of the application as specified in the Selection Properties. Two paragraphs before: Original: Implementations process the Properties (Section 6.2 of [I-D.ietf-taps-interface]) in the following order: Prohibit, Require, Prefer, Avoid. A few sentences later includes "avoid": Original: Finally, it should order the branches according to the preferred properties, and finally use any avoided properties as a tiebreaker. --> MW: yes these terms are related to the ones from RFC-to-be 9622, and I agree that avoidance should be added (I’m not sure “the same form” is necessary). Suggestion: NEW: This list is determined by the requirements, prohibitions, preferences and avoidances of the application as specified in the Selection Properties. 12) <!--[rfced] Is "to rendezvous" the rendezvous server? We are a bit confused by the second part of the sentence. If our suggestion does not capture your intent, please rephrase. Original: It will involve a directory service, and can require communication with the Remote Endpoint to rendezvous and exchange peer addresses. Perhaps: It will involve a directory service and can require communication between the Remote Endpoint and a rendezvous server as well as the exchange of peer addresses. --> MW: yes. 13) <!-- [rfced] For clarity, may we update "or else" to "otherwise" here? Original: The process of connection establishment completes when one leaf node of the tree has successfully completed negotiation with the Remote Endpoint, or else all nodes of the tree have failed to connect. Perhaps: The process of connection establishment completes when one leaf node of the tree has successfully completed negotiation with the Remote Endpoint; otherwise, all nodes of the tree have failed to connect. --> MW: I suggest, instead: NEW: The process of connection establishment completes when one leaf node of the tree has successfully completed negotiation with the Remote Endpoint, or when all nodes of the tree have failed to connect. 14) <!-- [rfced] For readability, may we update the text as follows? Original: When the Initiate action is called without any Messages being sent at the same time, depending on the protocols involved, it is not guaranteed that the Remote Endpoint will be notified of this, and hence a passive endpoint's application may not receive a ConnectionReceived event until it receives the first Message on the new Connection. Perhaps: Depending on the protocols involved, there is no guarantee that the Remote Endpoint will be notified when the Initiate action is called without any Messages being sent at the same time. Therefore, a passive endpoint's application may not receive a ConnectionReceived event until it receives the first Message on the new Connection. --> MW: yes, thank you! 15) <!-- [rfced] We are having trouble parsing this sentence. Are words missing? Or perhaps the Connections are to "be multiplexed and belong to the same Connection Group" or that the "multiplexed Connections belong to the same Connection Group"? Original: Multiplexing several Connections over a single underlying transport connection requires that the Connections to be multiplexed belong to the same Connection Group (as is indicated by the application using the Clone action). --> MW: the latter, thank you. Hence, I suggest: NEW: Multiplexing several Connections over a single underlying transport connection requires that the multiplexed Connections belong to the same Connection Group (as is indicated by the application using the Clone action). 16) <!--[rfced] The double use of "this" seems strange in these sentences. Please rephrase. Original: when this is false, this disables the requirement of in-order-delivery for protocols that support configurable ordering. and MW: NEW: when this is false, it disables the requirement of in-order-delivery for protocols that support configurable ordering. Original: when this is true, this means that the Message can be used by a transport mechanism that might deliver it multiple times... MW: NEW: when this is true, it means that the Message can be used by a transport mechanism that might deliver it multiple times... and Original: when this is true, this means that the sender will not send any further Messages. MW: NEW: when this is true, it means that the sender will not send any further Messages. → MW: I think this can generally be solved here by replacing the second “this” with “it”, as I have done with my in-line suggestions above. 17) <!-- [rfced] For readability, please consider whether the suggested text correctly conveys the intended meaning. Original: If a Connection finishes before a requested Receive action can be satisfied, the Transport Services system should deliver any partial Message content outstanding, or if none is available, an indication that there will be no more received Messages. Perhaps: If a Connection finishes before a requested Receive action can be satisfied, the Transport Services system should deliver any outstanding partial Message content; if none is available, the system should indicate that there will be no additional received Messages. --> MW: yes, this is fine (and, of course, better); thank you. 18) <!-- [rfced] For clarity, may we replace "yet" with "but the data will be"? Original: In effect, each leaf node will send the same early application data, yet encoded (encrypted) differently on the wire. Perhaps: In effect, each leaf node will send the same early application data, but the data will be encoded (encrypted) differently on the wire. --> MW: yes. 19) <!--[rfced] Looking at the following text, is this defining what Message Framer means? If so, please review the fact that the paragraph also starts out with a definition. Please let us know what revisions may be needed. Original: The Message Framer refers to the object or function within the main Connection implementation that delivers events to the custom framer implementation whenever data is ready to be parsed or framed. The paragraph starts with: A Message Framer is primarily defined by the code that handles events for a framer implementation, specifically how it handles inbound and outbound data parsing. --> MW: No, this “refers to” is meant in a technical sense. To make this clearer, I suggest: NEW: The Message Framer holds a reference to the object or function within the main Connection implementation that delivers events to the custom framer implementation whenever data is ready to be parsed or framed. 20) <!-- [rfced] Please confirm that "stop event" should be "<tt>Stop</tt> event". Original (no caps or <tt>): Similarly, a stop event can be delivered when a Connection is being torn down. --> MW: yes. 21) <!-- [rfced] Does "at first" mean "initially"? Original: In such cases, a Message Framer implementation can intercept sending and receiving of Messages at first, but then indicate that no more processing is needed. Perhaps: In such cases, a Message Framer implementation can initially intercept Messages being sent and received and subsequently indicate that no further processing is needed. --> MW: yes. 22) <!-- [rfced] Section 7: We note that this document uses "keepalives" and refers to a "keepAlive" property. The other documents seem to use "keep-alive" to refer to packets. Please review the use of "keepalives" and let us know if any updates are needed. Original: For example, if the application has requested to use keepalives with the keepAlive property, and the Protocol Stack contains both HTTP/2 and TCP, the HTTP/2 protocol can choose to enable its own keepalives to satisfy the application request, and disable TCP-level keepalives. --> MW: the name of the “keepAlive” property is fine, as it is consistent with RFC-to-be-9622. The “keepalives” should indeed be “keep-alives” for style consistency. So, I suggest: NEW: For example, if the application has requested to use keep-alives with the keepAlive property, and the Protocol Stack contains both HTTP/2 and TCP, the HTTP/2 protocol can choose to enable its own keep-alives to satisfy the application request, and disable TCP-level keep-alives. 23) <!-- [rfced] We are having trouble parsing the text following "is still available or". Please review and let us know how the text may be clarified. Original: A protocol can then establish new subflows over new paths while an active path is still available or, if migration is supported, also after a break has been detected, and should attempt to tear down subflows over paths that are no longer used. Perhaps (but this leaves out "after a break has been detected"): A protocol can then establish new subflows over new paths while an active path is still available, or it should attempt to tear down subflows over paths that are no longer used if migration is supported. --> MW: This proposal changes the semantics. Instead, “if migration is supported” is not strictly necessary to say here (the point is that only protocols with migration support can do this). I think it becomes clearer with this suggested fix: NEW: A protocol can then establish new subflows over new paths while an active path is still available or after a break has been detected, and should attempt to tear down subflows over paths that are no longer used. 24) <!-- [rfced] There is no Appendix D in draft-ietf-taps-interface <https://www.ietf.org/archive/id/draft-ietf-taps-impl-18.html#I-D.ietf-taps-interface>. We see "callbacks," "fallback," and "backpressure," but we don't see "backtrack", "back track", or "back-track." Please review and let us know what section is intended. Original: This back-tracking method applies to all elements of [RFC8923] (see appendix D of [I-D.ietf-taps-interface]): they are listed in appendix A of [RFC8923] with an implementation hint in the same style, pointing back to Section 4 of [RFC8303]. --> MW: oops! A great catch. This is meant to be about appendix C, and the term “back-tracking method” is just confusing and not needed here; “This” is enough here. So, I suggest: NEW: This applies to all elements of [RFC8923] (see appendix C of [I-D.ietf-taps-interface]): they are listed in appendix A of [RFC8923] with an implementation hint in the same style, pointing back to Section 4 of [RFC8303]. 25) <!--[rfced] This text may have gotten garbled along the way (see "for a multicast group to for a multicast control bus"). Please rephrase. Original: For example, one Connection might be opened for a multicast group to for a multicast control bus, and another application later opens a separate Connection to the same group to send signals to and/or receive signals from the common bus. --> MW: NEW: For example, one Connection might be opened for a multicast group used for a shared control bus, and another application later opens a separate Connection to the same multicast group to send signals to and/or receive signals from the common bus. 26) <!-- [rfced] Section 10.6: We find "requirements as follows" and the "following explanation" in the subsequent sentence confusing - what directly follows the paragraph? Does the "requirements as follows" refer to following paragraph that starts with "Stream mapping requires..."? If yes, should this text (all of the text until "Initiate:") be indented under "Connection Object"? Original: Connection Object: Connection objects can be mapped to an SCTP association or a stream in an SCTP association. Mapping Connection objects to SCTP streams is called "stream mapping" and has additional requirements as follows. The following explanation assumes a client-server communication model. Stream mapping requires ... --> MW: yes, it refers to the following text until “Initiate:”, and yes, please indent all of this text. 27) <!-- [rfced] Please confirm that "stream id" (lowercase "id") is correct, as we see the following (using "stream IDs") in draft-ietf-taps-interface (RFC-to-be 9622): The optional connectionProperties parameter allows passing Transport Properties that control the behavior of the underlying stream or connection to be created, e.g., Protocol-specific Properties to request specific stream IDs for SCTP or QUIC. --> MW: lower case “stream id” is correct, since this text refers to SCTP where “stream id” is consistent with RFC 8303 as well as the main SCTP specification in RFC 9260. The text in draft-ietf-taps-interface (RFC-to-be 9622) refers to both SCTP and QUIC. In QUIC, the term is indeed called “stream ID”. The most precise solution would be to update the text in draft-ietf-taps-interface (RFC-to-be 9622) as follows: OLD: The optional connectionProperties parameter allows passing Transport Properties that control the behavior of the underlying stream or connection to be created, e.g., Protocol-specific Properties to request specific stream IDs for SCTP or QUIC. NEW: The optional connectionProperties parameter allows passing Transport Properties that control the behavior of the underlying stream or connection to be created, e.g., Protocol-specific Properties to request specific stream ids for SCTP or stream IDs for QUIC. I am, however, in favor of leaving this as it is, in both documents. The most important point of draft-ietf-taps-interface (RFC-to-be 9622) is to make applications independent of the underlying protocols – and so, it’s good to show the conceptually equivalent “stream id” of SCTP and “stream ID” of QUIC as only one thing, even with the same name. I would prefer to just accept this capitalization mismatch (although I have no very strong opinion about whether to update the text in draft-ietf-taps-interface (RFC-to-be 9622) as above). 28) <!-- [rfced] We wonder if "might block" should be "will block" because "without risking" implies that blocking should not happen? Or is the intent to say the risk of blocking is reduced? Original: This allows a sender to schedule transmissions between multiple streams without risking that transmission of a large message on one stream might block transmissions on other streams for a long time. --> MW: I agree, “will block” is better here, thank you. 29) <!-- [rfced] Does "growing order" mean "ascending order"? Original: All additional Connections are assigned to unused stream ids in growing order. --> MW: yes. 30) <!-- [rfced] Will "fire" be clear for readers? Perhaps "be initiated" or "be triggered" would be more accurate? Original: At the peer, the event RESET_STREAM-EVENT.SCTP will fire, which the peer must answer by issuing RESET_STREAM.SCTP too. Perhaps: At the peer, the event RESET_STREAM-EVENT.SCTP will be triggered, and the peer must respond by also issuing a RESET_STREAM.SCTP. --> MW: yes, this suggestion is good, thank you. 31) <!-- [rfced] For readability, may we update the sentence as follows? It is difficult to locate the information in RFC 9621 otherwise. Original: The Security Considerations of the Transport Services Architecture [I-D.ietf-taps-arch] forbids gathering and racing with Protocol Stacks that do not have equivalent security properties. Perhaps: As discussed in Sections 3.3 and 6 of [RFC9621], gathering and racing with Protocol Stacks that do not have equivalent security properties are forbidden. --> MW: Thank you, the update is fine - but the word “forbidden” is actually too strict (the definition in Section 3.3 of [I-D.ietf-taps-arch] uses SHOULD). I have also confirmed this offline with the authors of [I-D.ietf-taps-arch]. Accordingly, please use the following: NEW: As discussed in Sections 3.3 and 6 of [RFC9621], gathering and racing with Protocol Stacks that do not have equivalent security properties ought not to be attempted. 32) <!-- [rfced] Please note that we have updated the following references. Please let us know if any corrections are needed. [NEAT-flow-mapping] updated based on the information found at <https://ieeexplore.ieee.org/document/8264876>. [TCP-COUPLING] updated based on the information found at <https://ieeexplore.ieee.org/document/8406887>. --> MW: this is fine, thank you! 33) <!--[rfced] The following RFCs have been obsoleted. We will update to point the reader to the one on the right unless we hear objection. RFC 5389 becomes RFC 8489 RFC 5766 becomes RFC 8656 RFC 7230 becomes RFC 9110 RFC 7540 becomes RFC 9113 --> MW: this is fine, thank you. 34) <!-- [rfced] Appendix C: The URL for the NEAT project (https://www.neat-project.org) does not appear to be working ("Unable to connect"). Please let us know how this should be updated. Original: - NEAT project: https://www.neat-project.org --> MW: Please remove this line. 36) <!--[rfced] We had the following questions/comments related to abbreviation use: a) Please note that we have expanded abbreviations in this document. Please review and let us know any objections. Examples include: Differentiated Services Code Point (DSCP) Multipath TCP (MPTCP) Stream Control Transmission Protocol (SCTP) b) We also introduced these abbreviations where the expansions were first used because the abbreviations were used later in the document. TFO DF TAPS c) Please also review the use of TAPS in the running header (this was removed form the short title of RFC-to-be 9622). Please let us know if it should also be changed for this document. Note that it does appear in the body of this document and we have now expanded it there. --> MW: All of the above is good; please update the running header though: OLD: TAPS Implementation NEW: Transport Services Implementation By the way, it would be good to do a similar update of RFC 9621-to-be. I have informed the authors of this document to consider this and tell you. 37) <!--[rfced] Please review any uses of the slash character like the following and let us know if "and", "or", or "and/or" would be clearer for the reader. Original: ...which serves to simplify the local send/receive functions and to filter the traffic for the specified addresses and ports... --> MW: This seems to be clear enough as it is. 38) <!-- [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. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. In addition, please consider whether "traditional" (Section 4.1.1) should be updated for clarity. While the NIST website <https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#ta ble1> indicates that this term is potentially biased, it is also ambiguous. "Tradition" is a subjective term, as it is not the same for everyone. Original: When trying to connect to a hostname Endpoint Identifer on a traditional IP network, the implementation should send all applicable DNS queries. Note that the resolution in RFC-to-be 9622 was to simily delete "traditional". --> MW: Done, I checked the Style Guide, but could not see anything that needs changing. I agree about “traditional”, and suggest to remove it also here. So: OLD: When trying to connect to a hostname Endpoint Identifier on a traditional IP network, the implementation should send all applicable DNS queries. NEW: When trying to connect to a hostname Endpoint Identifier on an IP network, the implementation should send all applicable DNS queries. (a typo was introduced in the quoted text above (“Identifer” instead of “Identifier”). This is correct as “Identifier” in the document.) Thank you. RFC Editor/sg/mf *****IMPORTANT***** Updated 2024/11/25 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/rfc9623.xml https://www.rfc-editor.org/authors/rfc9623.html https://www.rfc-editor.org/authors/rfc9623.pdf https://www.rfc-editor.org/authors/rfc9623.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9623-diff.html https://www.rfc-editor.org/authors/rfc9623-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9623-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9623 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9623 (draft-ietf-taps-impl-18) Title : Implementing Interfaces to Transport Services Author(s) : A. Brunstrom, Ed., T. Pauly, Ed., R. Enghardt, P. Tiesel, M. Welzl WG Chair(s) : Reese Enghardt, Aaron Falk Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
