jiebi/CodeConvo huggingface dataset:
Change:
The "s=" and "t=" lines MUST stay the same. <ins> Each "m=" and c=" line MUST be filled in with the port and address of the default candidate for the m= section, as described in RFC5245, Section 4.3.  If no candidates have yet been gathered, the dummy values MUST be used, as described above.  [TODO: update profile UDP/TCP per default candidate] </ins> Each "a=mid" line MUST stay the same. Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless

Discussion:
Update of ekr's PR . Details: Initial offers/answers have no candidates Add canTrickle property Add text regarding a=end-of-candidates Clarify dummy/null address/port stuff
lgtm
NAME can you review this before Friday?
I'll try and carefully read this tomorrow morning but I'm running out of time for today. It looked good on my quick skim of it but I want to read it carefully but don't expect to have issues with it.
On this morning's Editor's Call we discussed the topic of what trickle indicators should appear in the SDP. The trickle draft prescribes two indicators: a=ice-options:trickle a=end-of-candidates However, as agreed at the interim, JSEP agents always do trickle and just expose a canTrickle property. Accordingly, the conclusion was to interpret a=ice-options:trickle as "I can do trickle" (this is consistent with half-trickle) and thus JSEP agents always send it, even if canTrickle=false. So, we should insert a=end-of-candidates when gathering is done to mean "I am done trickling". This means that JSEP agents will generate a=ice-options:trickle in response even to offers which do not contain it. However, offerers should already ignore that. As before, it's up to the app to wait for all the candidates before sending the offer if canTrickle=false
Agreed
Sounds good!
Fixed by
Change:
Each "a=mid" line MUST stay the same. <del> If the m= section is not bundled into another m= section (i.e., it is either not bundled or it possesses the sender's BUNDLE-tag) each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless </del> <ins> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless </ins> the ICE configuration has changed (either changes to the supported STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option (sec.icerestart was specified.  If the m= <del> section is bundled into another m= section, it MUST NOT have any ICE credentials. </del> <ins> section is bundled into another m= section, it still MUST NOT contain any ICE credentials. </ins> If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering

Discussion:
Change position of initial paragraph on handling of bundled m= sections; simplify some text; remove discussion of ICE restart option in answers.
NAME FYI
Change:
the client's account key.  The client then computes the SHA-256 digest of the key authorization. <del> The record provisioned to the DNS is the base64 encoding of this </del> <ins> The record provisioned to the DNS is the base64url encoding of this </ins> digest.  The client constructs the validation domain name by prepending the label "_acme-challenge" to the domain name being validated, then provisions a TXT record with the digest value under

Discussion:
All of the Base64 strings are actually Base64 URL encoded In the Java support for big ints the top byte is set to 0 to eliminate issues with signs. The thumbprint used here does not support that. It would be useful to mention that in the spec. I think it would help if there was an appendix with a complete example from key to key authorization to help clarify the points above.
Right, point 3 is pretty unclear and requires searching with your favorite search engine.
Change:
contains the computed signature value. <ins> The COSE structure used to create the byte stream to be signed uses the following CDDL grammar structure: </ins> How to compute a signature: Create a Sig_structure object and populate it with the appropriate fields. <del> Create the value to be hashed by encode the Sig_structure to a </del> <ins> Create the value to be hashed by encoding the Sig_structure to a </ins> byte string. Sign the hash

Discussion:
Add new tables to the end of the document about parameters which talk about types and possible column for integer indexes in the future
Change:
transport like TCP that performs return-routability checks as part of the connection establishment. <ins> DTLS implementations do not use the TLS 1.3 "compatibility mode" described in I-D.ietf-tls-tls13, Section D.4.  DTLS servers MUST NOT echo the "session_id" value from the client and endpoints MUST NOT send ChangeCipherSpec messages.  Note however that implementations MUST ignore ChangeCipherSpec messages received in unprotected records. </ins> With these exceptions, the DTLS message formats, flows, and logic are <del> the same as those of TLS 1.3.  DTLS implementations SHOULD not use the TLS 1.3 "compatibility mode" described in I-D.ietf-tls-tls13, Section D.4 and DTLS servers SHOULD ignore the "session_id" value generated by the client rather than sending ChangeCipherSpec messages.  Implementations MUST still ignore ChangeCipherSpec messages received during the handshake and at all other times SHOULD treat them as if they had failed to deprotect. </del> <ins> the same as those of TLS 1.3. </ins> 5.1.

Discussion:
I split and reordered the paragragh to maintain the integrity of the "aside from these exceptions, this is TLS 1.3".
Change:
to-end, an encryption key is derived from the end-to-end SRTP master key to encrypt header extensions as per RFC6904.  The Media Distributor will not be able use the information contained in those <del> header extensions encrypted with E2E keys.  See dolist for a related item in the To Do list. </del> <ins> header extensions encrypted with E2E keys. </ins> 4.4.

Discussion:
This is related to text that was in framework that said Investigate adding ability to enable the transmission of one-way media from a non-trusted device (e.g., announcements). One possible solution is to have the Key Distributor send an "ekt_key" message that is explicitly labeled for receive-only and giving that to announcement servers. A possible approach would be to define EKT Keys with a SPI > 32000, for example, for this purpose and endpoints should only use those EKT Keys to decrypt Full EKT Fields received from such transmitters. Endpoints would never send media with EKT Keys with those SPI values.
The other solution was to have an explicit indication in the message that delivers the EKT Key to the endpoint of announcement server. The EKT Key contains the key, cipher, MKI, etc. The KMF could add "direction" as a new field, which would be "send-only" (sent to announcement servers), "receive-only" (sent to endpoints), or "send-receive" for all the "normal" EKT Keys used in the conference between endpoints. Using SPI values to have certain meaning would work, but the device would have to know its role. That might lead to some confusion. So, I'd prefer an explicit indication to the device. Also, we might want to use this to admit certain endpoints into the conference (e.g., large-scale "webinars" or similar) where endpoints participating should be in listen-only mode. (Of course, any media they transmit could be discarded, but having a receive-only key makes that more explicit, too.)
Note that at IETF 96, there was no interest in working on this requirement, in part indicating that announcements, etc would come out-of-band and likely not involve media. The general sentiment was to remove this from the to do list.
We can close this open issue till there is energy to work on in the WG
Change:
A topic creator MUST include exactly one content format link attribute value (ct) in the create payload.  If the Broker does not <del> support the indicated format for both publish and subscribe, it MUST reject the operation with an error code of 4.00 "Bad Request". </del> <ins> support the indicated format for both publish and subscribe, or if there is more than one "ct" value included in the request, the Broker MUST reject the operation with an error code of 4.00 "Bad Request". Only one topic may be created per request.  If there is more than one link included in a CREATE request, the Broker MUST reject the operation with an erroro code of 4.00 "Bad Request". </ins> There is no default content format.  If no ct is specified, the Broker MUST reject the operation with an error code of 4.00 "Bad

Discussion:
removed duplicate description of hierarchy, added a constraint to allow only one topic to be created at a time, added text to allow additional target attributes in links for created topics
Change:
Errors detected by the after successfully removing encapsulation and errors detected by the MUST be sent in an .  This might be because <del> the request is malformed or the does not produce a response.  In either case the can generate a response with an appropriate error status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see HTTP and HTTP, respectively).  This response is encapsulated in the same way as a successful response. </del> <ins> the is malformed or the does not produce a response.  In either case the can generate a response with an appropriate error status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see HTTP and HTTP, respectively).  This response is encapsulated in the same way as a successful response. </ins> Errors in the encapsulation of requests mean that responses cannot be encapsulated.  This includes cases where the is incorrect or

