jiebi/TextFlow huggingface dataset:
Original text:
This is necessary to allow the discovery of pledges by the registrar- agent using mDNS.  The list may be provided by administrative means or the registrar agent may get the information via an interaction <del> with the pledge, like scanning of product-serial-number information using a QR code or similar. </del>  According to RFC8995 section 5.3, the domain registrar performs the pledge authorization for bootstrapping within his domain based on the

Reviewer comments:
Included in the text. Maybe will include further text for
In 5.5.1: This kind of suggests that an Agent may also not know the serial number. But in creating the agent-signed-data, this number is required later on. Could we clarify perhaps the Agent MUST know the serial-number; e.g. in one of these ways: configured (as in quoted text above) discovered (in "standard" way using mDNS / DNS-SD first part of service instance name) discovered (in vendor-specific way e.g. RF beacons) other (in vendor-specific way, e.g. scan QR code of packaging) - maybe that's the same as category 1 from the Agent point of view.
Additional Note: figure 4 doesn't show the part where the Agent discovers the serial number of the Pledge. This was adding to the confusion. Maybe figure 4 can stay as is; this is just to clarify that at the start of Fig 4 the Agent MUST know the serial-number. So some small link is missing to get the complete picture.
I reopened as the initial point if the registrar-agent MUST know the serial number is not solved by the QR code reference. As the registrar-agent needs to know, which pledges he is bootstrapping, he needs the list of serial numbers in advance to be able to construct the agent signed data. Text proposed will be included into the pre-conditions described in section 5.5.1, In addition, the registrar-agent MUST know the product-serial-number(s) of the pledge(s) to be bootstrapped. The registrar-agent MAY be provided with the product-serial-number in different ways: configured, e.g., as a list of pledges to be bootstrapped via QR code scanning discovered by using standard approaches like mDNS as described in 5.4.2. discovered by using a vendor specific approach, e.g., RF beacons
Ok

Revised text:
This is necessary to allow the discovery of pledges by the registrar- agent using mDNS.  The list may be provided by administrative means or the registrar agent may get the information via an interaction  <ins> with the pledge.  For instance, RFC9238 describes scanning of a QR code, the product-serial-number would be initialized from the 12N B005 Product Serial Number. </ins> According to RFC8995 section 5.3, the domain registrar performs the pledge authorization for bootstrapping within his domain based on the
Original text:
the main Connection implementation that delivers events to the custom framer implementation whenever data is ready to be parsed or framed.  When a Connection establishment attempt begins, an event can be delivered to notify the framer implementation that a new Connection is being created.  Similarly, a stop event can be delivered when a

