jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-quic-manageability

Commentary: must be postprocessed to become metrics . 
 Waiting for more reviews , e.g. from before we can merge . 
 The text describes an example for measuring the average RTT . I like that , but I think we should call out a little that the mean RTT is only one metric . When looking at management info , I 'm often interested in min /  and variance ... So : “ A simple linear smoothing ... to get a more stable estimate ” . Quite so for a table average RTT . I ’d prefer it if we could say something about RTT variance at this point . To me it is important that RTT measurements are clear , and we should never assume in a Spec that RTT is something specific , but more generally an estimate that needs to consider the variance .
Paragraph (version A):
Note that this measurement, as with passive RTT measurement for TCP,
includes any transport protocol delay (e.g., delayed sending of
acknowledgements) and/or application layer delay (e.g., waiting for a
response to be generated).  It therefore provides devices on path a
good instantaneous estimate of the RTT as experienced by the
application.  A simple linear smoothing or moving minimum filter can
be applied to the stream of RTT information to get a more stable
estimate.
Paragraph (version B):
Note that this measurement, as with passive RTT measurement for TCP,
includes any transport protocol delay (e.g., delayed sending of
acknowledgements) and/or application layer delay (e.g., waiting for a
response to be generated).  It therefore provides devices on path a
good instantaneous estimate of the RTT as experienced by the
application.
Paragraph (version B):
Raw RTT samples generated using these techniques can be processed in
various ways to generate useful network performance metrics.  A
simple linear smoothing or moving minimum filter can be applied to
the stream of RTT samples to get a more stable estimate of
application-experienced RTT.  RTT samples measured from the spin bit
can also be used to generate RTT distribution information, including
minimum RTT (which approximates network RTT over longer time windows)
and RTT variance (which approximates jitter as seen by the
application).
Draft: draft-ietf-quic-manageability

Commentary: It seems to me that QUIC is no different to other transports in respect of being able to utilise other port numbers , and it would be worth noting that this is normal . The present text might perhaps suggest this is specific to QUIC . Should the text reference RFC 7605 or something else just to explain ports do n't imply specific application behaviour , but could infer this ? . 
 The title of the pull request was cause for a momentary flutter - in that I do n't see the port as carrying anything other than a reference to a convention - but the text is very good .
Paragraph (version A):
Applications that have a mapping for TCP as well as QUIC are expected
to use the same port number for both services.  However, as with TCP-
based services, especially when application layer information is
encrypted, there is no guarantee that a specific application will use
the registered port, or the used port is carrying traffic belonging
to the respective registered service.  For example, QUIC-HTTP
specifies the use of Alt-Svc for discovery of HTTP/3 services on
other ports.
Paragraph (version B):
Applications that have a mapping for TCP as well as QUIC are expected
to use the same port number for both services.  However, as for all
other IETF transports RFC7605, there is no guarantee that a specific
application will use a given registered port, or that a given port
carries traffic belonging to the respective registered service,
especially when application layer information is encrypted.  For
example, QUIC-HTTP specifies the use of Alt-Svc for discovery of
HTTP/3 services on other ports.
Draft: draft-ietf-quic-applicability

Commentary: Does this make it easier to understand ? 
 is this better ? 
 “ Server deployments with load balancers and other routing infrastructure need to ensure that this infrastructure consistently routes packets to the correct server instance . “ could this be : “ Server deployments with load balancers and other routing infrastructure that depends on observing the payload of IP packets need to ensure that this infrastructure consistently routes all the QUIC packet belonging to a connection to the same server instance . ” Seems like that is helpful . Is there a relevant section in the OPS draft where the reader should be directed ? 
 Not sure if you addition of " that depends on observing the payload of IP packets " is that helpful in the sentence . The whole point here that if you use load balancers with QUIC , looking only at the IP might not be enough . can you have a look how to phrase this ? 
 Is this referring to sec 9.1 of the applicability draft ? Why refer to the ops draft when the current reference ( QUIC - LB ) has everything you would want to know about the subject ? I do n't understand what  's new clause adds . In fact , the IP address is not in the payload so I do n't believe it 's even accurate . Are you trying to distinguish between L7 and L4 load balancers here ? 
 I could n't work out what the current sentence means what does " correctly " mean ? 
 OK , I can reword this . 
 This is left open as there is a pending rewrite of the NAT section . 
 looks good to me .
