jiebi/CodeConvo huggingface dataset:
Change:
5. <del> An extension to the RFC8366 voucher is needed for the case where the client will be redirected to a local EST Registrar. 5.1. INSERT_TEXT_FROM_FILE ietf-voucher-redirected-tree.txt END 5.2. INSERT_TEXT_FROM_FILE ietf-voucher-redirected@DATE.yang END </del> <ins> RFC8366bis contains the two needed voucher extensions: est-domain and additional-configuration which are needed when a client is redirected to a local EST Registrar. </ins> 6. <del> 6.1. This document registers one URI in the IETF XML registry RFC3688. Following the format in RFC3688, the following registration is requested: 6.2. This document registers two YANG modules in the YANG Module Names registry RFC6020.  Following the format defined in RFC6020, the the following registration is requested: </del> <ins> This document makes no IANA requests. </ins> 7.

Discussion:
This reflects that all YANG activity has been rolled up into draft-ietf-anima-rfc8366bis.
the YANG contains "RFC XXXX: Voucher Profile for Cloud redirected Devices" - it seems the name needs updating and there should be an RFC ednote here saying the reference is "this RFC". Correct?YANG contains this: description "Base the constrained voucher upon the regular one"; This looks like a copy/paste leftover from constrained-voucher; correct that it should be modified? (Would this also bump the YANG version and date then?) YANG description for leaf "est-domain" does not explicitly say the word "EST server" which I think it should. So this URI directs to the EST server in the owner's URL YANG support the use case of combining the voucher-constrained format (that extends base voucher) and the voucher-redirected format (from current draft) ? Would that require yet another new YANG module?
Also, the YANG extensions need to move to RFC8366bis! URL
Change:
messages encoded as MLSPlaintext objects in cases where it is necessary for the delivery service to examine such messages. <del> The remainder of this section describe how to compute the signature </del> <ins> The remainder of this section describes how to compute the signature </ins> of an MLSPlaintext object and how to convert it to an MLSCiphertext object.  The overall process is as follows:

Discussion:
I don't like the pattern of having a marker byte followed by zero-padding. It has to be parsed manually, backwards, unlike every other object in the protocol which all follow a common format.
Agreement at the interim was that people don't care about the overhead (for now), so we're going to go with the simpler, TLS-syntax-based structure.
Here's the Weekly Digest for : - - Last week 18 issues were created. Of these, 3 issues have been closed and 15 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 5 comments. - - Last week, 10 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 4 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: :bustin_silhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
To provide additional information for the designated experts, IANA [SHALL add/has added] the following note: <ins> The role of the designature expert is described in [this-RFC]. </ins> The designated expert RFC8126 ensures that the specification is publicly available.  An Internet Draft that is posted and never published or a standard in another standards body, industry <del> consortium, university site, etc. suffices.  The expert also verifies that the label is a string consisting of printable ASCII </del> <ins> consortium, university site, etc. suffices.  The expert may provide more in depth reviews, but their approval should not be taken as an endorsement of the exporter.  The expert also verifies that the label is a string consisting of printable ASCII </ins> characters beginning with "EXPORTER".  IANA MUST also verify that one label is not a prefix of any other label.  For example, labels "key" or "master secretary" are forbidden.

Discussion:
This change aligns the DE text and adds more info about what the DE does and doesn't do. It also capitalizes "Recommended" so that it's more clear that we're referring to the column. NAME PTAL
LGTM, thanks for unifying the DE language.
Change:
1. <del> Deprecation of an HTTP resource (Section 2 of HTTP) communicates information about the lifecycle of a resource.  It encourages applications to migrate away from the resource, discourages applications from forming new dependencies on the resource, and informs applications about the risk of continuing dependence upon the resource. </del> <ins> Deprecation of an HTTP resource (HTTP) communicates information about the lifecycle of a resource.  It encourages applications to migrate away from the resource, discourages applications from forming new dependencies on the resource, and informs applications about the risk of continuing dependence upon the resource. </ins> The act of deprecation does not change any behavior of the resource. It informs clients of the fact that a resource is deprecated.  The

