jiebi/CodeConvo huggingface dataset:
Change:
candidate would provide applications an even more reliable tracking mechanism than the private IP addresses that this specification is designed to hide.  The use of registered mDNS hostnames SHOULD be <del> scoped by origin, and have the lifetime of the page. If the generated mDNS hostname candidate does not follow the pattern described, the exposed candidate might be used for fingerprinting. If there are multiple host candidates with different IP addresses, IPv4 and/or IPv6, each results in a separate mDNS hostname candidate. The number of mDNS hostname candidates can provide a fingerprinting dimension.  If so desired an ICE agent MAY expose additional mDNS hostname candidates that are not registered. </del> <ins> scoped by origin, and SHOULD have the lifetime of the page. </ins> 3.3.

Discussion:
Fingerprinting question will be tracked in a new issue.
Merging this one with Jeroen's approval.
LGTM
Change:
The Notification Number is initialized to the Partial IV of the first successfully verified notification in response to the registration <del> request.  A client receiving a notification SHALL compare the Partial IV with the Notification Number associated to that Observe registration.  The client MUST stop processing notifications with a Partial IV which has been previously received.  Applications MAY decide that a client only processes notifications which have greater Partial IV than the Notification Number. </del> <ins> request.  A client MUST only accept at most one Observe notifications without Partial IV, and treat it as the oldest notification received. A client receiving a notification containing a Partial IV SHALL compare the Partial IV with the Notification Number associated to that Observe registration.  The client MUST stop processing notifications with a Partial IV which has been previously received. Applications MAY decide that a client only processes notifications which have greater Partial IV than the Notification Number. </ins> If the verification of the response succeeds, and the received Partial IV was greater than the Notification Number then the client

Discussion:
Solves issue (from review comments by NAME : URL)
According to Jim, the change of always including a Partial IV for notifications (both successful or errors) complicates the code too much, although it simplifies the spec, so he proposes to revert that change. Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id.
Change:
commonly accessed via JavaScript in web browsers). Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol <del> need to perform a security analysis that considers the impact of HTTP </del> <ins> need to include a security analysis that considers the impact of HTTP </ins> Datagrams and Capsules in the context of their protocol. 5.

Discussion:
Is it really the Definition that performs the security analysis? Original: Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol need to perform a security analysis that considers the impact of HTTP Datagrams and Capsules in the context of their protocol. Perhaps: Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol need to include a security analysis that considers the impact of HTTP Datagrams and Capsules in the context of their protocol.
I prefer the RFC editor suggestion here.
Same, works for me
Change:
codepoints, it does not increase ECN counts. Coalesced packets (see packet-coalesce) mean that several packets can <del> share the same IP header.  The ECN counter for the ECN codepoint </del> <ins> share the same IP header.  The ECN counts for the ECN codepoint </ins> received in the associated IP header are incremented once for each QUIC packet, not per enclosing IP packet or UDP datagram.

Discussion:
Taking Gorry's suggestions, which seem quite reasonable.
(1) NiT: /The ECN counter for the ECN codepoint received in the associated IP header are incremented once for each QUIC packet, not per enclosing IP packet or UDP datagram./ mixed singular and plural - is this /counters/? (2) I like this phrase in the security considerations also from the point of view of how to generate transport feedback for ECT(?). Can we call this out here: /QUIC endpoints ignore the ECN codepoint field on an IP packet unless at least one QUIC packet in that IP packet is successfully processed/ (3) General experiments are not permitted in RFC8311, only using experimental RFCs. I think therefore, we should be clear in the detail here: /Implementations MAY experiment with and use other strategies for use of ECN. Other methods of probing paths for ECN support are possible, as are different marking strategies. Implementations can also use the ECT(1) codepoint, as specified in {{?RFC8311}}./ I’d propose something more like this: /Other methods of probing paths for ECN support are possible, as are different marking strategies. Implementations MAY use other methods defined in RFCs, as specified in {{?RFC8311}}. Implementations that use the ECT(1) codepoint, need to perform ECN validation using this code point./
Change:
6.3. <del> For a server to use a new version in the future, clients must </del> <ins> For a server to use a new version in the future, clients need to </ins> correctly handle unsupported versions.  To help ensure this, a server <del> SHOULD include a reserved version (see versions) while generating a </del> <ins> SHOULD include a version that is reserved for forcing version negotiation (0x?a?a?a?a as defined in versions) when generating a </ins> Version Negotiation packet. The design of version negotiation permits a server to avoid maintaining state for packets that it rejects in this fashion. <del> A client MAY send a packet using a reserved version number.  This can be used to solicit a list of supported versions from a server. </del> <ins> A client MAY send a packet using a version that is reserved for forcing version negotiation.  This can be used to solicit a list of supported versions from a server. </ins> 7.

