jiebi/CodeConvo huggingface dataset:
Change:
DTLS <del> SRTP </del> ZRTP <ins> SRTP </ins> Transport-Layer Security Protocols: QUIC

Discussion:
This revises the description of SRTP and the relation between SRTP, DTLS, and ZRTP.
If we keep that headline, we need one for DTLS-SRTP too. Yes, that was intentional. SRTP is just the record protocol. The key management is usually done by DTLS or occasionally by ZRTP.
Comment from Ekr's review of -10: Pre-Connection Interfaces […] Also, I'm not sure you want to omit tcpcrypt here, in that it does have a way to do external authentication by exporting a session ID. Also ZRTP allows for some sort of fingerprint-based auth. tcpcrypt (and I believe ZRTP) both have session caches.
ZRTP uses , compared by the users, as an external authentication mechanism (similar process to the Safety Numbers in Signal, I believe). ZRTP does maintain a session cache.
In other words, ZRTP supports interfaces to Authentication Delegation and Session Cache Management, and DTLS-SRTP does not?
Thanks for the reply. I'm okay with merging these changes as they are, or you can add that one reference for ZRTP to have both.
Change:
Alice, Bob, and Charlie create accounts with the messaging service and obtain credentials from the AS. <del> Alice, Bob, and Charlie authenticate to the MS and store some </del> <ins> Alice, Bob, and Charlie authenticate to the DS and store some </ins> keying material which can be used to encrypt to them for the first time. When Alice wants to send a message to Bob and Charlie, she <del> contacts the MS and looks up their keying material.  She uses </del> <ins> contacts the DS and looks up their keying material.  She uses </ins> those keys to establish a set of keys which she can use to send to Bob and Charlie.  She then sends the encrypted message(s) to the <del> MS, which forwards them to the ultimate recipients. </del> <ins> DS, which forwards them to the ultimate recipients. </ins> Bob and/or Charlie respond to Alice's message.  Their messages might include new keys which allow the joint keys to be updated,

Discussion:
The current naming is confusing: MS stands for "Message Switch" and "Messaging Server" but not for "Messaging Service" AS stands for "Authentication Server" and "Authentication Service". The proposed change gives: MS as "Messaging Service" (AS* + DS) AS as "Authentication Service" DS as "Delivery Service" the "Server"s being the endpoints and not the functionality
Change:
"scope" field of the authorization to the URI for that application. Authorization resources are created by the server in response to <del> certificate applications submitted by an account key holder; their URLs are provided to the client in "authorization" requirement objects.  The authorization object is implicitly tied to the account key used to sign the new-application request. </del> <ins> certificate applications or authorization requests submitted by an account key holder; their URLs are provided to the client in the responses to these requests.  The authorization object is implicitly tied to the account key used to sign the request. </ins> When a client receives an application from the server with an "authorization" requirement, it downloads the authorization resource <del> by sending a GET request to the indicated URL. </del> <ins> by sending a GET request to the indicated URL.  If the client initiates authorization using a request to the new authorization resource, it will have already recevied the pending authorization object in the response to that request. </ins> 6.5.1.

Discussion:
As discussed at IETF 96, even with the new-app flow, it is still useful to be able to request authorization outside of an issuance transaction. This PR re-adds the new-authz transaction.
Change:
By adjusting the resolution/degree of audio and video data, it can reduce transmission cost significantly. <del> 7.2.2. </del> <ins> 6.2.2. </ins> In future smart cities, Smart grids will be critical in ensuring availability and efficiency for energy saving and control in city-

Discussion:
Main change: Merged 2 sections (IoT Integrated with Edge Computing and architecture section) into a new "model" section. Updated the architecture diagram into a model diagram including the logical functions proposed by Dirk. Heavily reworded/simplified text from the previous 2 sections - I tried to keep relevant info, but removed what was redundant with the existing challenges section. The architectures (gateway vs. distributed) are shortly listed above the figure, but the rest aims to be general. Some renaming for your consideration (feel free to ignore/change): new draft title: IoT Edge Computing Challenges, Model and State-of-Art Review challenges section ("new IoT challenges" could seem a bit general): Challenges for IoT and Impacts of Edge Computing Minor: edits in abstract
Yong-Geun, Jungha, and Dirk agreed via e-mail. Since the new version has been sent to the Datatracker, I will merge.
Change:
5.2. <del> IANA is requested to create a new registry for "EKT Ciphers".  The </del> <ins> IANA is requested to create a new table for "EKT Ciphers" in the "Real-Time Transport Protocol (RTP) Parameters" registry.  The </ins> initial values in this registry are: Note to RFC Editor: Please replace RFCAAAA with the RFC number for

