jiebi/CodeConvo huggingface dataset:
Code change:
Minor editorial fixes in response to Gen-ART review. <ins> Random EP names: Point that multiple collisions are possible but unlikely. (For background, in the first round of attempts there's a good chance that one of the random IDs will collide due to the birthday paradox; the likelyhood for a second (or even third) collision in a row is way below that because only the colliding node(s) will retry). </ins> changes from -24 to -25 Large rework of section 7 (Security policies)

Related discussion:
text: The generated address did, however, fail to follow the guidance of RFC 3307 and set the first bit of the Group ID. Consequently, the addresses were changed from ff35:30:2001:db8::x to ff35:30:2001:db8::8000:x, which should finally be a legal choice of a group address for anyone operating the 2001:db8:: site. (The changes can be viewed at URL). GENERIC-6MAN "Whas this discussed with 6MAN?" response: Not yet; a request for feedback was sent out recently. (Mail at URL). GENERIC-WHOPICKSMODEL "How does the client know which security policies the RD supports?" response: The client can only expect any level of trustworthiness if there is a claim to that in the RD's credentials. Typically, though, that claim will not be encoded there, but implied. For example, when configuring an application that relies authenticated endpoint names, then telling the application to use the RD authenticated via PKI as URL should only be done if the configurator is sure that URL will do the required checks on endpoint names. Some clarification has been added in URL GENERIC-SUBJECT "Section 7.1 says: '... can be transported in the subject.' -- where precisely?" response: That text was only meant to illustrate to the reader what such a policy could contain, not to set one (which would require more precision). It has been made more explicit that this is merely setting the task for the policies. As an example, some more precision is given by referring to SubjectAltName dNSName entries. Changes in URL (If you have read up to this point, please continue reading the follow-up mails addressing the individual reviewer's points.)
Code change:
as well as providing a public key that others can use for key agreement.  The client's signature key can be updated throughout the lifetime of the group by sending a new KeyPackage with a new <del> signature key; the new signature key MUST be validated by the </del> <ins> Credential.  However, the identity MUST be the same in both Credentials and the new Credential MUST be validated by the </ins> authentication service. When used as InitKeys, KeyPackages are intended to be used only once

Related discussion:
text: Rotating keys is important and in some cases, Signature Keys are not going to be very "long-term". Instead they're going to be rotated periodically. I thus propose we simply remove the assumption that Signature Keys are of a "long-term" nature (or otherwise "long-lived"). The second change in this PR is that I added a few words indicating explicitly that the identity must not change when updating a KeyPackage.
Code change:
a Preconnection allows applications to override this for more detailed control. <del> Transport Properties MUST always be specified while security parameters are OPTIONAL. </del> If Message Framers are used (see framing), they MUST be added to the Preconnection during pre-establishment.

Related discussion:
text: For other parameters you have to pass in an empty object if you do not want to set anything but not for SecurityParameters. Unclear why the parameters are treated differently?
Make security parameters non-optional Remove "Transport Properties MUST always be specified while security parameters are OPTIONAL." Define that there is an implementation-specific security parameter to disable security
LGTM, thanks!
Code change:
Partial IV MUST always be compared with the Notification Number, which thus MUST NOT be forgotten after 128 seconds.  Further details of replay protection of notifications are specified in replay- <del> protection.  The client MAY ignore the Observe option value. </del> <ins> protection. </ins> Clients can re-register observations to ensure that the observation is still active and establish freshness again (RFC7641 <del> Section 3.3.1).  When an OSCORE observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and OSCORE option) change.  The server uses the new request's Partial IV as the 'request_piv' of new responses. </del> <ins> Section 3.3.1).  When an OSCORE protected observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and OSCORE option) change.  The server uses the new request's Partial IV as the 'request_piv' of new responses. </ins> 4.1.3.5.

Related discussion:
text: This PR should (hopefully) conclude the main rewrite of Observe which was triggered by the security analysis and additional reviews of Observe. It should (hopefully) now be clear what part of the Observe related processing can be omitted in case Observe is not supported or in case intermediaries are not used. A new appendix E is covering the latter case.
Code change:
its adoption in the broadcasting/streaming industry is lagging behind. <del> Currently, there is no standard protocol designed for ingesting media into a streaming service using WebRTC and so content providers still rely heavily on protocols like RTMP for doing so. These protocols are much older than WebRTC and by default lack some important security and resilience features provided by WebRTC with minimal overhead and additional latency. The media codecs used for ingestion in older protocols tend to be limited and not negotiated.  WebRTC includes support for negotiation of codecs, potentially alleviating transcoding on the ingest node (which can introduce delay and degrade media quality).  Server side transcoding that has traditionally been done to present multiple renditions in Adaptive Bit Rate Streaming (ABR) implementations can be replaced with Simulcast RFC8853 and SVC codecs that are well supported by WebRTC clients.  In addition, WebRTC clients can adjust client-side encoding parameters based on RTCP feedback to maximize encoding quality. Encryption is mandatory in WebRTC, therefore secure transport of media is implicit. </del> The IETF RTCWEB working group standardized JSEP (RFC8829), a mechanism used to control the setup, management, and teardown of a multimedia session.  It also describes how to negotiate media flows

