jiebi/CodeConvo huggingface dataset:
Change:
The above process to locate the serial-number MUST be performed by the pledge when filling out the voucher-request.  Signed voucher- <del> requests are always passed up to the MASA, and the connection between the serial-number in the voucher-request and the serial number in the IDevID certificate. </del> <ins> requests are always passed up to the MASA. </ins> As explained in RequestVoucherFromMASA the Registrar MUST extract the <del> serial-number again itself from the pledge's TLS certificate.  It may </del> <ins> serial-number again itself from the pledge's TLS certificate.  It can </ins> consult the serial-number in the pledge-request if there are any possible confusion about the source of the serial-number (hwSerialNum vs serialNumber).

Discussion:
This should be a complete set of diffs for removing unsigned pledge voucher-requests from the text.
For issue
The text "This artifact may be optionally signed" is buried in the yang module (ietf-voucher-URL) and needs to be removed.
When a pledge decides to use an unsigned voucher request, the Registrar will place it into prior-signed-voucher request on the BRSKI-MASA arc. It will be JSON embedded in. When a pledge decides to use a signed voucher request, the Registrar will place the base64 encode of the pledge_request in as a string. The MASA can tell the difference between the two because the signed thing (whether CBOR, COSE, CMS signed CBOR, or CMS signed JSON) will always be base64 encoded. We need to explain this somewhere.
section 5.5 indicates that: prior-signed-voucher-request: If a signed pledge voucher-request was received then it SHOULD be included in the registrar voucher- request. (NOTE: what is included is the complete pledge voucher- request, inclusive of the 'assertion', 'proximity-registrar-cert', etc wrapped by the pledge's original signature). If a signed voucher-request was not recieved from the pledge then this leaf is omitted from the registrar voucher request. This indicates that the MASA never needs to "tell the difference" only the registrar. (The pledge to registrar signaling is via request media type as detailed in s5.2). I did notice this when reading: s3.3. these references to voucher in the leaf description should be to voucher request? "If it is necessary to change a voucher, or re-sign and forward a voucher that was previously provided along a protocol path, then the previously signed voucher SHOULD be included in this field." etc. subsequent paragraphs.
URL tries to fix the lack of specification for unsigned voucher requests.
Max to produce a draft branch that removes unsigned voucher request so we can examine the ramifications of this.
v20 of BRSKI removed unsigned voucher requests. What were the reasons for removing? I don't see a mention of this in the anima WG email. If removed as a final decision, then this issue can be closed also.
Hi, yes, we could close this now. I did post several times to the list in Feb and March, and it was raised during the WG meeting itself, asking for feedback.

Ok, I now see the email list discussion also in December 2018 and based on this the unsigned voucher was removed.
Change:
"NamedGroupList" value: %%% Named Group Extension enum { // Elliptic Curve Groups. <del> obsolete_RESERVED (1..13), sect571r1 (14), obsolete_RESERVED (15..22), secp256r1 (23), secp384r1 (24), secp521r1 (25), </del> <ins> obsolete_RESERVED (1..22), secp256r1 (23), secp384r1 (24), secp521r1 (25), </ins> Indicates support of the corresponding named curve.  Note that

Discussion:
It appears to be the consensus that sect571r1 should be dropped. This drops it and adds placeholders for the CFRG curves. There are likely to be more than these two values in the final version to indicate ECDHE & certificate usage separately.
NAME shall we remove sect571r1 Let's let the CFRG draft get a little further along before we add the placeholders.
On Wednesday, July 15, 2015 06:23:48 pm ekr wrote: Ok. I dropped that bit and pushed a new commit here.
Rob Stradling just posted to the list that he suspects that most users of this curve are just due to implementations blindly picking the biggest number, not because it was actually chosen. OpenSSL seems to do this by default and doesn't really provide an obvious way to change that.
Change:
For example: indicates that a resource with the relation type <del> "https://example.org/rel/widget" can be found by interpolating the </del> <ins> "https://example.org/rel/widget" can be found by expanding the </ins> "https://example.org/vars/widget_id" variable into the template given.

Discussion:
"interpolate" feels very odd. Other choices would be "expanding" or "substituting". I am not picky about the exact choice, but the current terminology seems odd.
The URI Template RFC uses 'expand', so that seems most appropriate.
Change:
applications running on top of QUIC must therefore either be prepared to accept connectivity failure on such networks, or be engineered to fall back to some other transport protocol.  In the case of HTTP, <del> this fallback is TLS 1.3 over TCP. </del> <ins> this fallback is TLS over TCP. </ins> The IETF TAPS specifications I-D.ietf-taps-arch describe a system with a common API for multiple protocols and some of the implications

Discussion:
Applicability section 2 says: I'm not sure how practical this advice is. Requiring a fallback to TLS 1.3 specifically seems problematic due to the diversity of HTTP versions and TLS versions that are deployed today. (NB: I agree with a general raising of the bar for security, but I don't think this document is the place to state it) We can assume that any HTTP version might learn about HTTP/3 via Alt-Svc or HTTPSVC. This could for example be HTTP/1.1 over TCP port 80. Such a client could fallback to the version it learned about QUIC from, and nothing bad would happen.
This wasn't meant to enforce any restriction. The assumption was simply that if you have implemented QUIC, you might have probably also implemented TLS1.3... however, I guess we can just remove the "1.3" here and only say "TLS over TCP". Okay?
One could argue it should require TLS 1.3, since otherwise there's an easy security downgrade, but I'm not sure that's something we could require.
IMO we need to accommodate disparate support across versions. To give an example, a CDN operator may have QUIC and HTTP endpoints that are configured differently according to customer configuration. With QUIC v1 it is safe to assume only TLS 1.3 so a CDN might not provide configuration for TLS version. However, other HTTP versions could theoretically be configured only to support a maximum of TLS 1.2. Since plaintext HTTP and TLS 1.2 are not prohibited for use on the internet, it seems odd to levy a requirement that prevents them being used in one specific chain of interactions. Mirja's suggestion to say "TLS over TCP" is better but would still not address the plaintext HTTP case. A user agent might see URL, connect to port 80, and get Alt-Svc'd to HTTP/3. If the something goes wrong and TLS is not permitted, then all connectivity might be broken forever.
In the same section later we say I hope that addresses your point about security downgrade, NAME ?
It might be worth saying "likely to impose a degradation on performance and can degrade security;"?
I created a PR and also changed the order of sentences a bit to make the it more clear. NAME is there anything else you think we need to say here?
Change:
4.4.1. <del> DTLS records contain a sequence number to provide replay protection. Sequence number verification SHOULD be performed using the following sliding window procedure, borrowed from Section 3.4.3 of RFC4303. </del> <ins> Each DTLS record contains a sequence number to provide replay protection.  Sequence number verification SHOULD be performed using the following sliding window procedure, borrowed from Section 3.4.3 of RFC4303. </ins> <del> The receiver packet counter for this session MUST be initialized to zero when the session is established.  For each received record, the </del> <ins> The received packet counter for a session MUST be initialized to zero when that session is established.  For each received record, the </ins> receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received <del> during the life of this session.  This SHOULD be the first check </del> <ins> during the lifetime of the session.  This SHOULD be the first check </ins> applied to a packet after it has been matched to a session, to speed <del> rejection of duplicate records. </del> <ins> up the rejection of duplicate records. </ins> Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following

Discussion:
I do understand that the text is consistent with the one in , but I think that it could benefit from some rework.
Change:
Version Negotiation packet to indicate that the version the client chose is unacceptable, but doesn't allow the client to safely make use of that information to create a new connection with a mutually <del> supported version. </del> <ins> supported version.  This document updates QUIC-INVARIANTS by defining version negotiation mechanisms that leverage the Version Negotiation packet. </ins> With proper safety mechanisms in place, the Version Negotiation packet can be part of a mechanism to allow two QUIC implementations

Discussion:
Add a short text in the introduction section to define how this document updates RFC 8999.
Thanks for taking the time, Christian! I appreciate it.
We have agreed to mark this document as updating RFC 8999. Fine, but this lacks a bit of discipline. We should have a statement inside the text (not just the abstract) explaining in which way RFC 8999 is updated.
Can someone propose text here? Based on our discussion in , there is no agreement inside the IETF on what "updates" means so I'm not sure what text would be helpful for readers.
NAME see PR
Change:
transmitting. In order to avoid nonce reuse, the cryptographic contexts used in <del> step 1 and step 5 MUST use different, independent master keys and master salts. </del> <ins> step 1 and step 5 MUST use different, independent master keys.  Note that this means that the key used for decryption by the MD MUST be different from the key used for re-encryption to the end recipient. </ins> Note that if multiple MDs modify the same packet, then the first MD to alter a given header field is the one that adds it to the OHB.  If

Discussion:
This PR responds to IESG review comments from Magnus Westerlund, except for his comments on RED, which I haven't quite figured out how to address yet.
LGTM with nits
Change:
Store the mDNS hostname and its related IP address in the ICE agent for future reuse. <del> Replace the IP address of the ICE host candidate with its mDNS hostname.  Expose the candidate. </del> <ins> Replace the IP address of the ICE candidate with its mDNS hostname and provide the candidate to the web application. </ins> An ICE agent can implement this procedure in any way so long as it produces equivalent results to this procedure. An implementation may for instance pre-register mDNS hostnames by executing steps 3 to 5 and prepopulate an ICE agent accordingly.  By <del> doing so, only steps 1 and 2 of the above procedure will be executed at the time of gathering candidates. </del> <ins> doing so, only step 6 of the above procedure will be executed at the time of gathering candidates. </ins> An implementation may also detect that mDNS is not supported by the <del> available network interfaces.  The ICE agent may skip step 3 and 4 </del> <ins> available network interfaces.  The ICE agent may skip steps 2 and 3 </ins> and directly decide to not expose the host candidate. <del> This procedure ensures that a mDNS name is used to replace only one IP address.  Specifically an ICE agent using an interface with both </del> <ins> This procedure ensures that an mDNS name is used to replace only one IP address.  Specifically, an ICE agent using an interface with both </ins> IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. <ins> Any server-reflexive candidates generated from an mDNS local candidate MUST have their raddr field set to 0.0.0.0 and their rport field set to 0. Any candidates exposed to the web application via local descriptions MUST be identical to those provided during candidate gathering (i.e., MUST NOT contain private host IP addresses). </ins> 2.2. <del> For any remote host ICE candidate received by the ICE agent, the following procedure is used: </del> <ins> For any remote ICE candidate received by the ICE agent, the following procedure is used: </ins> If the connection-address field value of the ICE candidate does not end with ".local" or if the value contains more than one ".",

Discussion:
Followup from , as discussed today
Will wait for LGTM from NAME before merging.
Rethought my approach here and rewrote the section accordingly. PTAL.
LGTM
Sorry for the delay. Github did not let me see any diffs over the weekend.
Change:
Implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association. <ins> 4.1.1. Implementations can distinguish the two header formats by examining the first byte, which in the DTLSCiphertext header represents the content type.  The only valid values for the content type are alert(21), handshake(22), application_data(23), and ack(25), with application_data actually representing protected data with the true content type being encrypted.  If any of these values is present, then the record MUST be handled as DTLSCiphertext. If the first byte is any other other value, then receivers MUST check to see if the leading bits of the first byte are 001.  If so, they MUST process the record as DTLSShortCiphertext.  Otherwise, the record MUST be rejected as if it had failed deprotection. 4.1.2. When receiving a DTLSShortCiphertext message, the recipient does not have a full epoch or sequence number value and so there is some opportunity for ambiguity.  Because the full epoch and sequence number are used to compute the per-record nonce, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. If the epoch bit has the same parity as the current epoch, then implementations SHOULD reconstruct the sequence number by computing the full sequence number which is numerically closest to one plus the sequence number of the highest successfully deprotected record. If the epoch bit has a different parity from the current epoch, then the record is either from a previous epoch or from a future epoch. Implementations SHOULD use the epoch value which would produce a sequence number which is numerically closest to what would be reconstructed for that epoch, as determined by the algorithm in the paragraph above. [[OPEN ISSUE: Say something about how many outstanding packets? Difficulty here is that we have no ACKs to tell us what's outstanding.]] [[OPEN ISSUE: This isn't going to work well with multiple key updates.  There are a number of options here, including limiting to one outstanding update, or saying that you have to use long headers in that case.]] </ins> 4.2. Each DTLS record MUST fit within a single datagram.  In order to

Discussion:
NAME PTAL
Oops. Thanks.
Sorry, I forgot to mention that I plan to do a separate PR for shrinking DTLS ciphertext. I have part of it in my buffer, but got this up and had to move on to something else for a bit.
I'm happy to defer fixing KeyUpdate, which is basically non-functional as it is. This is fine on that basis.
Change:
and discontinue retrying. The Leader MUST ignore any report pertaining to a batch that has <del> already been collected.  (See input-share-batch-validation for </del> <ins> already been collected.  (See early-input-share-validation for </ins> details.)  Otherwise, comparing the aggregate result to the previous aggregate result may result in a privacy violation.  (Note that the Helpers enforce this as well.)  The Leader MAY ignore any reports

Discussion:
Clarify that is used when it's impossible to determine if an input share is valid. One situation we need this for is when an Aggregator drops some anti-replay state in order to reduce storage costs. This should result in data loss in the worst case, not a loss of privacy.
Since , aggregators are required to store report nonces for batch intervals that have not yet been collected. This is necessary in order to prevent replay attacks. The problem is that nothing guarantees that a batch interval will be collected in a timely manner: In theory, it's possible that aggregators will have to store nonce sets indefinitely. To prevent this, there needs to be a way for the aggregators to agree on when to stop accepting reports for a given batch interval. The strawman solution is to allow each aggregator to, at its own discretion, ignore a report if it can't confirm if the report was replayed or not. The problem is that this potentially leads to unnecessary data loss.
I propose resolving this with .
Change:
epoch and begins the next one. In practice, there's a realistic risk of two members generating <del> Commit messages at the same time, based on the same state, and both </del> <ins> Commit messages at the same time, based on the same counter, and both </ins> attempting to send them to the group at the same time.  The extent to which this is a problem, and the appropriate solution, depends on the design of the Delivery Service.  Per the CAP theorem, there are two

Discussion:
This PR pulls in the CAP theorem-related discussion from URL which is a more helpful way to frame DS design.
Change:
validation response for his own account key.  The risks due to hosting providers noted above are a particular case. <ins> It is RECOMMENDED that the server perform DNS queries and make HTTP and TLS connections from various network perspectives, in order to make MitM attacks harder. </ins> 10.3. As a protocol run over HTTPS, standard considerations for TCP-based

Discussion:
Previously these were spread among the various challenges. We can simplify by putting them in one place. Replaces .
Change:
negotiation (both compatible and incompatible) interacts with retry during a handshake that requires both.  For example, that could be accomplished by having the server send a Retry packet in the original <del> version first and therefore validating the client's IP address before </del> <ins> version first thereby validating the client's IP address before </ins> attempting compatible version negotiation.  If both versions support authenticating Retry packets, the compatibility defition needs to define how to authenticate the Retry in the negotiated version

Discussion:
s/and therefore/, thereby/
s/rightly/tightly s/across version/across multiple versions
s/Alternatively, t/T/
Change:
register-capsule and register-no-context-capsule.  When contexts are used, they are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a <del> 62-bit integer (0 to 2^62-1). </del> <ins> 62-bit integer (0 to 2 -1). </ins> While stream IDs are a per-hop concept, context IDs are an end-to-end concept.  In other words, if a datagram travels through one or more

Discussion:
…king hte law Also, switch to format to beatuiful superscript HTML rendering as used by RFC 9000.
Stating the obvious here. But we're using value with a legal range larger than semantically legal. RFC 9000 has some similar caveats with MAX_STREAMS URL To address this, the suggestion is to add something like
That suggestion sounds good to me.
Change:
section is relevant for EAP-TLS in general (regardless of the underlying TLS version used). <ins> EAP servers will usually require the EAP peer to provide a valid certificate and will fail the connection if one is not provided. Some deployments may permit no peer authentication for some or all connections.  When peer authentication is not used, implementations MUST take care to limit network access appropriately for unauthenticated peers and implementations MUST use resumption with caution to ensure that a resumed session is not granted more privilege than was intended for the original session. </ins> EAP-TLS is typically encapsulated in other protocols, such as PPP RFC1661, RADIUS RFC2865, Diameter RFC6733, or PANA RFC5191.  The encapsulating protocols can also provide additional, non-EAP

Discussion:
Discuss security implementations of no peer authentication in the authorization section of section 5. This addresses issue
NAME does this PR address this issue?
Yes, thanks.
Section 5 should have text discussing the security aspects of "no peer authentication" Perhaps: MUST put users into a limited access network MUST NOT allow resumption Otherwise the unauthenticated users would get open access to secure networks.
Change:
3.5. <ins> RTP CNAME values provide a canonical name for the RTP endpoint, allowing other RTP endpoints to determine which RTP streams are using the same clock and thus which clock sources can be used that to synchronize media playout. Any MediaStreamTracks which have different clock sources MUST have different CNAMEs [TODO: need a reference for this.]  Any MediaStreamTracks which are in different PeerConnection objects MUST have different CNAMEs; this prevents peers from linking calls from multiple remote PeerConnections based on the CNAME.  For simplicity, MediaStreamTracks in the same PeerConnection which have the same clock source SHOULD have the same CNAME. 3.6. </ins> Some call signaling systems allow various types of forking where an SDP Offer may be provided to more than one device.  For example, SIP RFC3261 defines both a "Parallel Search" and "Sequential Search".

Discussion:
This Replaces PR URL This fixes URL
I cleaned up the text here.
The structure of this looks good - just think the text should be expanded a bit.
This should incorporate the change in - and reference URL there as well.
lgtm
While cname for offers is described quite clearly, the sections describing answers don't mention CNAME.
This should get handled in NAME
I don't think that is the place. Looking at section 5.3.1. Initial answer, there is text saying 'If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in [RFC5576], Section 4.1, indicating the SSRC to be used for sending media.' There should be something about cname here as well, just as it is for the corresponding part in section 5.2.1 Initial Offer.
Right, but is making changes to 5.2.1, so that's probably the right place to change 5.3.1 as well.
I saw Ekr updated and closed this one. Makes sense. , Justin Uberti EMAIL wrote:
Section 5.2.1: in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs specified for MSTs? Are they randomly generated for each MediaStream? If so, can two MediaStreams be synced?]
Discussion on rtp usage more or less concluded that we'd use the same CNAME for an entire RTCPeerConnection, unless the tracks had different clock sources. And require different CNAMEs for different RTCPeerConnections, unless something had forced them to be the same. API affordances for this are TBD and for the W3C WG, Magnus suggested some sort of binding between RTCPeerConnection instances to allow for CNAME copying, rather than provide the footgun that direct overwriting permits (i.e., the browser is given the ability to mark unsynchronized tracks differently, rather than be forced to falsely claim synchronization).
Discussed in DC: this resolution is OK. Question about the use of LS groups for legacy gear, as opposed to MSID. See .
Related but URL
What are next steps here?
Propose browser generates one CNAME (or more if multiple clock sources). Later API may add ways to set the CNAME from JS.
That would be consistent with the RTP usage conclusions.