Discussion:
Ignoring my concern and bias over extensibility with EKT :), this looks fine.
Should the registries be part of the SDP or RTP parameters group? I.e., collected together with the other SDP parameters?
Change:
demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the application protocol and associated service to which processes <del> connect" RFC6335.  Note that the assumption that an application can be identified in the network based on the port number is less true today, due to encapsulation, mechanisms for dynamic port assignments as well as NATs. </del> <ins> connect" RFC6335.  The assumption that an application can be identified in the network based on the port number is less true today due to encapsulation, mechanisms for dynamic port assignments, and NATs. </ins> As QUIC is a general purpose transport protocol, there are no <del> requirements that servers use a particular UDP port for QUIC in general.  For applications with a fallback to TCP which do not already have an alternate mapping to UDP, the registration (if necessary) and use of the UDP port number corresponding to the TCP port already registered for the application is RECOMMENDED.  For example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. Applications should define an alternate endpoint discovery mechanism </del> <ins> requirements that servers use a particular UDP port for QUIC.  For applications with a fallback to TCP that do not already have an alternate mapping to UDP, the registration (if necessary) and use of the UDP port number corresponding to the TCP port already registered for the application is RECOMMENDED.  For example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. Applications could define an alternate endpoint discovery mechanism </ins> 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 </del> <ins> HTTP/3 (QUIC-HTTP Sections 3.2 and 3.3) specifies the use of ALPN </ins> 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,

Discussion:
Quite a few pieces of text in here that needed corrections. As before, I'm happy to pull out individual commits so we can discuss.
Change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> For more information about time scales, see Appendix E of RFC1305, Section 3 of ISO8601, and the appropriate ITU documents ITURTF460-6. </del> <ins> For more information about time scales, see RFC1305, Section 3 of ISO8601, and the appropriate ITU documents ITU-R-TF.460-6. </ins> 3.

Discussion:
I looked through the inline comments as well. Should we file issues for all of these?
I think we should have a quick check if we can resolve any of these between us, and then make issues. Grüße, Carsten
(Many of the comments are really editorial. E.g., if you have a “BCP47 extensions registry” in mind, we can simply point to that; I just couldn’t find that.) I think I’ll submit the -01 now anyway, so we do have a new version to look at for the interim. Grüße, Carsten
Perfect, thanks. I'll try to see how many of the comments can be trivially resolved.
Please confirm -01; we can submit a -02 quickly after that (I-D deadline 2021-10-25!).
-01 is published o/
Perfect, thanks for the changes! They look great, and I apologize for the issues especially with the references, Metanorma was not making my life any easier.
Change:
space ID, it MUST treat this as a connection error of type MP_PROTOCOL_VIOLATION and close the connection. <ins> When using a single packet number space, endhosts MUST NOT send ACK_MP frames.  If an endhost receives an ACK_MP frame while a single packet number space was negotiated, it MUST treat this as a connection error of type MP_PROTOCOL_VIOLATION and close the connection. </ins> 10. Multi-path QUIC transport error codes are 62-bit unsigned integers

Discussion:
When negotiating the use of a single packet number space, it is not clear whether the use of ACKMP frame is acceptable or not. Should we only stick to ACK frames and consider reception of ACKMP frames to be MPPROTOCOLVIOLATION error? Or should we tolerate their reception if the packet number space identifier is 0?
Ah good point. I moved the text about ACKMP this morning because I assumed that you would only implement this frame if you use multiple packet number spaces. If that's the case receiving an ACKMP with enablemultipath=2 should be a PROTOCOLVIOLATION and we should specify that.
Look good to me.
Change:
application_[i]_[j]_key and application_[i]_[j]_nonce. <del> Concretely, suppose we have the following AS Tree. </del> <ins> Concretely, suppose we have the following AS Tree and ratchet for participant D: </ins> Then if a client uses key KD1 and nonce ND1 during epoch n then it must consume (at least) values G, F, D0, D1, KD1, ND1 as well as the update_secret and init_secret used to derive G (i.e. the <del> application_secret). </del> <ins> application_secret).  The client MAY retain (i.e., not consume) the values KD0 and ND0 to allow for out-of-order delivery, and SHOULD retain D2 to allow for processing future messages. </ins> 11.4.

Discussion:
This PR implements a collection of comments on . It aims to achieve the goal stated by NAME of having every derivation have a different relationship, but with a simpler construction.
Ok, I think this is good enough : )
Change:
Group.  As noted in groups, this property is not entangled when Connections are cloned, i.e., changing the Priority on one Connection in a Connection Group does not change it on the other Connections in <del> the same Connection Group.  See priority-in-taps. </del> <ins> the same Connection Group.  No guarantees of a specific behavior regarding Connection Priority are given; a transport system may ignore this property.  See priority-in-taps for more details. </ins> 7.1.3.