Discussion:
Section 6.3 says And then Section 15 defines two kinds of "reserved" versions, which makes the paragraph above ambiguous. ... Is the intent in Section 6.3 that a server SHOULD include a version that is reserved for forcing version negotiation (i.e., matches 0x?a?a?a?a), or SHOULD a server include a version reserved for future IETF consensus documents (i.e., matching 0x0000????). Or both?
In my opinion having an implementation that advertises possible future standards versions without actually supporting them seems wrong, what happens if the other side actually supports this version? This seems like it could deadlock or look like a bidding down attack in case the client moves to a lower version to resolve the deadlock. On the other hand, announcing standards versions helps to not ossify around the 0x?a?a?a?a pattern but to me announcing standards versions does not seem like a solution to this.
I think that some of the discussion recently has pushed us away from reserving versions for IETF use. Fixing that would make this a design issue, of course. I get the editorial point though. Doubling up on the use of "reserved" is unfortunate.
looks fine
Change:
IANA is requested to create the following three entries in the existing registry for ExtensionType (defined in RFC8446): <del> encrypted_client_hello(0xfe09), with "TLS 1.3" column values set </del> <ins> encrypted_client_hello(0xfe0a), with "TLS 1.3" column values set </ins> to "CH, EE", and "Recommended" column set to "Yes". ech_is_inner (0xda09), with "TLS 1.3" column values set to "CH",

Discussion:
and also updates the ECH version. I didn't bump the extension codepoint for "echisinner," since that seems harmless. cc NAME NAME
This new version of the draft removes the version-vector dependency, so this should be the last time we update the pinned version.
Works for me!
Change:
appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is not desired. For example, when using the Opus codec, the "usedtx=0" parameter <del> would be specified in the offer. Note that setting the "VoiceActivityDetection" parameter when generating an offer is a request to receive audio with silence suppression.  It has no impact on whether the local endpoint does silence suppression for the audio it sends. </del> <ins> would be specified in the offer.  In addition, the implementation MUST NOT use silence suppression for media it generates, regardless of whether the "CN" codecs or related fmtp parameters appear in the peer's description.  The impact of these rules is that silence suppression in JSEP depends on mutual agreement of both sides, which ensures consistent handling regardless of which codec is used. </ins> The "VoiceActivityDetection" option does not have any impact on the setting of the "vad" value in the signaling of the client to mixer

Discussion:
LGTM
I am going to land this and then make a followup PR for S 5.9.
You'll also need to update S 5.9 to ensure CN is only enabled when support is bilateral: For each specified "CN" media format, enable DTX for all supported media formats with the same clockrate, as described in [RFC3389], Section 5, except for formats that have their own internal DTX mechanisms. DTX for such formats (e.g., Opus) is controlled via fmtp parameters, as discussed in Section 5.2.3.2.
Change:
authentication with the usage of a certificate after successfully establishing the connection with a PSK. <del> 6.1. </del> <ins> 5.1. </ins> Many industrial protocols assume that PSKs are distributed and assigned manually via one of the following approaches: typing the