Paragraph (version A):
Server deployments with load balancers and other routing
infrastructure need to ensure that this infrastructure consistently
routes packets to the correct server instance.  This might require
coordination between servers and infrastructure.  One method of
achieving this involves encoding routing information into the
connection ID.  This ensures that there is no need to for servers and
infrastructure to coordinate routing information for each connection.
See QUIC-LB for more information.
Paragraph (version B):
Server deployments with load balancers and other routing
infrastructure need to ensure that this infrastructure consistently
routes packets to the server instance that has the connection state,
even if addresses, ports, and/or connection IDs change.  This might
require coordination between servers and infrastructure.  One method
of achieving this involves encoding routing information into the
connection ID.  For an example of this technique, see QUIC-LB.
Draft: draft-ietf-quic-applicability

Commentary: The proposed text looks OK to me . 
 The ID said : “ blocking or other interference by network elements such as firewalls ” I think this language could be seen as having a little attitude that could be avoided . I suggest replacing “ interference ” , and instead say that this can change the forwarding policy . This also extends it to include action from QoS policies and service level agreements . “ by network elements such as firewalls that rely on the port number for application identification . ” I ’d prefer “ use ” to “ rely ” … because they might well use other heuristics in future if they do prove more useful to classify sessions / packets . 
 Is the wording in better / good ?
Paragraph (version A):
Given the prevalence of the assumption in network management practice
that a port number maps unambiguously to an application, the use of
ports that cannot easily be mapped to a registered service name might
lead to blocking or other interference by network elements such as
firewalls that rely on the port number for application
identification.
Paragraph (version B):
Given the prevalence of the assumption in network management practice
that a port number maps unambiguously to an application, the use of
ports that cannot easily be mapped to a registered service name might
lead to blocking or other changes to the forwarding behavior by
network elements such as firewalls that use the port number for
application identification.
Draft: draft-ietf-quic-applicability

Commentary: Issue : “ and use of the UDP port number corresponding to the TCP port already registered for the application is RECOMMENDED ” . I agree with the intent , but here an RFC2119 keyword is used , but is this intended , and can this please cite the RFC that says this rather than just stating this . 
 Similarly noted in 
 PR removes normative language and says " usually ... appropriate " instead . Is that okay ? Or should the wording be stronger ?
Paragraph (version A):
As QUIC is a general purpose transport protocol, there are no
requirements that servers use a particular UDP port for QUIC.  For
applications with a fallback to TCP that do not already have an
alternate mapping to UDP, the registration (if necessary) and use of
the UDP port number corresponding to the TCP port already registered
for the application is RECOMMENDED.  For example, the default port
for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2
over TLS over TCP.
Paragraph (version B):
As QUIC is a general purpose transport protocol, there are no
requirements that servers use a particular UDP port for QUIC.  For
applications with a fallback to TCP that do not already have an
alternate mapping to UDP, usually the registration (if necessary) and
use of the UDP port number corresponding to the TCP port already
registered for the application is appropriate.  For example, the
default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to
HTTP/1.1 or HTTP/2 over TLS over TCP.
Draft: draft-ietf-quic-applicability

Commentary: I think the following sentence has issues : “ In case it is RECOMMENDED to abort the connection , allowing the application to present a suitable prompt to the user that secure communication is unavailable . ” I ’m not sure I understand “ In case ” I ’m not sure this should be upper case RFC2119 , unless we decide to also make normative recommendations in other places . “ allowing” .. ”unavailable ” makes this award to read . 
 2119 issue also noted in .
