jiebi/CodeConvo huggingface dataset:
Change:
7.1. <del> Several of the challenges in this document makes use of an "authorized key" object.  Such an object is a JSON object that encodes an authorization for a specific account key to fulfill a specific challenge. A random value that uniquely identifies a challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. The account key being authorized </del> <ins> Several of the challenges in this document makes use of a key authorization string.  A key authorization expresses a domain holder's authorization for a specified key to satisfy a specified challenge, by concatenating the token for the challenge with a key fingerprint, separated by a "." character: The "JWK_Thumbprint" step indicates the computation specified in RFC7638, using the SHA-256 digest.  As specified in the individual challenges below, the token for a challenge is a JSON string comprised entirely of characters in the base64 alphabet.  The "||" operator indicates concatenation of strings. In computations involving key authorizations, such as the digest computations required for the DNS and TLS SNI challenges, the key authorization string MUST be represented in UTF-8 form (or, equivalently, ASCII). </ins> 7.2.

Discussion:
This PR updates the new challenges so that they no longer use a JSON object dictated by the server. Instead, they use a "key authorization" string that is canonically generated from the token and key for a given challenge. (And also, while we're here, changes "authorized key object" to "key authorization".)
Change:
This alert was used in previous versions of TLS.  TLS 1.3 does not include compression and TLS 1.3 implementations MUST NOT send this <del> alert when in TLS 1.3 mode. </del> <ins> alert when in TLS 1.3 mode.  This message is always fatal. </ins> Reception of a "handshake_failure" alert message indicates that

Discussion:
Expands on NAME improvements. The obsolete alerts were previously fatal and still are. Mark them as such. Also fix one of their names which is missing the "_RESERVED" in the descriptions list.
Change:
RFC4568 MUST NOT be implemented to signal SDES SRTP keying information. <del> The RFC5888 grouping framework MUST be implemented for signaling grouping information, and MUST be used to identify m= lines via the a=mid attribute. </del> <ins> RFC5888 MUST be implemented for signaling grouping information, and MUST be used to identify m= lines via the a=mid attribute. </ins> I-D.ietf-mmusic-msid MUST be supported, in order to signal associations between RTP objects and W3C MediaStreams and

Discussion:
Fixed
Cullen, I did some git history rewriting to remove the unnecessary flip-flop around this bullet entry and push -f ed.
LGTM
Section 5.1.1 R-16: TODOs should be deleted before Last Call :-) Also sugggest renumbering the trailing sentence as R-16. Section 5.1.2: Suggest using a different letter on the numbering. U-1 and U-2?
Change:
4.5.1. <del> The procedures defined in DTLS Tunnel for PERC I-D.jones-perc-dtls- tunnel establish one or more TLS tunnels between the Media </del> <ins> The procedures defined in DTLS Tunnel for PERC I-D.draft-ietf-perc- dtls-tunnel establish one or more TLS tunnels between the Media </ins> Distributor and Key Distributor, making it is possible for the Media Distributor to facilitate the establishment of a secure DTLS association between each endpoint and the Key Distributor as shown

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:
for CertificateVerify, Finished and other messages. The signature algorithm and hash algorithm MUST be a pair offered <del> in the "signature_algorithms" extension (see signature- </del> <ins> in the client's "signature_algorithms" extension (see signature- </ins> algorithms).  Note that there is a possibility for inconsistencies here.  For instance, the client might offer DHE_DSS key exchange but omit any DSA pairs from its "signature_algorithms" extension.

Discussion:
Missing semi-colon in the message definition. Also, the signature_algorithms of the client are what matter.
Change:
There are a number of scenarios where a client or RS needs to discard the OSCORE security context, and acquire a new one. <del> The client MUST discard the current security context associated with </del> <ins> The client MUST discard the current Security Context associated with </ins> an RS when: the Sequence Number space ends.

Discussion:
OCF comments.
check that re-sending token triggers nonces exchange and new security context derived.
add a implementation note about namespaces for identifiers in case several methods are used (EDHOC, ACE, others)
Change:
of unidirectional links are connected to the same bidirectional LTP on either end of the link pair. <del> [Editor's note: text below related to G.807 needs to be revised based on the published G.807 revision!] </del> 2.3.1. The OTSi is defined in ITU-T Recommendation G.959.1, section 3.2.4

Discussion:
draft-ietf-ccamp-optical-impairment-topology-URL for IETF 114 submission --> draft-ietf-ccamp-optical-impairment-topology-yang-URL Related to pull request . Addressing and resolving several open issues.
May need to rebase this branch with the master branch to make sure all the validation checks pass
Change:
The effect of Selection Properties can be queried on Connections and Messages <del> Note that Configuring Connection Properties and Message Properties on </del> <ins> Note that configuring Connection Properties and Message Properties on </ins> Preconnections is preferred over setting them later.  Early specification of Connection Properties allows their use as additional <del> input to the selection process.  Protocol Specific Properties, see property-names, should not be used as an input to the selection process. </del> <ins> input to the selection process.  Protocol Specific Properties, which enable configuration of specialized features of a specific protocol, see Section 3.2 of I-D.ietf-taps-arch, are not used as an input to the selection process but only support configuration if the respective prototocol has been selected. </ins> 4.2.1.

Discussion:
The term Protocol Specific Properties is not well introduced. In the Arch doc we have a section about "Specialized Features" and I not added a reference and rephrased the sentence respectively. Do we need to say more than that?
LGTM modulo two nitsLooks good to me, except one nit.
Change:
Otherwise, resolve the candidate using mDNS. <del> If it resolves to an IP address, replace the value of the ICE host candidate by the resolved IP address and continue processing of the candidate. </del> <ins> If it resolves to an IP address, replace the mDNS hostname of the ICE candidate with the resolved IP address and continue processing of the candidate. </ins> Otherwise, ignore the candidate. An ICE agent may use a hostname resolver that transparently supports both Multicast and Unicast DNS.  In this case the resolution of a <del> ".local" name may happen through Unicast DNS, see RFC6762 section 3. </del> <ins> ".local" name may happen through Unicast DNS as noted in RFC6762, Section 3. </ins> An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address.

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:
The server SHOULD validate that the contact URLs in the "contact" field are valid and supported by the server.  If the server validates <del> contact URLs it MUST support the "mailto" scheme.  If the server rejects a contact URL for using an unsupported scheme it MUST return an error of type "unsupportedContact", with a description describing the error and what types of contact URLs the server considers acceptable.  If the server rejects a contact URL for using a supported scheme but an invalid value then the server MUST return an error of type "invalidContact". </del> <ins> contact URLs it MUST support the "mailto" scheme.  Clients MUST NOT provide a "mailto" URL in the "contact" field that contains "hfields" RFC6068, or more than one "addr-spec" in the "to" component.  If a server encounters a "mailto" contact URL that does not meet these criteria, then it SHOULD reject it as invalid. If the server rejects a contact URL for using an unsupported scheme it MUST return an error of type "unsupportedContact", with a description describing the error and what types of contact URLs the server considers acceptable.  If the server rejects a contact URL for using a supported scheme but an invalid value then the server MUST return an error of type "invalidContact". </ins> If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URL where such terms

Discussion:
This doesn't address the other piece of feedback, that mailto URLs can contain multiple entries.
If you don't allow , then it's only possible to have one address.
Oh, no, that's totally wrong, will update.
Change:
the "extensions" field of the "capabilities" field. The "leaf_node_source" field indicates how this LeafNode came to be <del> added to the tree. </del> <ins> added to the tree.  This signal tells other members of the group whether the leaf node is required to have a "lifetime" or "parent_hash", and whether the "group_id" is added as context to the signature.  Whether these fields can be computed by the client represented by the LeafNode depends on when the LeafNode was created. For example, a KeyPackage is created before the client knows which group it will be used with, so its signature can't bind to a "group_id". </ins> In the case where the leaf was added to the tree based on a pre- published KeyPackage, the "lifetime" field represents the times

Discussion:
This PR picks up changes from clarifying and cleaning up a few issues around LeafNode.
A big improvement in readability and correctness.
Change:
"application" and the <proto> and "fmt" fields MUST be set to exactly match the fields in the offer. <del> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", "a=candidate", "a=fingerprint", "a=dtls-id", and "a=setup" lines MUST be included under the conditions described above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp- sdp, Section 4.1. </del> <ins> Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line referencing the SCTP port number, as defined in I-D.ietf-mmusic-sctp- sdp, Section 5.1, and, if appropriate, an "a=max-message-size" line, as defined in I-D.ietf-mmusic-sctp-sdp, Section 6.1. As discussed above, the following attributes are included only if the m= section is not bundled into another m= section: "a=ice-ufrag", "a=ice-pwd", "a=fingerprint", "a=dtls-id", and "a=setup". </ins> If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as

Discussion:
NAME revised
Fixed by
Maybe in create-answer as well
The "Initial Offers" section does not distinguish systematically between requirements that apply for any type of offer and the ones that apply only to mediastreams. For instance: I think this should apply both to mediastreamtrack and to datachannels. Then many of the rules described under "Each m= section MUST include the following attribute lines:" seem specific to mediastreams, but not all; and that set of rules is then followed by a statement that a m= section must be created for data channels. This could use some reorganization and clarification.
Agree this could be refactored a bit. Magnus had a similar comment in the past.
Suggest contact with Magnus or Jessep for potential language.
I think this is mostly editorial and as such probably needs to be resolved within the author team.
Can this be considered fixed now? The createOffer section has since been structured into "here's what you generate for each RtpTransceiver", "here's what you generate if there's a data channel". And the data channel requirements look complete to me:
I agree with NAME NAME shall we close this?
I think the concern was that the data channel paragraphs feel a bit like an afterthought. I think this could be improved, but I don't think the current situation is dire.
I can live with the current text as is. Done is a feature and I don't think this will cause any interoperability problems.
This text has been improved as of PR . If we can and this text still reads well, I think we can close this issue.
Pending resolution of
is it's own bug. I think we an just close this and any changes needed can be dealt with by
I want to take one last editorial pass over the text once lands. This is a purely editorial issue at this point.
Change:
Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, <del> HTTP/3 (QUIC-HTTP Sections 3.2 and 3.3) specifies the use of ALPN RFC7301 for service discovery which allows the server to use and announce a different port number.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the binding to QUIC as well as the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </del> <ins> HTTP/3 (QUIC-HTTP Sections 3.1.1 and 3.1.2) specifies the use of HTTP Alternative Services for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the "h3" ALPN token RFC7301.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the binding to QUIC as well as the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </ins> Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of

Discussion:
It still says ALPN, though. ALPN doesn't have anything to do with using different ports; it has to do with using different protocols on the same port.
Yes, Martin already pointed this out. Fixed now. Do we need to say still more about ALPN?
I think that this refers to Alt-Svc (RFC 7838), which is mentioned in . You might also mention the not-yet-done SVCB record, but that might not be a good idea if you like the idea of publishing this.
SVCB record would just be an informational reference, no? So that shouldn't hold up publication. In this case I'd be okay to provide a pointer.
What do you meant by "ALPN doesn't enable use of other ports"?
The text here says "specifies the use of ALPN for service discovery which allows the server to use and announce a different port number". ALPN is not a service discovery mechanism, it's a protocol selection mechanism. ALPN is completely orthogonal to choice of ports. The purpose of ALPN is for client and server to agree on the protocol that is used. Your change to references in won't fix this issue. It does correctly cite the Alt-Svc sections of HTTP/3, but the surrounding text still says ALPN.
Change:
RFC3261 defines both a "Parallel Search" and "Sequential Search". Although these are primarily signaling level issues that are outside the scope of JSEP, they do have some impact on the configuration of <del> the media plane which is relevant.  When forking happens at the </del> <ins> the media plane that is relevant.  When forking happens at the </ins> signaling layer, the Javascript application responsible for the signaling needs to make the decisions about what media should be sent or received at any point of time, as well as which remote endpoint it

Discussion:
LGTM
LGTM with nit above
URL Justin to respond on the list and the changes to be attached to this issue.
Editorial changes: Section 3.2, Paragraph 4 Should read "only after an offer". yep Section 3.4.2, Paragraph 1 "... the number of media streams for which to gather candidates." ok, not a fan of ending a sentence with a preposition, I see. I'll go along with this one. Section 3.5, Paragraph 1 Should say, "... the media plane that is relevant." yep Section 4.1.5, Paragraph 2 and 3 Maybe I'm alone on this but I prefer the following: "Calling this API changes the local media state." The API doesn't do anything on its own, but is a mechanism for calling some action. (Same issue as above) "The candidate gathering process is indirectly controlled through this API." Will think this over. Overall, want to be consistent in how the term 'API' is used. Section 5.2.1, Paragraph 4 "into which it is being bundled." ok Section 5.2.1, Paragraph 5 Space needed after RFC reference. yep Section 5.2.1, Paragraph 7, bullet 6 "of" yep Section 5.2.1, Paragraph 7, bullet 11 "specified" yep Section 5.3.1, Paragraph 7 "URL then be generated..." yep Section 5.3.1, Paragraph 7, bullet 4 "... and there is a local MediaStreamTrack that has been associated ..." indeed, not my best work Section 5.3.1, Paragraph 7, bullet 5 "... Section 3, MUST be supported." yep Section 5.3.1, Paragraph 7, bullet 6 "... the payload type of the primary..." yep Section 5.3.1, Paragraph 7, bullet 11 "... as specified in ..." yep
Change:
that the Echo option value was generated by the server; otherwise the request is not processed further.  The server MUST then calculate the round-trip time RTT = (t1 - t0), where t1 is the request receive time <del> and t0 is the transmit time of the response that included the specific Echo option value.  The server MUST only accept requests with a round-trip time below a certain threshold T, i.e. RTT < T, otherwise the request is not processed further, and an error message MAY be sent.  The threshold T is application specific, its value </del> <ins> and t0 is the time when the Echo option value was generated.  The server MUST only accept requests with a round-trip time below a certain threshold T, i.e. RTT < T.  If the server cannot verify that the Echo option value was generated by the server or the round-trip time is not below the threshold the request is not processed further, and an error message MAY be sent.  The error message SHOULD include a new Echo option.  The threshold T is application specific, its value </ins> depends e.g. on the freshness requirements of the request.  An example message flow is illustrated in echo-figure.

Discussion:
Clarifications based on Jim's review. "t0 is the time when the Echo option value was generated." "If the server cannot verify that the Echo option value was generated by the server or the round-trip time is not below the threshold the request is not processed further, and an error message MAY be sent. The error message SHOULD include a new Echo option."
Change:
The proposals included by value in an External Commit MUST meet the following conditions: <del> There MUST be a single ExternalInit proposal </del> <ins> There MUST be a single ExternalInit proposal. </ins> <del> There MUST NOT be any Update proposals </del> <ins> There MAY be a single Remove proposal, where the LeafNode in the "path" field MUST meet the same criteria as the LeafNode in an Update for the removed leaf (see update).  In particular, the "credential" in the LeafNode MUST present a set of identifiers that is acceptable to the application for the removed participant. </ins> <del> If a Remove proposal is present, then the LeafNode in the "path" field MUST meet the same criteria as the LeafNode in an Update for the removed leaf (see update).  In particular, the "credential" in the LeafNode MUST present a set of identifiers that is acceptable to the application for the removed participant. </del> <ins> There MAY be one or more PreSharedKey proposals. There MUST NOT be any other proposals. </ins> External Commits MUST be signed by the new member.  In particular, the signature on the enclosing MLSPlaintext MUST verify using the

Discussion:
The current description of external commits still leaves room for the committer to include various other proposals such as arbitrary proposals that are not Update or Remove proposals (e.g., Adds, RequiredCapability, PSK, etc.). I think we should narrow that down to a specific set of proposals (i.e. an allow list style) to keep the implementation and general protocol complexity low for external commits, both for creation and processing. The way I see it, the new joiner can always issue a follow-up commit for other proposals, but I might be missing important use-cases, so I'd be grateful for feedback on this.
I agree with the intent here. Looking through the list of proposal types, the only other one that seems like it might be useful is PSK -- I could see it being useful to prove that you have a PSK when joining from the outside. If we can add that as an option (probably in parallel to Remove), this seems good to go to me.
Would an External Commit adding yourself contain an Add or an Update Proposal?
It used to contain an proposal, but since that's pretty much redundant with the the commiter has to include, it got optimized away. So an external commit should be handled as if it contained an Add proposal, where the KeyPackage in the Add is instead in the .
Comment by NAME Why RECOMMENDED and not MUST ?
Change:
the resulting output.  The specification of bignum does explicitly allow for integers encoded with leading zeros. <del> [CREF17] JLS: Should we register both or just the cose+cbor one? </del> <ins> [CREF15] JLS: Should we register both or just the cose+cbor one? </ins>

Discussion:
The CFRG EC algorithms are currently too far in the future to keep. Remove the ad put in the to be done later document.
Change:
every QUIC packet of the current version is set to 1, for demultiplexing with other UDP-encapsulated protocols. <del> latency spin bit: the third most significant bit of first octet. However, the is only used in short packet headers.  There it will be set alternatingly to 0 or 1 by the endpoints such that tracking edge transistions can be used to passively monitor the connection RTT, see spin-usage for further details. </del> <ins> latency spin bit: the third most significant bit of first octet in the short packet header.  The spin bit is set by endpoints such that tracking edge transitions can be used to passively observe end-to-end RTT.  See spin-usage for further details. </ins> header type: the long header has a 2 bit packet type field following the Header Form bit.  Header types correspond to stages

Discussion:
Review and update text in -manageability to reflect BKK spin bit consensus: single spin bit is in the protocol spec now endpoints may opt out (discuss why; this is for any reason, not just proxies as suggested in ), endpoints should probabilistically out out to provide cover for endpoints opting out
I am working on this.
NAME what about having a privacy consideration section ?
I'm not sure this fits in the scope of the document: can you say more about what you propose to be in this section? The -manageability document is meant to be an independent user's guide to the wire image, so information on the spin bit here will be more about how to measure it, not additional guidelines on how to generate it and when not to (though such text might belong in -applicability) Please coordinate with NAME who will also be proposing text on spin measurement to bring over from draft-ietf-quic-spin-exp.
see PR
closed by merge of and