Related discussion:
text: The text says: "The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node," I don't understand this sentence. If I use an "older protocol", e.g, RTMP, why do I need to care about WebRTC codecs?
That refers if you use RTMP for ingest and WebRTC for viewing.
rewriten the editorial in
The text says: "These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with minimal delay." I assume you refer to RTMP, which is mentioned in the previous Section. Doesn't RTMPS solve some of the security issues? But in general, if you want to put up WHIP against RTMP, I think you need a little more text. Also, as WHIP is supposed to be an "easy to implement" protocol, I think it would be fair to also list some of the functions NOT supported compared to e.g., RTMP. As I have mentioned before, there is no command for start the ingestion - it is assumed to have begun when the connection has been established. Also, there is no PAUSE/RESUME.
It is more referring to RTSP which lacks DTLS support. no command for start the ingestion - it is assumed to have begun when the connection has been established. Also, there is no PAUSE/RESUME. RTMP protocol was intended as an RPC mechanism between the flash player and server. It allowed to create custom apps both on client and server side, which supported a wide range of methods using AMF. However, current "RTMP protocol" implemented for ingesting is a reversed engineered version of the implementation done by the FMS and it lacks support for PAUSE/RESUME and the publication is started from the start of the RTMP connection (same as whip).
rewriten the editorial in
Code change:
the server is not overly constrained by the amplification restriction. <del> Packet loss, in particular loss of a Handshake packet from the server, can cause a situation in which the server cannot send when the client has no data to send and the anti-amplification limit is reached.  In order to avoid this causing a handshake deadlock, clients MUST send a packet upon a probe timeout, as described in QUIC-RECOVERY.  If the client has no data to retransmit and does not have Handshake keys, it MUST send an Initial packet in a UDP datagram of at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a Handshake packet. </del> <ins> Loss of an Initial or Handshake packet from the server can cause a deadlock if the client does not send additional Initial or Handshake packets.  A deadlock could occur when the server reaches its anti- amplification limit and the client has received acknowledgements for all the data it has sent.  In this case, when the client has no reason to send additional packets, the server will be unable to send more data because it has not validated the client's address.  To prevent this deadlock, clients MUST send a packet on a probe timeout (PTO, see Section 5.3 of QUIC-RECOVERY).  Specifically, the client MUST send an Initial packet in a UDP datagram of at least 1200 bytes if it does not have Handshake keys, and otherwise send a Handshake packet. </ins> A server might wish to validate the client address before starting the cryptographic handshake.  QUIC uses a token in the Initial packet

Related discussion:
text: Clarifies why a client might send a Handshake packet, as well as improving the surrounding anti-deadlock text. Changes 2 SHOULDs to MUSTs to line up with recovery.
We don't provide examples of the weird cases where you need to send Handshake packets to prevent amplification deadlock. The strangest one is where the client has all Initial data (and therefore has Handshake keys), but never receives a Handshake packet from the server. In this case, the client needs to send a Handshake packet that won't contain ACK or CRYPTO frames. We should explain this in a note. See .
I think the logic in the recovery draft misses some of these cases entirely. The rule in draft 23 is: but in your example case there is not necessarily any unacknowledged data to transmit in a probe, and a is forbidden at Handshake level, leaving no reasonable options to compose an ACK-eliciting packet.
a few suggestions
Code change:
then the server SHOULD change the status of the order to "invalid" and MAY delete the order resource. <del> The server MUST issue the requested certificate and update the order resource with a URL for the certificate shortly after the client has fulfilled the server's requirements.  If the client has already satisfied the server's requirements at the time of this request (e.g., by obtaining authorization for all of the identifiers in the certificate in previous transactions), then the server MUST proactively issue the requested certificate and provide a URL for it in the "certificate" field of the order.  The server MUST, however, still list the completed authorizations in the "authorizations" array. </del> <ins> The server MUST begin the issuance process for the requested certificate and update the order resource with a URL for the certificate once the client has fulfilled the server's requirements. If the client has already satisfied the server's requirements at the time of this request (e.g., by obtaining authorization for all of the identifiers in the certificate in previous transactions), then the server MUST proactively issue the requested certificate and provide a URL for it in the "certificate" field of the order.  The server MUST, however, still list the completed authorizations in the "authorizations" array. </ins> Once the client believes it has fulfilled the server's requirements, it should send a GET request to the order resource to obtain its

Related discussion:
text: This change replaces "shortly" in the normative language of Section 7.4, Applying for Certificate Issuance, with the more precise expectation that the server begin the issuance process, as discussed on the mailing list. URL We could say "MUST begin the issuance process" The main things on my mind that could delay issuance slightly: Submitting to CT Checking CAA Internal queuing for available capacity Manual vetting I think "MUST begin" covers for all of those, while allowing some vagueness as to how long they will take. On 03/22/2017 09:39 AM, Daniel McCarney wrote:
Code change:
2.4.7. <del> The "search" function extension provides a way to check whether a </del> <ins> The "search()" function extension provides a way to check whether a </ins> given string contains a substring that matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form.