Paragraph (version A):
Moreover, while encryption (in this case TLS) is inseparably
integrated with QUIC, TLS negotiation over TCP can be blocked.  In
case it is RECOMMENDED to abort the connection, allowing the
application to present a suitable prompt to the user that secure
communication is unavailable.
Paragraph (version B):
Moreover, while encryption (in this case TLS) is inseparably
integrated with QUIC, TLS negotiation over TCP can be blocked.  If
TLS over TCP cannot be supported, the connection should be aborted
instead, in order to enable the application to present a suitable
prompt to the user that secure communication is unavailable.
Draft: draft-ietf-quic-manageability

Commentary: The text says : “ and are emphatically NOT RECOMMENDED . ” I think I would agree with a strong encouragement to not do this , but I would suggest to not use upper case letters at this point , and I ’m not sure “ emphatically ” is a great word in a RFC :-) . I ’d also note that the volume of ACK traffic really can be a problem that QUIC needs to address , because QUIC over radio ( of various types ) can be significantly more expensive or lower performant than TCP , precisely because the control / ACK traffic is much more and there is no opportunity for network mitigation - hence it behoves QUIC implementors to use appropriate methods . 
 I created an PR to address the first point . Regarding the second point : do you want to propose additional text ? However , if I think that would go the into applicability ... ? 
 Suggestion for text : On network paths where there is significant asymmetry , the transmission of QUIC ACKs can reduce the efficient use of network capacity or transmission opportunities . This effect occurs when the return capacity is significantly more constrained than the forward capacity , or the cost of transmission per packet is a significant component of the total transmission cost . Reducing the ratio of acknowledgements to data at the QUIC receiver can improve link utilization and reduce link transmission costs .
Paragraph (version A):
Some deployed in-network functions distinguish pure-acknowledgment
(ACK) packets from packets carrying upper-layer data in order to
attempt to enhance performance, for example by queueing ACKs
differently or manipulating ACK signaling.  Distinguishing ACK
packets is trivial in TCP, but not supported by QUIC, since
acknowledgment signaling is carried inside QUIC's encrypted payload,
and ACK manipulation is impossible.  Specifically, heuristics
attempting to distinguish ACK-only packets from payload-carrying
packets based on packet size are likely to fail, and are emphatically
NOT RECOMMENDED.
Paragraph (version B):
Some deployed in-network functions distinguish pure-acknowledgment
(ACK) packets from packets carrying upper-layer data in order to
attempt to enhance performance, for example by queueing ACKs
differently or manipulating ACK signaling.  Distinguishing ACK
packets is trivial in TCP, but not supported by QUIC, since
acknowledgment signaling is carried inside QUIC's encrypted payload,
and ACK manipulation is impossible.  Specifically, heuristics
attempting to distinguish ACK-only packets from payload-carrying
packets based on packet size are likely to fail, and are not
recommended to use as a way to construe internals of QUIC's operation
as those mechanisms can change, e.g., due to the use of extensions.
Draft: draft-ietf-quic-manageability

Commentary: which is about " Network - visible information about QUIC flows " . They are mentioned once , based on a recent edit , but the text before that does not introduce them or explain what they are . Maybe we can add a few more sentences also making sure that even though they could be observed in the client initial , they can not be changed nor observed form the server ( to understand final negotiation / support ) .
Paragraph (version B):
Even though transport parameters transmitted in the client initial
are obserable by the network, they cannot be modified by the network
without risking connection failure.  Further, the negotiated reply
from the server cannot be observed, so observers on the network
cannot know which parameters are actually in use.
Draft: draft-ietf-quic-manageability

