jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-taps-interface

Commentary: PTAL 
 sec 5.2.12 Using temporary local addresses may break various mechanisms that prove address ownership ( e.g QUIC resumption tokens ) and therefore impair performance as the client has to re - verify its address . 
 The default is to use a temporary address for client local address ; and to not use it for a server local address . This is the same as most socket APIs . What are you suggesting in the text , 
 right , a QUIC resumption token will generally contain the client 's IP address so that future connections no longer have to go through Retry and anti - amplification mechanisms , which reduce throughput . so IIUC 5.2.12 could say something like " Clients that use temporary local addresses might invalidate server - provided tokens that validate the client 's IP addresses ( e.g.  8.1.3 of quic - transport ) , increasing latency . " 
 Add a one - sentence warning that using a temporary address has a potential performance impact on resumption . 
 Do we wish to refer to RFC 7721 ? 
 This looks pretty close ... check these words and submit .
Paragraph (version A):
This property allows the application to express a preference for the
use of temporary local addresses, sometimes called "privacy"
addresses RFC4941.  Temporary addresses are generally used to prevent
linking connections over time when a stable address, sometimes called
"permanent" address, is not needed.  Note that if an application
Requires the use of temporary addresses, the resulting Connection
cannot use IPv4, because temporary addresses do not exist in IPv4.
Paragraph (version B):
This property allows the application to express a preference for the
use of temporary local addresses, sometimes called "privacy"
addresses RFC4941.  Temporary addresses are generally used to prevent
linking connections over time when a stable address, sometimes called
"permanent" address, is not needed.  There are some caveats to note
when specifying this property.  First, if an application Requires the
use of temporary addresses, the resulting Connection cannot use IPv4,
because temporary addresses do not exist in IPv4.  Second, temporary
local addresses might involve trading off privacy for performance.
For instance, temporary addresses can interfere with resumption
mechanisms that some protocols rely on to reduce initial latency.
Draft: draft-ietf-taps-interface

Commentary: sec 4.2.2 " implementations MUST provide a method for the application to determine the entire set of possible values for each property . " Is this meant to be a requirement for a machine - readable API for learning the enum , or merely a requirement for documentation ? i.e. is it satisfied if the values are in the man page or comments of the C header file ? 
 As a by - note , is n't this a great place to use " REQUIRED " and say whether it is required to specify or required to support :-) . 
 Proposal : Just remove " however , implementations MUST provide a method for the application to determine the entire set of possible values for each property . " This is too implementation- and language- specific .
Paragraph (version A):
Enumeration: can take one value of a finite set of values,
dependent on the property itself.  The representation is
implementation dependent; however, implementations MUST provide a
method for the application to determine the entire set of possible
values for each property.
Paragraph (version B):
Enumeration: can take one value of a finite set of values,
dependent on the property itself.  The representation is
implementation dependent.
Draft: draft-ietf-taps-impl

Commentary: Removed phrasing that implies 0 - RTT data is just one packet and a reference to the Maximum Message Size with Connection Establishment property . Added a sentence on how / when an implementation can set this property . 
 The opening para reads to me like there is just one first packet . ... or is this actually more than one packets before the handshake complete ? 
 It is one packet for TCP , but it can be more for QUIC , TLS 1.3 ( etc ) 
 Reference Connection Property " Maximum Message Size Concurrent with Connection Establishment " 
 Seems like a useful addition that resolves my issue .
Paragraph (version A):
Several protocols allow sending higher-level protocol or application
data within the first packet of their protocol establishment, such as
TCP Fast Open RFC7413 and TLS 1.3 RFC8446.  This approach is referred
to as sending Zero-RTT (0-RTT) data.  This is a desirable property,
but poses challenges to an implementation that uses racing during
connection establishment.
Paragraph (version B):
Several protocols allow sending higher-level protocol or application
data during their protocol establishment, such as TCP Fast Open
RFC7413 and TLS 1.3 RFC8446.  This approach is referred to as sending
Zero-RTT (0-RTT) data.  This is a desirable property, but poses
challenges to an implementation that uses racing during connection
establishment.
Paragraph (version B):
The amount of data that can be sent as 0-RTT data varies by protocol
and can be queried by the application using the "Maximum Message Size
Concurrent with Connection Establishment" Connection Property.  An
implementation can set this property according to the protocols that
it will race based on the given Selection Properties when the
application requests to establish a connection.
Draft: draft-ietf-taps-interface

Commentary: Get a better / more formal explanation of Interactive mode for multipath based on our experience with  , etc . 
 Proposal from   : The connection should attempt to minimize the latency for interactive traffic patterns by transmitting data across multiple paths . The goal of minimizing the latency will be balanced against the cost fo each of these paths , meaning that depending on the cost of the lower latency path the scheduling might choose to use a higher latency path . Finally , the scheduling of the traffic can be done such that data may be transmitted on multiple paths in parallel to achieve the lowest latency possible . 
 Thanks for following up on this one . LGTM