Discussion:
… and move the group limit connection property to the right place (it was misplaced). Note that section 8.2.7 ("Priority in TAPS") already clarifies that a Connection Priority choice doesn't guarantee a certain outcome; this just adds another sentence in the paragraph describing the Connection property to make it clearer (less easy to miss).
Looks ready to merge to me.
Change:
assume this. Users will often use multiple devices, e.g., a phone as well as a <del> laptop.  Different devices are represented as different clients with independent cryptographic state. </del> <ins> laptop.  The formal definition of a Group in MLS is the set of clients that have knowledge of the shared group secret established in the group key establishment phase of the protocol and have contributed to it.  Until a Member has been added to the group and contributed to the group secret in a manner verifiable by other members of the group, other members cannot assume that the Member is a member of the group.  Different devices are represented as different clients with independent cryptographic state. </ins> 3.

Discussion:
Thanks Brendan! I'll merge this modulo the deletion of the paragraph regarding "being a member" since that was specifically discussed during an interim call.
Change:
The order object returned by the server represents a promise that if the client fulfills the server's requirements before the "expires" time, then the server will issue the requested certificate.  In the <del> order object, any object in the "authorizations" array whose status is "pending" represents an authorization transaction that the client must complete before the server will issue the certificate (see identifier-authorization).  If the client fails to complete the required actions before the "expires" time, then the server SHOULD change the status of the order to "invalid" and MAY delete the order resource. </del> <ins> order object, any authorization referenced in the "authorizations" array whose status is "pending" represents an authorization transaction that the client must complete before the server will issue the certificate (see identifier-authorization).  If the client fails to complete the required actions before the "expires" time, then the server SHOULD change the status of the order to "invalid" and MAY delete the application resource. </ins> The server MUST issue the requested certificate and update the order resource with a URL for the certificate as soon as the client has

Discussion:
As discussed at IETF 97, this PR removes the "requirements" abstraction, and changes the "requirements" field in an application/order object to be an "authorizations" field. This is a replacement for .
Let's Encrypt tell me that they have had a few reports of buggy clients creating enough pending authorizations to saturate their rate limits, so they need a way for clients to clear these out. These clients are also not keeping around authorization URLs, so they can't just go them. My proposed solution would be to re-add the "authorizations" field to the account object, which got lost in the refactor in or so. Together with deactivation, enabling clients to enumerate authorization URLs would solve this problem. You could also envision a more direct solution, offering an endpoint that just deletes all pending authorizations for a client or client+identifier.
This is definitely too specific to these buggy clients. For the flow, the list of orders is sufficient. It's true that technically you can create authorizations through a separate, optional, flow. But Let's Encrypt has no plans to implement that flow, because other CAs have said they cannot / would not implement it, so Let's Encrypt implementing it would split the market. I'm inclined to say let's not complicate the protocol, and hypothetical clients that want to do the flow with some hypothetical server need to keep proper track of their authzs. Also, I think the particular issue with hitting limits for pending authzs can be solved in several ways without modifying the protocol.
If is merged, I would expect that a reasonable ACME server supporting new-authz would return an exiting authz, instead of giving a rate limit error. Or return existing authz from the beginning.
Closing as a result of WG decision at IETF 98
Change:
and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. <del> If the RtpTransceiver's RtpSender is active, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line for each encoding specified.  The "a=rid" line is specified in I-D.ietf-mmusic-rid, and its direction MUST be "send".  If the application has chosen a RID value, it MUST be used as the rid-identifier; otherwise a RID value MUST be generated by the implementation.  When generating RID values, it is RECOMMENDED that the values be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-avtext-rid, Section 11.  If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated. If the RtpTransceiver's RtpSender is active and more than one "a=rid" line has been generated, an "a=simulcast" line, with direction "send", as defined in I-D.ietf-mmusic-sdp-simulcast, Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section. </del> <ins> If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line for each encoding specified.  The "a=rid" line is specified in I- D.ietf-mmusic-rid, and its direction MUST be "send".  If the application has chosen a RID value, it MUST be used as the rid- identifier; otherwise a RID value MUST be generated by the implementation.  When generating RID values, it is RECOMMENDED that the values be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-avtext-rid, Section 11.  If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated. If the RtpTransceiver has a sendrecv or sendonly direction and more than one "a=rid" line has been generated, an "a=simulcast" line, with direction "send", as defined in I-D.ietf-mmusic-sdp- simulcast, Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section. </ins> The following attributes, which are of category IDENTICAL or TRANSPORT, MUST appear only in "m=" sections which either have a