Discussion:
This repo wasn't set up with the automated tooling; this PR corrects that, and fixes up a few other small things.
it seems like there's some problem with this update, NAME URL
Fixed.
Change:
This API changes the local media state; among other things, it sets up local resources for sending and encoding media. <del> If setLocalDescription was previously called with an offer, and </del> <ins> If (1) setLocalDescription was previously called with an offer, (2) </ins> setRemoteDescription is called with an answer (provisional or final), <del> and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. </del> <ins> (3) the media directions are compatible, and (4) media is available to send, this will result in the starting of media transmission. </ins> 4.1.11.

Discussion:
clarified that there are four conditions, removed comment. issue 14
14) [rfced] Sections 4.1.9 and 4.1.10: We had trouble following the purpose of all of the "and"s in these sentences. Are four conditions set in these sentences, or fewer? Original: If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final), and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. ... If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final), and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. Possibly: If (1) setRemoteDescription was previously called with an offer, (2) setLocalDescription is called with an answer (provisional or final), (3) the media directions are compatible, and (4) media is available to send, media transmission can start. ... If (1) setLocalDescription was previously called with an offer, (2) setRemoteDescription is called with an answer (provisional or final), (3) the media directions are compatible, and (4) media is available to send, media transmission can start.
need to keep 'this will result in the starting of media transmission'
There are 4 conditions that have to be satisfied, as noted.
Change:
ID I-D.ietf-quic-invariants.  For these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2. <del> 5.2. </del> <ins> 4.2. </ins> Although the IETF has put considerable emphasis on end-to-end streaming media encryption, there are still important use cases that

Discussion:
Reverts ietf-wg-mops/draft-ietf-mops-streaming-opcons (still learning github)
Change:
For example, with a Required Insert Count of 9, a decoder receives a S bit of 1 and a Delta Base of 2.  This sets the Base to 6 and enables post-base indexing for three entries.  In this example, a <del> regular index of 1 refers to the 5th entry that was added to the </del> <ins> relative index of 1 refers to the 5th entry that was added to the </ins> table; a post-base index of 1 refers to the 8th entry. 4.5.2.