Paragraph (version A):
The connection should attempt to use multiple paths in parallel in
order to minimize loss and delay.  The actual strategy is
implementation specific.
Paragraph (version B):
The connection should attempt to minimize the latency for
interactive traffic patterns by transmitting data across multiple
paths when it is beneficial to do so.  The goal of minimizing the
latency will be balanced against the cost of each of these paths,
meaning that depending on the cost of the lower-latency path, the
scheduling might choose to use a higher-latency path.  Traffic can
be scheduled such that data may be transmitted on multiple paths
in parallel to achieve the lowest latency possible.  The specific
scheduling algorithm is implementation-specific.
Draft: draft-ietf-taps-impl

Commentary: Opening this to follow up on a comment by on that is now closed . " Simultaneous " and " Staggered " would be better names than " Immediate " and " Delayed " . Just from these terms , I would normally think that " Immediate " means to start racing right away , whereas " Delayed " means that nothing would happen for some time . So these two terms are slightly misleading in my opinion . ) 
 I agree this would be an improvement . 
 LGTM ( of course :-) ) Thanks , looks good !
Paragraph (version A):
Each approach is appropriate in different use-cases and branch types.
However, to avoid consuming unnecessary network resources,
implementations should not use immediate racing as a default
approach.
Paragraph (version B):
Each approach is appropriate in different use-cases and branch types.
However, to avoid consuming unnecessary network resources,
implementations should not use simultaneous racing as a default
approach.
Paragraph (version A):
Immediate racing is when multiple alternate branches are started
without waiting for any one branch to make progress before starting
the next alternative.  This means the attempts are effectively
simultaneous.  Immediate racing should be avoided by implementations,
since it consumes extra network resources and establishes state that
might not be used.
Paragraph (version A):
Delayed racing can be used whenever a single node of the tree has
multiple child nodes.  Based on the order determined when building
the tree, the first child node will be initiated immediately,
followed by the next child node after some delay.  Once that second
child node is initiated, the third child node (if present) will begin
after another delay, and so on until all child nodes have been
initiated, or one of the child nodes successfully completes its
negotiation.
Paragraph (version B):
Simultaneous racing is when multiple alternate branches are started
without waiting for any one branch to make progress before starting
the next alternative.  This means the attempts are effectively
simultaneous.  Simultaneous racing should be avoided by
implementations, since it consumes extra network resources and
establishes state that might not be used.
Paragraph (version B):
Staggered racing can be used whenever a single node of the tree has
multiple child nodes.  Based on the order determined when building
the tree, the first child node will be initiated immediately,
followed by the next child node after some delay.  Once that second
child node is initiated, the third child node (if present) will begin
after another delay, and so on until all child nodes have been
initiated, or one of the child nodes successfully completes its
negotiation.
Paragraph (version A):
Delayed racing attempts occur in parallel.  Implementations should
not terminate an earlier child connection attempt upon starting a
secondary child.
Paragraph (version B):
Staggered racing attempts occur in parallel.  Implementations should
not terminate an earlier child connection attempt upon starting a
secondary child.
Draft: draft-ietf-taps-interface

Commentary: Updates PR to remove reference to lower - case in namespaces corresponding to IANA protocol names . Express that strict adherence to the doc 's naming convention is not required , but that symbols in different languages should be visually similar . 
 Last minute PR
Paragraph (version A):
Making code of different TAPS implementations look similar.
Paragraph (version B):
Making code of different TAPS implementations look similar.  While
individual programming languages may preclude strict adherence to
the aforementioned naming convention (for instance, by prohibiting
the use of hyphens in symbols), users interacting with multiple
implementations will still benefit from the consistency resulting
from the use of visually similar symbols.
Paragraph (version A):
Namespaces for each of the keywords provided in the IANA protocol
numbers registry (see https://www.iana.org/assignments/protocol-
numbers/protocol-numbers.xhtml), translated to lower-case and with
characters other than letters, numbers, and hyphens deleted, are
reserved for Protocol Specific Properties and MUST not be used for
vendor or implementation-specific properties.
Paragraph (version B):
Namespaces for each of the keywords provided in the IANA protocol
numbers registry (see https://www.iana.org/assignments/protocol-
numbers/protocol-numbers.xhtml), reformatted where necessary to
conform to an implementation's naming conventions, are reserved for
Protocol Specific Properties and MUST not be used for vendor or
implementation-specific properties.
Draft: draft-ietf-taps-impl