Discussion:
We weren't always capitalizing "Encapsulated Request". This does more, in direct opposition to the changes in . If we don't take that (it seems we at an impasse there), then we should at least be consistent.
NAME I resolved conflicts, but please double check the intro paragraph that had Mark's proposed changes.
Change:
produce the final DTLSCiphertext. The outer content type of a DTLSCiphertext record carrying a CID <del> is always set to the value 25 (tls12_cid).  The actual content type of the record is found in DTLSInnerPlaintext.real_type after decryption. </del> <ins> is always set to tls12_cid(TBD2).  The real content type of the record is found in DTLSInnerPlaintext.real_type after decryption. </ins> The CID value, cid_length bytes long, as agreed at the time the extension has been negotiated.

Discussion:
URL If this PR is postponed to that date (12. April), may be the final values could be used. We have received a request for early code-point assignment of values for draft-ietf-tls-dtls-connection-id-04. We believe that only editorial changes are pending. Please respond to this list of you have concerns about these assignments by April 12, 2019. Thanks, Joe, Sean and Chris
Change:
Prefer, Require) for the level of preference of a given property during protocol selection; see selection-props. <del> 4.2. </del> <ins> 4.3. </ins> This document defines a language- and platform-independent interface to a Transport Services system.  Given the wide variety of languages