Discussion:
Since post-base index has a section separate from relative index, I do not consider post-base index a type of relative index, but a distinct category. Update text accordingly. If the consensus is that this is not the case, relative index and post-base index sections should be reworded, and a new term should be introduced for non-post-base relative index.
Change:
between an endpoint and the Key Distributor.  To establish this association, an endpoint will send DTLS-SRTP messages to the Media Distributor which will then forward them to the Key Distributor as <del> defined in I-D.jones-perc-dtls-tunnel.  The Key Encryption Key (KEK) (i.e., EKTKey) is also conveyed by the Key Distributor over the DTLS association to endpoints via procedures defined in PERC EKT [I- </del> <ins> defined in I-D.draft-ietf-perc-dtls-tunnel.  The Key Encryption Key (KEK) (i.e., EKTKey) is also conveyed by the Key Distributor over the DTLS association to endpoints via procedures defined in PERC EKT [I- </ins> D.ietf-perc-srtp-ekt-diet]. Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media

Discussion:
Changed reference to Tunnel and added an (interim) reference to Roach's PERC signaling draft
Added the actual reference to ietf-roach-perc-webrtc in the body.
LGTM
Change:
marked "No" range from "good" to "bad" from a cryptographic standpoint. <ins> CCM_8 cipher suites are not marked as Recommended.  These cipher suites have a significantly truncated authentication tag that represents a security trade-off that may not be appropriate for general environments. </ins> The designated expert RFC8126 only ensures that the specification is publicly available.

Discussion:
Addresses and .
CCM_8 has a significantly truncated authentication tag that represents a security trade-off that may not be appropriate for general environment.
I think not.
LGTM. Can you send me a PR for the TLS 1.3 spec.
Change:
keys but should still only be considered a single client. A policy on how long to allow a member to stay in a group without <del> updating its leaf keys, and whether there should be any attempt to resolve a stale leaf key before removing the member. </del> <ins> updating its leaf keys before removing them. </ins> Finally, there are some additional application-defined behaviors that are partially an individual application's decision but may overlap

Discussion:
Replaces Not compact.
When deploying MLS, the deployer/implementer needs a certain set of choices made. For example, authentication authorities, transport choices, how to interpret application data, etc. This draft could create a succinct summary format that a deployer could use as a checklist to make sure they've done the legwork necessary to be able to deploy MLS safely. this came up in the IETF 113 meeting.
If the draft describes such a summary as a template, then maybe some of the existing deployments could try filling it in, so we could see whether it's sufficient.
I actually think the answer here is fairly compact, and mostly laid out in the arch spec, so it's mainly a question of pulling together the threads. Basically, the application needs to define: An authentication service A delivery service What the content of the messages will be
compact is good and it looks like your list aligns roughly with the intuitions i opened this issue with, so that's good too. Are there any choices about cryptographic primitives that need to be decided as well (e.g. ciphersuite limitations or requirements, expected credential types)? What about MLS extensions or MLS proposals that clients connected to this deployment are expected to support or avoid?
I have no idea whether the template i outlined in is correct, let alone exhuastive. I offer it as a starting point, and won't be upset if anyone wants to step in to improve/correct it.
Really like this direction, few small tweaks.This looks good. Thanks Brendan, Thanks Richard!
Change:
candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy endpoints. <del> Similar to max-bundle, but RTCP candidates are not gathered.  This policy reduces the candidates that must be gathered to the absolute minimum, but will not be compatible with legacy endpoints that do not support RTCP mux. </del> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default BUNDLE policy MUST be set to "balanced". <ins> The application can specify its preferred policy regarding use of RTP/RTCP multiplexing RFC5761 using one of the following policies: The browser will gather both RTP and RTCP candidates but also will offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints. The browser will only gather RTP candidates.  [[OPEN ISSUE: how should the answerer behave.  https://github.com/rtcweb-wg/jsep/ issues/114]] This halves the number of candidates that the offerer needs to gather. </ins> 4.1.2. The createOffer method generates a blob of SDP that contains a

Discussion:
Justin, this isn't done, but PTAL and see if you think it's going in the right direction.
looks on right path to me
My only issue with this is what happens if you get an offer that does not do mux, I think it should be accepted regardless of what this is set to. I think this should be purely about what is generated in offer. Other than that it looks good.
We should discuss this on today's call. Justin and I spent a while on it last time and one of the relevant arguments was consistency. Specifically, say you have two endpoints, one of which is old (i.e., pre-WebRTC) and doesn't support mux at all and the other of which is set to "require", i.e., only do mux. With the current text, any attempt between these two to communicate will fail. If you only apply these polices to the offer, however: If the old endpoint is the offerer, then it will not offer mux but the WebRTC endpoint will accept it and the call will succeed. If the new endpoint is the offerer, then it will only provide mux candidates and the call will fail in a fairly ugly fashion. The point being that the current text allows you to fail fast.
lgtm
Push -f due to rebase screwup. Cullen and I discussed this PR and he is unconvinced that we should fail when the offer does not include mux but the answerer has set "require". In the interest of landing the rest of this, I have added an issue and an open issue section in the draft. URL Cullen, Justin, if this is acceptable LMK and I will merge this PR in.
This seems fine to me - good topic to discuss in Dallas, if we are still of two minds at that point.
NAME can you confirm this matches your expectations?
LGTM and this open issue is not a huge deal one way or the other
Cullen thinks it should accept and non-mux. EKR and Justin currently believe it should reject the offer.
Original text: when acting as answerer will reject any m= section that does not provide an "a=rtcp-mux" attribute.
LGTM at IETF 92
open issue in text to be removed
Change:
The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers, generally called "WebRTC" I-D.ietf-rtcweb- <del> overview.  The major use cases for WebTC technology are real-time </del> <ins> overview.  The major use cases for WebRTC technology are real-time </ins> audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems, (e.g., SIP-basedRFC3261 soft phones) WebRTC communications are directly controlled by some

Discussion:
As discussed, a couple of minor typos and corrections.
The travis failures here aren't Michael's fault.
I've looked up the missing reference dates and added them. Travis seems happier.
Change:
Note that where a regexp literal is required, the actual regexp needs to be enclosed in "/". <del> 5.3. </del> <ins> 5.4. </ins> Perform the same steps as in toESreg to obtain a valid regexp in PCRE PCRE2, the Go programming language RE2, and the Ruby programming

Discussion:
Signed-off-by: Tim Bray Based on our email thread with James, and a couple of minor editorial touch-ups.
LGTM, thanks.
Change:
Abstract An application server can use the method described to voluntarily <del> identify itself to a push service.  This identification information can be used by the push service to attribute requests that are made by the same application server to a single entity.  An application server can include additional information that the operator of a push service can use to contact the operator of the application server. This identification information can be used to restrict the use of a push subscription to a single application server. </del> <ins> identify itself to a push service.  The "vapid" authentication scheme allows a client to include its an identity in a signed token with requests that it makes.  The signature can be used by the push service to attribute requests that are made by the same application server to a single entity.  The identification information can allow the operator of a push service to contact the operator of the application server.  The signature can be used to restrict the use of a push subscription to a single application server. </ins> 1.

Discussion:
This looks a lot worse than it really is. Reflowing text causes massive diffs, which github somehow manages to make look like entirely new text.
Change:
5.8. <ins> If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false. </ins> The following steps are performed at the media engine level to apply a remote description.

Discussion:
This contains the ice-options changes as well - will take another look once that PR is merged.
looks like a straightforward change - lgtm
LGTM
JSEP defines this attribute on media level, while 5245 says it is a session level attribute. I understand that there is development ongoing here (e.g. 5245bis), but given that canTrickleIceCandidates is an API on the PeerConnection it makes more sense IMO to have ice-options:trickle on the session level than media line level. If we want this on media line line level, canTrickleIceCandidates should be a (readonly) Transceiver attribute. To that seems messy though, what would happen if Bundle is negotiated but one media line can do trickle but the other not? While the relation between the application of an Answer and canTrickleIceCandidates is spelled out, the same thing should be done for application of an Offer.
Decision on 1): simplest thing here is to move ice-options to session level, right after "An "a=msid-semantic:WMS" line MUST be added..." 2) yes, this should be put into handling a remote description, not handling an answer.
I can take this.
JSEP requires sending q=msid-semantics:WMS: If I read URL correctly, that is no longer defined, so that requirement should probably go. I'm happy to provide a PR that removes the requirement, the example usage and updates the reference, but I assume that updating the reference involves more work than just this, so I'll refrain from doing so unless I hear it would still be useful.
I think we can just remove this line, and scrub it from the examples. More work is probably needed to fix up the refs regarding a=msid, but I think this part should be easy to handle.
Change:
following message: To respond to valid output share requests, the helper first checks <del> that "batch_start" and "batch_end" are multiples of "task.batch_window" and that "batch_end - batch_start >= task.batch_window".  Next, it extracts from its state the set of input shares that fall in the window "[batch_start, batch_end)".  If the size of the batch is less than "task.batch_size", then it aborts and alerts the leader with "insufficient data".  Otherwise, it computes its output share, which has the following structure: </del> <ins> that the request corresponds to a valid collect request.  Next, it extracts from its state the set of input shares that fall in the window "[batch_start, batch_end)".  If the size of the batch is less than "task.batch_size", then it aborts and alerts the leader with "insufficient data".  Otherwise, it computes its output share, which has the following structure: </ins> Next, it encrypts its output share under the collector's HPKE public key:

Discussion:
This partially addresses the problem of preventing inter-batch replay attacks described by NAME in . Along the way, clean up the description of collect requests so that it talks about protocol messages rather than API calls (as NAME suggested).
Similar to , it should not be possible for a share to be included in more than one batch. The timestamp currently gives us some way of ensuring that reports map to at most batch, but not a way of ensuring that reports aren't included two overlapping batch windows. It's not immediately clear if include a single report in two overlapping batch windows is a problem, or if a problem only arises when these windows are disjoint. We should probably clarify what are the inter-batch requirements here and what sort of replay prevention is required.
The aggregators (either the leader or helper) can prevent the collector from getting outputs from overlapping batches by remembering batch intervals. For example, suppose the leader responded successfully to a collect request for time interval . Then suppose that, some time later, the collector requests output shares for , where . The potential privacy violation occurs because the sets of reports in each batch are non-disjoint. To prevent this, the leader might respond to the second request with an error, or it might just include the reports in .
If aggregators are meant to use the report timestamp to protect against replay, then I think it needs to appear in the AEAD-ed message constructed by the client (i.e. ). Otherwise a leader could insert arbitrary timestamps into and trick helpers into exceeding privacy budgets or double counting inputs. Additionally, a batching client could insert arbitrary values into .
I created a PR that addresses this issue partially. What's left to do is allow multiple collect requests over the same batch, as required by the PDA protocol (e.g., Hits). I have an idea for how to do this, I'll follow up with a PR.
Closed by URL