Commentary: In the implementation draft section 5.1.3 says that there should be an interface for the application to indicate batch sending . Section 7.7 specifies such an interface . Should the section in the implementation draft be updated or removed ? 
 I think it should be removed . Mainly , it points out that batching reduces overhead , which is also stated in the API draft in section 7.7 . 
 Perhaps it is still important for the implementation to know that it needs to support batching sends though ? I would suggest adjusting the text so it reads from the implementations perspective . Something like 
 I agree ; this is a nice text proposal . PR replaces the current text with your proposed one .
Paragraph (version A):
Since sending a Message may involve a context switch between the
application and the transport system, sending patterns that involve
multiple small Messages can incur high overhead if each needs to be
enqueued separately.  To avoid this, the application should have a
way to indicate a batch of Send actions, during which time the
implementation will hold off on processing Messages until the batch
is complete.  This can also help context switches when enqueuing data
in the interface driver if the operation can be batched.
Paragraph (version B):
Since sending a Message may involve a context switch between the
application and the transport system, sending patterns that involve
multiple small Messages can incur high overhead if each needs to be
enqueued separately.  To avoid this, the application can indicate a
batch of Send actions through the API.  When this is used, the
implementation should hold off on processing Messages until the batch
is complete.
Draft: draft-ietf-taps-interface

Commentary: ... while we use ( property , values ) pairs to set other properties ? Is there a reason for this ? Otherwise I suggest we agree to one interaction model ! 
 Related I also think this text is n't really that correct : " Security decisions , especially pertaining to trust , are not static . Once configured , parameters may also be supplied during connection establishment . These are best handled as client - provided callbacks . " You can update some security parameter anytime during the connection using the same interface as before . However the two callbacks we have defined require actually actions that follow an event , so they have to be callbacks . 
 " However the two callbacks we have defined require actually actions that follow an event , so they have to be callbacks . " - that 's it , these need to be callbacks . made them like that because using them requires a tighter interaction model . See issue . 
 As discussed in interim , Security Parameters are a bit different from selection properties . We should review the security parameter interface , but it will likely be independent . 
 I did a closer review on these and there are two main differences between Security Parameters and the other Preferences / Events : Use of individual calls on security parameters instead of add with  . These could easily be integrated , e.g. , by turning into Use of Callbacks instead of Events – closed as Issue . Despite there is no technical reason to not turn the Security Callbacks into events , events that " need to do something " , i.e. , accept , reject , or return an identity , really look wired . Let 's discuss which way to take this one forward : Leave as is Align the interface of SecurityParameters to the Transport Parameters , but keep them as a separate object and leave SecurityCallbacks as they are Integrate the interface of SecurityParameters into the Transport Parameters , but keep SecurityCallbacks roughly the same Integrate the interface of SecurityParameters into the Transport Parameters , make SecurityCallbacks more event - like . I am happy to make a PR for whatever we decide , but not for all of them . 
 We can do the minor option to change AddCiphersuite to Add(ciphersuite ... ) 
 Maybe add clarification text to say that these are pre - connection only parameters 
 Consider cutting cache lifetime , etc , from this list 
 We really should explicitly add a sentence to clearly say that the security functions are configured using add functions and not via Properties . This is so useful to say , so that someone does not come along and do this because they think we just did n't see this . 
 closed with 
 lgtm , will let merge it though .
Paragraph (version A):
Session cache management: Used to tune cache capacity, lifetime,
re-use, and eviction policies, e.g., LRU or FIFO.  Constants and
policies for these interfaces are implementation-specific.
Paragraph (version B):
Session cache management: Used to tune cache capacity, lifetime,
re-use, and eviction policies, e.g., LRU or FIFO.may also me
changed, but are implementation-specific.
Draft: draft-ietf-taps-interface