Commentary: The text is good however I do n't understand its placement in the draft fully . Should n't this paragraph go into the previous section or even in an own section ? I know the issue , that this PR is addressing , was about DDoS but if we want to have it in the DDoS section we need probably some more words explaining how Retry should be used in this case . Currently it comes a bit out of nothing and interrupts the reading flow of the rest of the text ... 
 I am not really sure at all that the existing DDoS guidance is good advice ; we have a somewhat more robust plan in quic - lb , which perhaps we should reference ? 
 for that matter , the Retry packet does not make an appearance in this section at all , which seems like an oversight . 
 Yes to both . Can you provide an PR ? 
 Yes , please assign this issue to me .
Paragraph (version B):
TCP syncookies RFC4937 are a well-established method of mitigating
some kinds of TCP DDoS attacks.  QUIC Retry packets are the
functional analogue to syncookies, forcing clients to prove
possession of their IP address before committing server state.
However, there are safeguards in QUIC against unsolicited injection
of these packets by intermediaries who do not have consent of the end
server.  See QUIC_LB for standard ways for intermediaries to send
Retry packets on behalf of consenting servers.
Draft: draft-ietf-quic-manageability

Commentary: This sentence is rather supposed to explain what 's done in QUIC then giving any recommendation , therefore we can simply remove the " recommended " phrasing .
Paragraph (version A):
these connections identifiable based on the usage of the spin bit, it
is recommended that all endpoints randomly disable "spinning" for at
least one eighth of connections, even if otherwise enabled by
default.  An endpoint not participating in spin bit signaling for a
given connection can use a fixed spin value for the duration of the
connection, or can set the bit randomly on each packet sent.
Paragraph (version B):
these connections identifiable based on the usage of the spin bit,
all endpoints randomly disable "spinning" for at least one eighth of
connections, even if otherwise enabled by default.  An endpoint not
participating in spin bit signaling for a given connection can use a
fixed spin value for the duration of the connection, or can set the
bit randomly on each packet sent.
Draft: draft-ietf-quic-applicability

Commentary: to the security considerations section ? 
 Cross protocol attacks , traffic analysis , and migration are discussed as well in the transport draft , so this pointer might not be absolutely necessary . However , we might still want to have it and then I think these are the relevant sections to refer to . 
 Applicability to me seems to be mostly targeted to non - H3 users of QUIC , so I 'm not sure the H3 - specific considerations need to be mentioned here . 
 My thinking was to add that as reference for other applications that might need to consider similar attacks / security issues . At least half of the points in the hhtp/3 sec considerations are really http specific and probably do n't have value for other applications but there are a number of points which are more general . Those points are to some extend probably also covered by the transport draft but may be explained in more detail in the h3 draft .
Paragraph (version B):
Further QUIC-HTTP provides security considerations specific to HTTP.
However, discussions such as on cross protocol attacks, traffic
analysis and padding, or migration might be relevant for other
applications using QUIC as well.
Draft: draft-ietf-quic-applicability

Commentary: After removing normative language , it occurs to us that there might be other security considerations that we want to highlight from Transport and TLS in Manageability or ( especially ) Applicability . 
 Minor editorial nit .
Paragraph (version A):
See the security considerations in QUIC and QUIC-TLS; the security
considerations for the underlying transport protocol are relevant for
applications using QUIC, as well.
Paragraph (version B):
See the security considerations in QUIC and QUIC-TLS; the security
considerations for the underlying transport protocol are relevant for
applications using QUIC, as well.  Considerations on linkability,
replay attacks, and randomness discussed in QUIC-TLS should be taken
into account when deploying and using QUIC.
Draft: draft-ietf-quic-manageability

Commentary: This is a proposal to mention some more things specifically in the security considerations section . At minimum we should add a sentence pointing the reader at the security consideration of the transport and tis drafts . I additionally , more or less , copied some notes from the transport draft that I found particular relevant for reader of the manageability draft . Comments welcome ! 
 any further thought here ? 
 After removing normative language , it occurs to us that there might be other security considerations that we want to highlight from Transport and TLS in Manageability or ( especially ) Applicability .