Related discussion:
text: Use parentheses as an indication that something is a function. Also, don't confuse the reader by alluding to potential future alternatives to value(). Reviewers: is this an improvement? It's a draft PR for now until we decide the change is worthwhile.
I think we'll need to explain the () notation, which should be familiar to C programmers but not necessarily to people who grew up on other languages. I also think we have a few more examples that point to hypothetical functions, such as , , .
I don't think there's a great point at which to explain that notation and, based on your observation, I'm going off the idea.
NAME Let's see how pans out before taking the current PR any further. Once I remove the function parentheses, the two PRs are changing the same text.
would be the place.
NAME As you suggested, I introduced this in 1.1, but near the start since it's notation rather than terminology. I did a regexp search to find and fix the remaining examples (your list was complete). In doing so, I found the strange markup and removed the backticks since there was no good reason for them.
We could do the fun() explanation and completeness search in a separate PR.
Code change:
AggregateShare collect-flow: "application/dap-aggregate-share" <del> CollectReq collect-flow: "application/dap-collect-req" </del> <ins> CollectionReq collect-flow: "application/dap-collect-req" </ins> Collection collect-flow: "application/dap-collection"

Related discussion:
text: All references to "metadata" are now to "report_metadata". References to "CollectReq" are now "CollectionReq". References to "CollectResp" are now "Collection".
The current version of the draft renames field "metadata" to "report_metadata" in the Report structure, but does not do the same renaming in the ReportShare and InputShareAad structures. I think this naming should be consistent, though I don't have a preference between the alternatives.
Thanks for pointing this out! Can you send prepare a PR?
Fixed in
Thanks a bunch NAME
Code change:
for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, and Ed25519 for signatures. <del> Values with the first byte 255 (decimal) are reserved for Private Use. </del> New ciphersuite values are assigned by IANA as described in iana- considerations.

Related discussion:
text: NAME thanks, good catch. should be fixed now.
Comment by NAME Algorithm entries use two octets (65535) but only allow 255 Private Use entries. I think that might be a little low. Maybe allow 0xf000 - 0xffff or something ?
I agree this should be changed. CCing NAME who I believe initially proposed this.
Code change:
PSK into the devices, or using a Trust On First Use (TOFU) approach with a device completely unprotected before the first login did take place.  Many devices have very limited UI.  For <del> example, they may only have a numeric keypad or even less number of buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI. </del> <ins> example, they may only have a numeric keypad or even fewer buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI. </ins> Some devices provision PSKs via an out-of-band, cloud-based syncing protocol. <del> Some secrets may be baked into or hardware or software device </del> <ins> Some secrets may be baked into hardware or software device </ins> components.  Moreover, when this is done at manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import.

Related discussion:
text: Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.
Code change:
that the load balancer will redirect the next Client Initial packet to a different server in that pool. <del> 7. </del> <ins> 8. </ins> Versioning in QUIC may change the protocol's behavior completely, except for the meaning of a few header fields that have been declared

Related discussion:
text: hopefully addresses issue
I don't think "the same port number as would be used for the same application over TCP" is necessary general-purpose guidance. I would argue for something more like:
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN
Code change:
Internet Transport Protocols" describes the impact of increased encryption of transport headers in general terms. <ins> It is also worth noting that considerations for heavily-encrypted transport protocols also come into play when streaming media is carried over IP-level VPNs and tunnels, with the additional consideration that an intermediary that does not possess credentials allowing decryption will not have visibility to the source and destination IP addresses of the packets being carried inside the tunnel. </ins> 7.2. Although the IETF has put considerable emphasis on end-to-end

Related discussion:
text: Discussion from editor conference call: NAME will update this PR with NAME comments
From NAME (URL) Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section (Seems closely related to URL )
The purpose of such tunneling is to circumvent geoblocks and access content from other regions - not to protect the media content. Encrypting the content is done by the content owner for its protection.
So, looking at , I'm seeing this text: I think this means that the effect is that the "transport-level information is opaque to intermediaries" effect described in the document applies, with the additional consideration that intermediaries can't see the IP addresses used inside the tunnel, either. I think the same applies to any IPsec-encrypted tunnel. Do we need to say that? And, if so - can we describe this without using product names and descriptions which may age badly in an RFC?
isn't as easy to read, but I think this is also the rough equivalent of IPsec, from a media operator perspective - all of the transport information and the IP addresses used inside the tunnel are obscured.
Just for the record, definitely worth checking as it is related to this discussion: URL Reviewer: Michael Scharf Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. This informational document surveys network and transport protocol issues that affect quality of experience for streaming applications, in particular video. The overview covers many topics across different technologies. Readers may only be familiar with a subset of these topics and could therefore learn quite a bit from this kind of tutorial. Nonetheless, it remains somewhat unclear what the actual objective of some of the text is.