Discussion:
explain how tls exporter helps with KDF and mitigating selfie attacks. added text on psk identity usage.
I left it empty for Owen (NAME He was planning to contribute some text on PSK collisions (between external PSKs and between external and internal PSKs).
I'll merge and will remove it for now. Owen can add it when he gets around to his PR.
LGTM pending one orphan section!
Change:
copied from the value of the "hosts" relation and overwritten by the value of the con query parameter. <ins> Links are modelled as they are in fig-ER-WKC.  As they do not have their ".well-known/core" document associated with them any more which would originally provide its Base URI, the "con" attribute of the registration fills that gap and is used as a Base URI. </ins> 3.4. Over the last few years, mobile operators around the world have

Discussion:
This is the documenting text to the changes worked out first on the examples in . It does not (yet) contain explaining overall text, but updates the various smaller mentions of the parameter to fit together. It does change the semantics of using on a registration update, but I believe that the previous wording was not what the original authors had intended. (Previously, an endpoint registering over TCP would need to explicitly repeat its con on every update).
Change:
including a Resource Type (rt) parameter RFC6690 with the value "core.rd" in the query string.  Likewise, a Resource Type parameter value of "core.rd-lookup*" is used to discover the URIs for RD Lookup <del> operations, and "core.gp" is used to discover the URI path for RD Group operations.  Upon success, the response will contain a payload with a link format entry for each RD function discovered, indicating the URI path of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. </del> <ins> operations, and "core.rd-group" is used to discover the URI path for RD Group operations.  Upon success, the response will contain a payload with a link format entry for each RD function discovered, indicating the URI path of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. </ins> A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link

Discussion:
atomicity idempotency, Jim multiple query parameter, Fairhair deleted eps from group, Jim simple registration, hauke
Change:
IANA is also to add the following note: <ins> The designated expert RFC5226 ensures that the specification is publicly available.  The expert also verifies that the label is a string consisting of printable ASCII 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. </ins> 12. IANA is to add the following entry to the TLS Alert Registry (the

Discussion:
I'm fairly sure that I sent these in already. Was there a regression? The current build has lines that are insanely long. This corrects that (and removes a warning caused by an open bracket).
I thought I fixed it, but I guess I'd missed it. I've got a fairly long rewrite that I hope to land early next that I think also addresses these.
Hoping that this is fixed via , which is pretty big set of editorial changes.
Change:
Oblivious HTTP has limited applicability.  Many uses of HTTP benefit from being able to carry state between requests, such as with cookies <del> (RFC6265), authentication (HTTP), or even alternative services </del> <ins> (COOKIES), authentication (HTTP), or even alternative services </ins> (RFC7838).  Oblivious HTTP removes linkage at the transport layer, which is only useful for an application that does not carry state between requests.

Discussion:
Duplicate reference: RFC6265, mentioned in 'RFC6265', was also mentioned in 'COOKIES'. Duplicate reference: RFC9110, mentioned in 'SEMANTICS', was also mentioned in 'HTTP'.
Change:
The following example shows a client performing an endpoint type lookup: <del> The following example shows a client performing a domain lookup: </del> The following example shows a client performing a group lookup for all groups:

Discussion:
These changes were talked about previously in Prague and allow preservation of link relationships. A new example based on the relevant RFC6690 example shows different relevant cases (with present in the registration) in the lookup interface. The latest suggestions of bringing the endpoint interface in line with that are not included yet.
RFC5988 (web linking) describes that a statement of in the context of A means that "A has a hosted resource at B, which has the attribute C=D" (with the implied "hosts" relationship from RFC6690). The repeated entries of the pattern currently drafted for the domain lookup interface (and the analogous group lookups) are bear no such meaning, and all provide statements about the same resource. In a way, they could be collapsed into (or ). Given it then talks about the currently used resource-directory (that is ), isn't that a more straightforward to express the desired information anyway?
See issue I think we need to include the group resource location, which is returned when a group is created, in the angle brackets or "href". I also believe we shod not specify a "domain" lookup because we decided to specify domain as an attribute of a registration. There is no domain table to do lookups on...
Change:
the stream becomes unblocked, and releasing the flow control prematurely makes the decoder vulnerable to memory exhaustion attacks.  A stream becomes unblocked when the Insert Count becomes <del> unblocked when the Insert Count becomes greater than or equal to the Required Insert Count for all encoded field sections the decoder has started reading from the stream. </del> <ins> greater than or equal to the Required Insert Count for all encoded field sections the decoder has started reading from the stream. </ins> When processing encoded field sections, the decoder expects the Required Insert Count to equal the lowest possible value for the

Discussion:
The repeated "when" clauses in this sentence make it difficult to parse. If our suggestion does not correctly capture your intent, could you please rephrase? Original: A stream becomes unblocked when the Insert Count becomes unblocked when the Insert Count becomes greater than or equal to the Required Insert Count for all encoded field sections the decoder has started reading from the stream. Perhaps: A stream becomes unblocked when the Insert Count becomes unblocked. When the Insert Count becomes greater than or equal to the Required Insert Count for all encoded field sections, the decoder has started reading from the stream.
It actually looks as though the words "becomes unblocked when the Insert Count" are duplicated, which would make the corrected text: That might still be confusing, but the proposed text certainly isn't the right change. The key point to capture is: The decoder has started reading at least one encoded field section from the stream and encountered a Required Insert Count value in some or all of them which exceeds its current Insert Count. This caused the stream to be considered blocked. When the Insert Count is greater than or equal to the RIC value from all of the encoded field sections the decoder has attempted to process, the stream becomes unblocked.
Fixed in .
Good catch.
Change:
of a given MediaStreamTrack, which is producing video of a certain resolution, receives an "a=imageattr recv" attribute, it MUST first check to see if the original resolution meets the criteria specified <del> in the attribute, and transmit it untouched if so.  If the original resolution is too large for the attribute criteria, the sender SHOULD apply downscaling to the output of the MediaStreamTrack in order to satisfy the criteria. </del> <ins> in the attribute, and transmit it untouched if so.  Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used.  This is required regardless of whether the receiver supports performing receive-side rotation (e.g., through CVO), as it significantly simplifies the matching logic. If the original resolution is too large for the attribute criteria, the sender SHOULD apply downscaling to the output of the MediaStreamTrack in order to satisfy the criteria. </ins> If the receiver requires a minimum resolution which is greater than the native resolution of the video, upscaling is needed, but this may

Discussion:
LGTM
C. Section 3.6.1: As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to at most 360p. In this case, the implemention would generate this attribute: a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] Maybe this example should discuss the minimal aspect of this. What it really is expressing in that it can handle any resolution between 16x16 pixels up to 640x360 as the longest in respective side. No limitations to any picture aspect ratio. That the examples expresses this is missing in the example text.
I think this is a realistic example, so I suggest we just add more descriptive text.
Change:
9.1. QUIC supports a server-generated Connection ID, transmitted to the <del> client during connection establishment (see Section 6.1 of QUIC). </del> <ins> client during connection establishment (see Section 7.2 of QUIC). </ins> Servers behind load balancers may need to change the Connection ID during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support

Discussion:
The ops drafts often reference the core drafts by section number; make sure these section number references are correct for the WGLC drafts.
Correcting overcorrections regarding capitalization, but this seems benign.
Change:
connections using previously established keys.  These keys do not provide protection of endpoint identities (see endpoint-privacy), nor do they provide non-repudiation (one endpoint in a connection can <del> deny the conversation).  PSK authentication security implicitly assumes one fundamental property: each PSK is known to exactly one client and one server, and that these never switch roles.  If this assumption is violated, then the security properties of TLS are severely weakened. </del> <ins> deny the conversation).  Protection of endpoint identities and protection against an endpoint denying the conversation are possible when a fresh TLS handshake is performed. PSK authentication security implicitly assumes one fundamental property: each PSK is known to exactly one client and one server, and that these never switch roles.  If this assumption is violated, then the security properties of TLS are severely weakened as discussed below. </ins> 4.1. As discussed in use-cases, there are use cases where it is desirable for multiple clients or multiple servers to share a PSK.  If this is <del> done naively by having all members share a common key, then TLS only authenticates the entire group, and the security of the overall </del> <ins> done naively by having all members share a common key, then TLS authenticates only group membership, and the security of the overall </ins> system is inherently rather brittle.  There are a number of obvious weaknesses here:

Discussion:
Resolve comments from Ben Smyth.
NAME can you please cut a new version of the draft?
Done. Revision -02 has been submitted.
I am getting a permission error when I try to set the tag for "draft-ietf-tls-external-psk-guidance-02". Everything else is done, and I have used my local file to submit the Internet-Draft. Please set the tag when you have a minute.
Change:
specifies both (i) how a client performs the operation and (ii) how other clients update their state based on it. <del> There are four major operations in the lifecycle of a group: </del> <ins> There are three major operations in the lifecycle of a group: </ins> Adding a member, initiated by a current member;

Discussion:
The operations in the lifecycle of a group has been reduced to three.
Thank you !
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 1 issues have been closed and 1 issues are still open. :greenheart: , by :heart: , by :+1: , by It received :+1: x1, :smile: x0, :tada: x0 and :heart: x0. :speaker: , by It received 1 comments. - - Last week, 3 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there were 3 stagazers. :star: :star: :star: You all are the stars! :star2: - - 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 .