Reviewer comments:
It seems blindingly obvious to me that an implementation would need to take care of this... and this note of caution seems quite appropriate (if unnecessary... but surely it doesn't hurt).
Dynamic framer add and passthrough (last two paragraphs of section 6.1) assume synchronous operation; what happens to bytes in the send/receive buffers when the framer stack changes? There either needs to be an explicit mutex here (allowing the framer/implementation to lock the buffers at the exact point the framer change happens, not allowing any bytes to be processed while the dynamic framer decision is made), or some way to annotate in a buffer the replay point after which a dynamic reframing is necessary. Are we going to leave this up to implementors to figure out, or should we point out that here be dragons?
We should clarify that these operations within the data path of the stack should be synchronized.

Revised text:
the main Connection implementation that delivers events to the custom framer implementation whenever data is ready to be parsed or framed. <ins> The Transport Services implementation needs to ensure that all of the events and actions taken on a Message Framer are synchronized to ensure consistent behavior.  For example, some of the actions defined below (such as PrependFramer and StartPassthrough) modify how data flows in a protocol stack, and require synchronization with sending and parsing data in the Message Framer. </ins> When a Connection establishment attempt begins, an event can be delivered to notify the framer implementation that a new Connection is being created.  Similarly, a stop event can be delivered when a
Original text:
4.1.2. <del> Branch types must occur in a specific order relative to one another to avoid creating leaf nodes with invalid or incompatible settings. In the example above, it would be invalid to branch for derived endpoints (the DNS results for www.example.com) before branching between interface paths, since there are situations when the results will be different across networks due to private names or different supported IP versions.  Implementations must be careful to branch in an order that results in usable leaf nodes whenever there are multiple branch types that could be used from a single node. The order of operations for branching should be: Alternate Paths </del>  Protocol Options

Reviewer comments:
SORRY I made a PR on your PR, when I meant to leave a review comment, see 1024. .... Silly to make a PR on a PR - I added a review comment instead...
In section 4.1.4 in the impl draft, we have: "The order of operations for branching, where lower numbers are acted upon first, should be: Alternate Paths Protocol Options Derived Endpoints" However, I would say there is not really a strict ordering required. The text actually indicates that selection of the protocol is rather independent while there is usually a dependency between the interface and derived endpoint. I think this is related to my other issue about the use of the term path, because a path consists of both the local and remote endpoint and therefore there is of course a dependency. So in summary I'm not sure how useful I find this whole section as currently written...
We should conclude if anything more is needed here besides cleaning up the terminology, where Alternate Paths is not a good term - see .
Any implementation should have a consistent order of operations. This is a recommended example. Reference the arch text that says it needs to work the same way each time.
Reference ICE/HE

Revised text:
4.1.2.  <ins> Branch types ought to occur in a specific order relative to one another to avoid creating leaf nodes with invalid or incompatible settings.  In the example above, it would be invalid to branch for derived endpoints (the DNS results for www.example.com) before branching between interface paths, since there are situations when the results will be different across networks due to private names or different supported IP versions.  Implementations need to be careful to branch in a consistent order that results in usable leaf nodes whenever there are multiple branch types that could be used from a single node. This document recommends the following order of operations for branching: Network Paths </ins> Protocol Options
Original text:
highest available capacity, based on the observed maximum throughput.  Implementations process the Properties (Section 6.2 of I-D.ietf-taps- interface) in the following order: Prohibit, Require, Prefer, Avoid. If Selection Properties contain any prohibited properties, the

Reviewer comments:
Appendix B.1 lists two properties as "under discussion": Bounds on Send or Receive Rate: (PR 1036 fixes the name): this is no longer under discussion, these properties exist. Cost Preferences: this is no longer under discussion, I suppose?? We don't have this in the interface draft. So I have the impression that this should no longer be an appendix, the text on Cost Preferences should be removed, and the text on Bounds on Send and Receive Rate should be moved elsewhere, and not be mentioned as "under discussion".
LGMT

Revised text:
highest available capacity, based on the observed maximum throughput. <ins> As another example, branch sorting can also be influenced by bounds on the Send or Receive rate (Selection Properties "minSendRate" / "minRecvRate" / "maxSendRate" / "maxRecvRate"): if the application indicates a bound on the expected Send or Receive bitrate, an implementation may prefer a path that can likely provide the desired bandwidth, based on cached maximum throughput, see performance- caches.  The application may know the Send or Receive Bitrate from metadata in adaptive HTTP streaming, such as MPEG-DASH. </ins> Implementations process the Properties (Section 6.2 of I-D.ietf-taps- interface) in the following order: Prohibit, Require, Prefer, Avoid. If Selection Properties contain any prohibited properties, the
Original text:
Protocol-specific Properties MUST use the protocol acronym as the Namespace (e.g., a "tcp" Connection could support a TCP-specific <del> Transport Property, such as the user timeout value, in a protocol- specific property called "tcp.userTimeoutValue" (see tcp-uto). </del>  Vendor or implementation specific properties MUST use a string identifying the vendor or implementation as the Namespace.

Reviewer comments:
We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

Revised text:
Protocol-specific Properties MUST use the protocol acronym as the Namespace (e.g., a "tcp" Connection could support a TCP-specific  <ins> Transport Property, such as the user timeout value, in a Protocol- specific Property called "tcp.userTimeoutValue" (see tcp-uto). </ins> Vendor or implementation specific properties MUST use a string identifying the vendor or implementation as the Namespace.
Original text:
Namespaces for each of the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol- <del> numbers/protocol-numbers.xhtml) are reserved for protocol-specific </del>  Properties and MUST NOT be used for vendor or implementation-specific properties.  Avoid using any of the terms listed as keywords in the protocol numbers registry as any part of a vendor- or implementation-

Reviewer comments:
We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

Revised text:
Namespaces for each of the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol-  <ins> numbers/protocol-numbers.xhtml) are reserved for Protocol-specific </ins> Properties and MUST NOT be used for vendor or implementation-specific properties.  Avoid using any of the terms listed as keywords in the protocol numbers registry as any part of a vendor- or implementation-
Original text:
The optional "connectionProperties" parameter allows passing Transport Properties that control the behavior of the underlying <del> stream or connection to be created, e.g., protocol-specific properties to request specific stream IDs for SCTP or QUIC. </del>  Message Properties set on a Connection also apply only to that Connection.

Reviewer comments:
We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

Revised text:
The optional "connectionProperties" parameter allows passing Transport Properties that control the behavior of the underlying  <ins> stream or connection to be created, e.g., Protocol-specific Properties to request specific stream IDs for SCTP or QUIC. </ins> Message Properties set on a Connection also apply only to that Connection.
Original text:
Protocol-specific Properties are defined in a transport- and implementation-specific way to permit more specialized protocol features to be used.  Too much reliance by an application on <del> protocol-specific Properties can significantly reduce the flexibility </del>  of a transport services implementation to make appropriate selection and configuration choices.  Therefore, it is RECOMMENDED that <del> Protocol Properties are used for properties common across different protocols and that Protocol-specific Properties are only used where specific protocols or properties are necessary. </del>  The application can set and query Connection Properties on a per- Connection basis.  Connection Properties that are not read-only can

Reviewer comments:
We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

Revised text:
Protocol-specific Properties are defined in a transport- and implementation-specific way to permit more specialized protocol features to be used.  Too much reliance by an application on  <ins> Protocol-specific Properties can significantly reduce the flexibility </ins> of a transport services implementation to make appropriate selection and configuration choices.  Therefore, it is RECOMMENDED that  <ins> Protocol-specific Properties are used for properties common across different protocols and that Protocol-specific Properties are only used where specific protocols or properties are necessary. </ins> The application can set and query Connection Properties on a per- Connection basis.  Connection Properties that are not read-only can
Original text:
Message Properties can be set and queried using the Message Context: <del> These Message Properties may be generic properties or protocol- </del>  specific Properties. For MessageContexts returned by send Events (see send-events) and

Reviewer comments:
We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

Revised text:
Message Properties can be set and queried using the Message Context:  <ins> These Message Properties may be generic properties or Protocol- </ins> specific Properties. For MessageContexts returned by send Events (see send-events) and
Original text:
In the following cases, failure should be detected during pre- establishment: <del> A request by an application for Protocol Properties that cannot be </del>  satisfied by any of the available protocols.  For example, if an application requires "perMsgReliability", but no such feature is available in any protocol on the host running the transport system this should result in an error, e.g., when SCTP is not supported by the operating system. <del> A request by an application for Protocol Properties that are in conflict with each other, i.e., the required and prohibited properties cannot be satisfied by the same protocol.  For example, if an application prohibits "reliability" but then requires </del>  "perMsgReliability", this mismatch should result in an error. To avoid allocating resources that are not finally needed, it is

Reviewer comments:
We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

Revised text:
In the following cases, failure should be detected during pre- establishment:  <ins> A request by an application for properties that cannot be </ins> satisfied by any of the available protocols.  For example, if an application requires "perMsgReliability", but no such feature is available in any protocol on the host running the transport system this should result in an error, e.g., when SCTP is not supported by the operating system.  <ins> A request by an application for properties that are in conflict with each other, i.e., the required and prohibited properties cannot be satisfied by the same protocol.  For example, if an application prohibits "reliability" but then requires </ins> "perMsgReliability", this mismatch should result in an error. To avoid allocating resources that are not finally needed, it is
Original text:
implementation should store the properties in storage common to all protocols, and notify all protocol instances in the Protocol Stack whenever the properties have been modified by the application.  For <del> protocol-specfic properties, such as the User Timeout that applies to TCP, the Transport Services implementation only needs to update the relevant protocol instance. </del>  If an error is encountered in setting a property (for example, if the application tries to set a TCP-specific property on a Connection that

Reviewer comments:
We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

Revised text:
implementation should store the properties in storage common to all protocols, and notify all protocol instances in the Protocol Stack whenever the properties have been modified by the application.  For  <ins> Protocol-specific Properties, such as the User Timeout that applies to TCP, the Transport Services implementation only needs to update the relevant protocol instance. </ins> If an error is encountered in setting a property (for example, if the application tries to set a TCP-specific property on a Connection that
Original text:
SHOULD be made accessible through a unified set of calls using the Transport Services API.  As a baseline, any Transport Services API SHOULD allow access to the minimal set of features offered by <del> transport protocols RFC8923. </del>  An application can specify constraints and preferences for the protocols, features, and network interfaces it will use via

Reviewer comments:
URL Assuming there would be more protocols in the future and the minset functionalities will expand via extension or amendments. It would important to indicate if this architecture should is also extensible or it only supports on the minimum set referred. Definitely we haven't seen the future yet, but it would be important to express if we have considered such expansion of minimum functionalities.
To me, the current spec is based on minset that describes the common functions. So, the addition I would expect here is to say that there can be extensions and protocol-specific features.
I expect that if a common feature is added to the minset, then the architecture and API surface would also be extended to match.
LGTM modulo a nit

Revised text:
SHOULD be made accessible through a unified set of calls using the Transport Services API.  As a baseline, any Transport Services API SHOULD allow access to the minimal set of features offered by  <ins> transport protocols RFC8923.  If that minimal set is updated or expanded in the future, the Transport Services API ought to be extended to match. </ins> An application can specify constraints and preferences for the protocols, features, and network interfaces it will use via