Discussion:
Reference transceiver direction as opposed to "active" senders/receivers We initially thought there would be an "active" bit on senders/receivers to control the direction of a media description, but instead we now have a "setDirection" API on the transceiver. So we should reference that.
lgtm
Change:
jitter, which may be problematic for delay-sensitive applications. The recommended default is to Ignore this option. <del> 5.2.13. </del> <ins> 5.2.14. </ins> direction

Discussion:
Address
API should allow a preconnection property to specify if a private (IPv6) address is preferred. Outbound connections should prefer this. Listeners should avoid this.
Thank you! I was really missing this one .LGTM!
Change:
that apply to the described resource independent of which link is currently being followed.) <del> In the currently described model, the extracted data would be: </del> <ins> The model this would be converted to is: </ins> <del> If the alternative literals-with-properties approach were chosen, the extraction would produce: </del> <ins> | Subject | Predicate | Object | |------+-------+-----+ | http://.../ | rel:previous | http://.../TheBook/chapter2 | | http://.../TheBook/chapter2 | linkformat:title | "letztes Kapitel" with xml:lang "de" | {: #fig-8288-data-properties title='Information model extracted from fig-8288-orig'} </ins> <del> In CBOR serialization, both would produce the same output: </del> <ins> In CBOR serialization, this produces: </ins> 1.1.5.

Discussion:
Closes: URL In the comments there's the question of whether we need that properties of literals that are literals themselves can have properties again. Right now it does no harm, but no good either; I have no use case that's not completely contrived, and the number of properties we can round-trip through RDF is quite limited anyway.
I think we should pick the information model variation where literals can't have arbitrary outgoing statements, but only properties (that happen to be serialized just like other statements). Allowing nested statements from literals is kinda nice conceptually, but it is hard to explain (as it requires all the "blank node" explanations over again) is impractical in conversions is hard to visualize correctly Realistically, literals can have a type (if they're string-form; for everything else conversion can be guided by tags) or a language (which AIU is also a type these days when considering LTR/RTL). We might also see things like content format (for embedded representations), but if we want to carry them over to RDF, we can't do the literal attributes anyway, and I think we don't need to (because we now also have 's tags for content formats and can thus easily tag things inside CBOR). Are there any arguments we should have in an issue beforehand? Otherwise I'd start a pull request at my next CoRAL session.
While writing this up, I stumbled over which CBOR data model to pick for equivalence. Making literals identical to each other if they are identical in the CBOR generic data model seems the right thing to do (as opposed to going into the extended data model), as it is easier and stable. I think that we (or applications) can still define additional equivalences later on.
Change:
IPv6 address resolved, if one exists, or the first IPv4 address, if not. <ins> An ICE agent MAY add additional restrictions regarding the ICE candidates it will resolve using mDNS, as this mechanism allows attackers to send ICE traffic to devices with well-known mDNS names. </ins> 4. 4.1.

Discussion:
As pointed by NAME one can stuff ICE candidates with mDNS names that are not UUID. This may ease exposing some devices (URL) to some unsolicited mDNS/STUN traffic.
To be noted that a web application can currently synthesize candidates with well-known IP addresses/address ranges. Allowing non UUID mDNS resolution might ease such attacks. We should evaluate whether this is fine as is or not. One possibility would be to mandate mDNS resolution for UUID-based names only.
I am inclining towards mandating mDNS resolution for UUID-base names only. My rationale is the technique proposed is essentially intended to expose no handle to applications to tweak. A general name + .local could fall back to the path of FQDN ICE supported by unicast DNS currently, with better security scrutiny.
Implementations might use the same code path for mDNS and unicast DNS, so I am not sure this will be easy to do this distinction in practice. I would do the distinction between applications that trust the source of ICE candidates (in which case any mDNS is fine) from cases where there is no trust (web browsers typically). In the latter case, I would go with a SHOULD statement.
Started PR URL
Fixed via
Approved with a few editorial comments
Change:
While this document only defines a profile based on AES-GCM, it is possible for future documents to define further profiles with <del> different inner and outer crypto in this same framework.  For </del> <ins> different inner and outer algorithms in this same framework.  For </ins> example, if a new SRTP transform was defined that encrypts some or all of the RTP header, it would be reasonable for systems to have the option of using that for the outer algorithm.  Similarly, if a new

Discussion:
NAME added few nits to the commit
Oh, one things I think we should add ref to ABNF
Change:
Rendezvous() on a Preconnection with a source-specific multicast group address as the Local Endpoint results in an EstablishmentError. <ins> The following API calls can be used to configure a Preconnection before calling Rendezvous(): </ins> See multicast-examples for more examples. 6.1.2.

Discussion:
Fix-up multicast
Fixing the sequence of some examples vs. the text describing them, and referring to examples ("The following API calls can be used ...")
Also a great PR! :) Seriously, thanks!