Discussion:
This PR provides usage examples of our abstract interface, to address . The examples show how an application might use Listen(), Initiate(), and Rendezvous(), send a Message, and receive a Message. There is some redundancy between these examples, and I introduces some subtle differences to make them plausible, e.g., the "server" provides its identity, and the "client" verifies the other endpoint's identity using a trust callback. Overall the section became rather long. Should we instead just stick to one example, e.g., Initiate()? (Or Rendezvous() because it covers the most aspects? Or Initiate() but with all the aspects from Rendezvous()?) Otherwise I'm particularly interested in feedback on the Rendezvous() example -- I think it's correct wrt the draft, but is there a "more plausible" port number, and should anything else be set there that is not in the Initiate() and Listen() examples?
Thanks for the review, I addressed the comments. Maybe the default for Preserve Message Boundaries should be Require as well, if we receive only complete Messages by default...
I'm good with these changes. Regarding how we show the pseudo-code, I'm not totally sure about the notation (how rigorous are we on that?), so someone else should validate it makes sense.
Similar to the way we added simple diagrams to the architecture document to make the "story" of the document more compelling, we should begin the interface document with a simple workflow for an example connection. This way, we can show concretely up front how this is simple and useful, while being quite flexible and powerful. This can also inform how we then continue to explain depth to the details.
I'm going to prepare a PR this week.
This looks good, modulo a couple of comments in the review (introduce API example notation, decide on formatting for property names). In the interests of getting this into the draft rev for Prague, though, I don't think we should block merging on these, and can clean them up in/after Prague.
Change:
contained within the RendezvousDone<> Event, and is ready to use as soon as it is passed to the application via the Event. <del> An RendezvousError occurs either when the Properties and Security </del> <ins> An EstablishmentError occurs either when the Properties and Security </ins> Parameters of the Preconnection cannot be fulfilled for rendezvous or cannot be reconciled with the Local and/or Remote Endpoints, when the Local Endpoint or Remote Endpoint cannot be resolved, when no

Discussion:
No need to have a different type of Event for initiate, listen and rendezvous.
On a PreConnection, an application uses EITHER Initiate OR Listen OR Rendezvous. Therefore, it seems unnecessary to distinguish between three types of errors. Shouldn't we have a general per-PreConnection "UnfulfilledError" instead of the InitiateError + ListenError + RendezvousError, just to shorten things a bit? An application needs more details (reasons), but it gets them as a parameter anyway when the new "UnfulfilledError" would occur.
Change:
the validation is still in progress, the server MUST return a 202 (Accepted) response with a Retry-After header field. <del> 6.6. </del> <ins> 6.7. </ins> The holder of an authorized key pair for an identifier may use ACME to request that a certificate be issued for that identifier.  The

Discussion:
What advantage does including the old key provide?
Having the new key sign over the field makes the hand-over mutual -- the old key blesses the new key by signing over the JWS and the new key accepts by signing over the thumbprint. Basically, the field is acting as an identifier for the registration for purposes of the new key's acceptance of the hand-over. Note that this is well-defined because the server is required to only have one registration for a given key-pair (it MUST return a 409/Conflict if there's an attempt to duplicate).
Account keys should change over time to improve security. We should have a way to change the key associated with an account with changing anything else about the account. Something liike: Post: /rotate-key { "key": { / JWK key / } } Note: The request should be signed with the old key. All authorizations should remain with the account. If there are any requests being validated then they should still use the old key (as specified by the oriignal authorization request.
Change:
The "commit_secret" is the value "path_secret[n+1]" derived from the "path_secret[n]" value associated to the root node. <ins> Generate a new ClientInitKey for the Committer's own leaf.  Store it in the ratchet tree and assign it to the "client_init_key" field in the Commit object. </ins> Construct an MLSPlaintext object containing the Commit object. Use the "commit_secret" to advance the key schedule and compute the "confirmation" value in the MLSPlaintext.  Sign the

Discussion:
You can now rebase this on master for clarity.
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 3 comments. - - Last week, 8 pull requests were created, updated or merged. Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - 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 .
This looks good, just one minor clarification
Change:
endpoints in the form of messages.  Two endpoints can have multiple data channels between them. <del> An implementation of the Interactive Connectivty Establishment </del> <ins> An implementation of the Interactive Connectivity Establishment </ins> (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166).

Discussion:
This deals with some of Meral's GEN-ART comments.
I can see putting it back, but we should be consistent there were two e.g. and two for examples. My matchy-matchy tendencies getting to me.
:-) I can flip it in the other direction. Sometimes I show off my English skills, othertimes I want to write simple English. Trapped by my own filters .... the review ended up in my gen-art inbox, which I stopped reading years ago when I left the gen-art team....
No worries. I would go with whatever the RFC editor is going to end up doing, but to be honest I don’t know which they’d prefer. spt
Change:
not included in this category. epoch value (3) is used for payloads protected using keys derived <del> from the initial traffic_secret_0.  This may include handshake messages, such as post-handshake messages (e.g., a NewSessionTicket message). </del> <ins> from the initial [sender]_application_traffic_secret_0.  This may include handshake messages, such as post-handshake messages (e.g., a NewSessionTicket message). </ins> epoch value (4 to 2^16-1) is used for payloads protected using <del> keys from the traffic_secret_N (N>0). </del> <ins> keys from the [sender]_application_traffic_secret_N (N>0). </ins> Using these reserved epoch values a receiver knows what cipher state has been used to encrypt and integrity protect a message.