Paragraph (version A):
Supporting manageability of QUIC traffic inherently involves
tradeoffs with the confidentiality of QUIC's control information;
this entire document is therefore security-relevant.
Paragraph (version B):
QUIC is an encrypted and authenticated transport.  That means, once
the cryptographic handshake is complete, QUIC endpoints discard most
packets that are not authenticated, greatly limiting the ability of
an attacker to interfere with existing connections.
Paragraph (version B):
However, some information is still observerable, as supporting
manageability of QUIC traffic inherently involves tradeoffs with the
confidentiality of QUIC's control information; this entire document
is therefore security-relevant.
Paragraph (version B):
More security considerations for QUIC are discussed in QUIC-TRANSPORT
and QUIC-TLS, generally considering active or passive attackers in
the network as well as attacks on specific QUIC mechanism.
Paragraph (version B):
Version Negotiation packets do not contain any mechanism to prevent
version downgrade attacks.  However, future versions of QUIC that use
Version Negotiation packets are require to define a mechanism that is
robust against version downgrade attacks.  Therefore a network node
should not attempt to impact version selection, as version downgrade
may result in connection failure.
Draft: draft-ietf-quic-manageability

Commentary: Wishful thinking , but as you say , ca n't hurt .
Paragraph (version A):
QUIC is expected to evolve rapidly, so new versions, both
experimental and IETF standard versions, will be deployed in the
Internet more often than with traditional Internet- and transport-
layer protocols.  Using a particular version number to recognize
valid QUIC traffic is likely to persistently miss a fraction of QUIC
flows and completely fail in the multi-year timeframe, and is
therefore not recommended.
Paragraph (version B):
QUIC is expected to evolve rapidly, so new versions, both
experimental and IETF standard versions, will be deployed in the
Internet more often than with traditional Internet- and transport-
layer protocols.  Using a particular version number to recognize
valid QUIC traffic is likely to persistently miss a fraction of QUIC
flows and completely fail in the near future, and is therefore not
recommended.  In addition, due to the speed of evolution of the
protocol, devices that attempt to distinguish QUIC traffic from non-
QUIC traffic for purposes of network admission control should admit
all QUIC traffic regardless of version.
Draft: draft-ietf-quic-applicability

Commentary: This text in is incorrect . An endpoint can abruptly close ( reset ) egress data , but it can only request that its peer abruptly close ingress ( using STOP_SENDING ) . 
 is there a missing " not " ? Do you mean : s / An endpoint can abruptly close ( reset ) egress data / An endpoint can not abruptly close ( reset ) egress data/ ? Anyway , yes , we need to fix that !
Paragraph (version A):
Streams can be independently opened and closed, gracefully or by
error.  An application can gracefully close the egress direction of a
stream by instructing QUIC to send a FIN bit in a STREAM frame.  It
cannot gracefully close the ingress direction without a peer-
generated FIN, much like in TCP.  However, an endpoint can abruptly
close either the ingress or egress direction; these actions are fully
independent of each other.
Paragraph (version B):
Streams can be independently opened and closed, gracefully or by
error.  An application can gracefully close the egress direction of a
stream by instructing QUIC to send a FIN bit in a STREAM frame.  It
cannot gracefully close the ingress direction without a peer-
generated FIN, much like in TCP.  However, an endpoint can abruptly
close the egress direction or request that its peer abruptly close
the ingress direction; these actions are fully independent of each
other.
Draft: draft-ietf-quic-applicability

Commentary: launches right into discussion of how linkability protections might be inadequate without really establishing what the requirements are or why they exist . This needs an introduction paragraph . 
 Note sure how much more we want to say here or can say at this point in time .... if you have a more concrete idea what we should say here , can you give it a try and propose a PR ? 
 Something like : Then launch into the existing discussion . 
 Sounds good to me . I can add that after you PR landed or you can add it to your PR .
Paragraph (version B):
QUIC requires that endpoints generate fresh connection IDs for use on
new network paths.  Choosing values that are unlinkable to an outside
observer ensures that activity on different paths cannot be trivially
correlated using the connection ID.