Commentary: When I initial read the heading I thought this is again about reliability . May we can call this single - segment or something ... ? 
 Well it 's a term - I do n't like it much . Single segment does n't mean it 's all in one IP packet ( it means it 's all in one transport segment ) . We could just say sending as a single IP packet . 
 Interim : proposing to rename to something more simple like Do n't Fragment ? We do n't have a good name . 
 Do n't Fragment seems good too me - and tidy this sentence : OLD : /Attempts to send a message with this property set with a size greater to the transport 's current estimate of its maximum transmission segment size will result in a " SendError"./ NEW : /Setting this property causes a " SendError " when an attempt is made to send a message with a size greater than the transport 's current estimate of the maximum packet size./
Paragraph (version A):
This property specifies that a message should be sent and received as
a single packet without transport-layer segmentation or network-layer
fragmentation, if possible.  Attempts to send a message with this
property set with a size greater to the transport's current estimate
of its maximum transmission segment size will result in a
"SendError".  When used with transports supporting this functionality
and running over IP version 4, the Don't Fragment bit will be set.
Paragraph (version B):
This property specifies that a message should be sent and received as
a single packet network-layer fragmentation, if possible.  Attempts
to send a message with this property set with a size greater to the
transport's current estimate of its maximum transmission segment size
will result in a "SendError".  When used with transports supporting
this functionality and running over IP version 4, the Don't Fragment
bit will be set.
Draft: draft-ietf-taps-interface

Commentary: Sorry we just merged the multipath part into the API doc but I think there is still an issue about this part : ' Active : : The connection will negotiate the use of multiple paths if the chosen transport supports this . It will actively bring up paths based on the multipath policy ( { { multipath - policy } } ) selected by the application , as limited by the Interface Instance and Provisioning Domain Instance properties ( see { { prop - interface } } and { { prop - pvd } } ) . Passive : : The connection will support the use of multiple paths if the remote endpoint requests it . The connection will not actively initiate the use of any new paths , but will accept paths initiated by the remote endpoint . ' This mixes two things which should be separated : requesting MP support actively ( or just do it if requested by the other end ) and opening of new subflows when MP support was negotiated successfully . I thought we wanted to take the later out ( opening sub flows ) and discuss that separately .... ? 
 Just created PR to remove the part about opening new subflows . Do we need to further discuss when / how to open subflows or do we leave this as open for now ? 
 Agree that interim ( June 19 ) to not address opening of subflows in the API
Paragraph (version A):
The connection will negotiate the use of multiple paths if the
chosen transport supports this.  It will actively bring up paths
based on the multipath policy (multipath-policy) selected by the
application, as limited by the Interface Instance and Provisioning
Domain Instance properties (see prop-interface and prop-pvd).
Paragraph (version A):
The connection will support the use of multiple paths if the
remote endpoint requests it.  The connection will not actively
initiate the use of any new paths, but will accept paths initiated
by the remote endpoint.
Paragraph (version B):
The connection will negotiate the use of multiple paths if the
chosen transport supports this.
Paragraph (version B):
The connection will support the use of multiple paths if the
remote endpoint requests it.
Draft: draft-ietf-taps-interface

Commentary: Clarify how the IANA protocol numbers registry keywords ( largely upper - case ) textually relate to Transport Property Names . Refine some of the surrounding text .
Paragraph (version A):
Allow different components of a TAPS implementation to pass
Transport Properties, e.g., between a language frontend and a
policy manager, or as a representation of properties retrieved
from a file or other storage.
Paragraph (version A):
Make code of different TAPS implementations look similar.
Paragraph (version A):
The Namespace part MUST be empty for well-known, generic
properties, i.e., for properties that are not specific to a
protocol and are defined in an RFC.
Paragraph (version B):
Allowing different components of a TAPS implementation to pass
Transport Properties, e.g., between a language frontend and a
policy manager, or as a representation of properties retrieved
from a file or other storage.
Paragraph (version B):
Making code of different TAPS implementations look similar.
Paragraph (version B):
The Namespace component MUST be empty for well-known, generic
properties, i.e., for properties that are not specific to a
protocol and are defined in an RFC.
Paragraph (version A):
Namespaces for the keywords provided in the IANA protocol numbers
registry (see https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml) are reserved for Protocol Specific Properties
and MUST not be used for vendor or implementation specific
properties.
Paragraph (version B):
Namespaces for each of the keywords provided in the IANA protocol
numbers registry (see https://www.iana.org/assignments/protocol-
numbers/protocol-numbers.xhtml), translated to lower-case and with
characters other than letters, numbers, and hyphens deleted, are
reserved for Protocol Specific Properties and MUST not be used for
vendor or implementation-specific properties.
Draft: draft-ietf-taps-impl

Commentary: I actually really like : " Simultaneous " and " Staggered " as descriptive terms that avoid the question of " delaying " . 
 Opening this to follow up on a comment by on that is now closed . " Simultaneous " and " Staggered " would be better names than " Immediate " and " Delayed " . Just from these terms , I would normally think that " Immediate " means to start racing right away , whereas " Delayed " means that nothing would happen for some time . So these two terms are slightly misleading in my opinion . ) 
 I agree this would be an improvement . 
 In Section 4.2.1 . , I did n't really understand what " immediate " means from the text . I think it just needs one sentence . 
 lgtm ( side note - nothing blocking , this is just an idea : to me , " Simultaneous " and " Staggered " would be better names than " Immediate " and " Delayed " . Just from these terms , I would normally think that " Immediate " means to start racing right away , whereas " Delayed " means that nothing would happen for some time . So these two terms are slightly misleading in my opinion.)Looks good , thanks ! I will close this and open a separate issue for the naming .
Paragraph (version A):
Immediate, or simultaneous, racing should be avoided by
implementations.  This approach can consume network resources and
establish state that will not be used.
Paragraph (version B):
Immediate racing is when multiple alternate branches are started
without waiting for any one branch to make progress before starting
the next alternative.  This means the attempts are effectively
simultaneous.  Immediate racing should be avoided by implementations,
since it consumes extra network resources and establishes state that
might not be used.