Discussion:
I read through the draft and amassed a number of comments. This PR resolves the easy stuff. I'll send an email to the WG list with the more interesting ones shortly. Grammar fixes.The text describing sequence number encryption doesn't say how the receiver handles short ciphertexts. It's also phrased oddly. It says "In some (rare) cases the ciphertext may be less than 16 bytes", but the whole point of the text is to ensure it cannot be less than 16 bytes. Reword it. Whether there's a Certificate message is no longer a function of the ciphersuite, but of parameters in general. (With resumption that was already true.) The bits talking about epoch 1-3 so far before the definitions of those epochs should link to the section. Remove some remnants of EndOfEarlyData. They're still in the definition of the Handshake struct. I wasn't sure how to handle that since it was in the HandshakeType enum and we probably shouldn't call it RESERVED when it exists in TLS? Spell out [sender]applicationtrafficsecret since trafficsecret isn't defined.
This looks good to me.
These changes look good to me! NAME can you please have a look?
Change:
In the event that a valid proposal is omitted from the next Commit, the sender of the proposal SHOULD retransmit it in the new epoch. <ins> A member of the group MAY send a Commit that references no proposals at all, which would thus have empty vectors for "updates", "removes", and "adds".  Such a Commit resets the sender's leaf and the nodes along its direct path, and provides forward secrecy and post- compromise security with regard to the sender of the Commit.  An Update proposal can be regarded as a "lazy" version of this operation, where only the leaf changes and intermediate nodes are blanked out. </ins> The "path" field of a Commit message MUST be populated if the Commit covers at least one Update or Remove proposal, i.e., if the length of the "updates" or "removes vectors is greater than zero.  The

Discussion:
I think we need to clearly define "FS / PCS with regard to", but once we do that, it seems like a fine phrase. That seems like a good topic for a review / update of the Security Considerations once we have the protocol mostly in shape, for which I have filed .
The not-protocol parts of the document, including security considerations and some of the operational considerations, are mostly untouched since the beginning of this work. As we get the protocol firmed up, we should revisit these parts to make sure they're up to date and give an accurate reflection of the concerns around the protocol.
One particular thing related to this that I noticed is that in the the first sentence: is outdated as (ii) can now also be an all-zero vector, namely if is not required and not set (as introduced in if I'm not mistaken).
I did a review of the Security Considerations and didn't see anything that needs fixing before WGLC. The point that NAME raises appears to have been fixed in some other PR.
Right now, it is possible to send a Commit that covers no proposals. This has the result that the leaf of the sender and its direct path are refreshed, but no other change to the tree is made. (The epoch also advances, of course.) This can be is a useful operation. For example, an Add wipes out the new joiner's direct path, so having the new joiner send a Commit over no proposals would fill in that direct path and make subsequent operations more efficient. We should clarify in some prose that (a) this is possible and (b) why it might be useful.
That works fine. I am a bit bothered by the phrasing regarding properties « with regard to ...». If you can find an alternate phrasing that would be
Change:
pointers to other documents that form part of the WebRTC suite. By reading this document and the documents it refers to, it should be <del> possible to have all information needed to implement an WebRTC </del> <ins> possible to have all information needed to implement a WebRTC </ins> compatible implementation. 2.2.

Discussion:
This deals with some of Meral's GEN-ART comments.
I can see putting it back, but we should be consistent there were two e.g. and two for examples. My matchy-matchy tendencies getting to me.
:-) I can flip it in the other direction. Sometimes I show off my English skills, othertimes I want to write simple English. Trapped by my own filters .... the review ended up in my gen-art inbox, which I stopped reading years ago when I left the gen-art team....
No worries. I would go with whatever the RFC editor is going to end up doing, but to be honest I don’t know which they’d prefer. spt