jiebi/CodeConvo huggingface dataset:
Change:
An "a=dtls-id" line, as specified in I-D.ietf-mmusic-dtls-sdp Section 5.2. <ins> An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered. </ins> An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1. An "a=rtcp-rsize" line, as specified in RFC5506, Section 5.

Discussion:
LGTM
What needs to happen to finish this one ?
NAME NAME I think this reflects our discussion in the bug.
LGTM
NAME back at you
Ugh, git push failing due to airplane wifi. Will update when it succeeds
done
Where are we on this. Is this waiting for justin ?
yes, we are waiting for justin
Change:
server's length hint L (ECHCOnfig.maximum_name_length) when computing the padding as follows: <del> If L > D, add L - D bytes of padding.  This rounds to the server's advertised hint, i.e., ECHConfig.maximum_name_length. </del> <ins> If L >= D, add L - D bytes of padding.  This rounds to the server's advertised hint, i.e., ECHConfig.maximum_name_length. </ins> <del> Otherwise, add 32 - (D % 32) bytes of padding.  This rounds D up to the nearest multiple of 32 bytes. </del> <ins> Otherwise, let P = 31 - ((D - 1) % 32), and add P bytes of padding, plus an additional 32 bytes if D + P < L + 32.  This rounds D up to the nearest multiple of 32 bytes that permits at least 32 bytes of length ambiguity. </ins> In addition to padding ClientHelloInner, clients and servers will also need to pad all other handshake messages that have sensitive-

Discussion:
Consider the following values for L and D, where L is the server's hint and D is the length of the domain name. This change pads D according to the following rules. D1: D L is at least 32 elements. Thanks, NAME
cc NAME NAME NAME NAME NAME
TBH I am not sure that this is worth it, but I believe it is correct.
Section 7.2 says This has some problems: If L == D, or D > L and D % 32 == 0, this results in unnecessary padding. If L == D == 31, there is no length protection. The output is 32, and that is the only length that produces that output. The easiest solution is to replace "32 - (D % 32)" with "(L - D) & 0x1f". This pads up to the nearest L + 32*n. If it's considered important to pad to a multiple of 32, I would suggest ensuring that the initial bucket is at least 32, e.g.
Change:
A list of offered KeyShareEntry values in descending order of client preference.  This vector MAY be empty if the client is <del> requesting a HelloRetryRequest.  The ordering of values here SHOULD match that of the ordering of offered support in the "supported_groups" extension. </del> <ins> requesting a HelloRetryRequest.  Each KeyShareEntry value MUST correspond to a group offered in the "supported_groups" extension and MUST appear in the same order.  However, the values MAY be a non-contiguous subset of the "supported_groups" extension and MAY omit the most preferred groups. </ins> The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for.

Discussion:
This is a redo of PR now that PR has removed the appending rule and resolved issue .
Change:
preference using the priority fields in each SVCB record I-D.ietf- dnsop-svcb-https. <ins> If the client encounters a mandatory parameter in an SVCB record it does not understand, it MUST NOT use that record to discover a Designated Resolver.  The client can still use others records in the same response if the client can understand all of their mandatory parameters.  This allows future encrypted deployments to simultaneously support protocols even if a given client is not aware of all those protocols.  For example, if the Unencrypted Resolver returns three SVCB records, one for DoH, one for DoT, and one for a yet-to-exist protocol, a client which only supports DoH and DoT should be able to use those records while safely ignoring the third record. </ins> To avoid name lookup deadlock, Designated Resolvers SHOULD follow the guidance in Section 10 of RFC8484 regarding the avoidance of DNS- based references that block the completion of the TLS handshake.

Discussion:
To address
We should clarify that if a client doesn’t understand a mandatory parameter in an SVCB record, it MUST NOT use it as normal DoT/DoH, since it could be misinterpreting the meaning.
Concrete example might be with: "mandatory=foo,dohpath foo=[...] alpn=h2 dohpath=[...]" Where clients which don't know how to handle "foo" must ignore that RR in the RRset, which might also contain other SVCB RRs for just DoH.
Change:
4. <del> This extension is applicable for use with DTLS 1.2 and below. dtls- record12 illustrates the record format.  I-D.ietf-tls-dtls13 specifies how to carry the CID in a DTLS 1.3 record. Note that for both record formats, it is not possible to parse the records without knowing how long the Connection ID is. </del> <ins> This specification defines the DTLS 1.2 record layer format and I- D.ietf-tls-dtls13 specifies how to carry the CID in DTLS 1.3. </ins> In order to allow a receiver to determine whether a record has CID or not, connections which have negotiated this extension use a

Discussion:
Trying to address URL but also trying to expand the description a bit for clarity.
According URL all records seems to use a . Does this include the ?
Does this PR provide an improvement help? URL
Yes, it clarifies it for me.
Change:
there are no such checklists, no action is necessary. One consequence of this behavior is that in cases where ICE should <del> fail, e.g., where both sides provide candidates with unresolvable FQDNs ICE will no longer fail immediately, and only fail when the aforementioned timer expires.  However, because most ICE scenarios require an extended period of time to determine failure, the fact that some specific scenarios no longer fail fast should have minimal application impact, if any. </del> <ins> fail, e.g., where both sides provide candidates with unsupported address families, ICE will no longer fail immediately, and only fail when the aforementioned timer expires.  However, because most ICE scenarios require an extended period of time to determine failure, the fact that some specific scenarios no longer fail fast should have minimal application impact, if any. </ins> Note also that the timer is potentially relevant to the ICE nomination procedure described in RFC8445, Section 8.1.1.  That

Discussion:
I committed the change.
WHERE: All Candidates Discarded WHAT: Remove/rewrite the following: "(e.g., a candidate that contains a FQDN that fails to resolve)." WHY: It is unclear whether how/if FQDNs can be used in candidates. I think the text saying that the candidate cannot be used for some other reason is enough.
Implemented in One issue, though: The text says: "One consequence of this behavior is that in cases where ICE should fail, e.g., where both sides provide candidates with unsupported address families ICE will no longer fail immediately, and only fail when the aforementioned timer expires." ('unsupported address families' used to be 'unresolvable FQDNs', but the issue is the same) Q: If both endpoints provide candidates that can't be used, how is the timer going to help? No endpoint will send any connectivity checks, so there will be no peer-reflexive candidates.
LG with one minor text change
Change:
MitM registers account key pair B <del> Legitimate domain holder sends a new-order request signed using </del> <ins> Legitimate domain holder sends a newOrder request signed using </ins> account key A MitM suppresses the legitimate request but sends the same request

Discussion:
This PR is collecting changes to make sure we address during the editing window. Editorial clarifications only, please.
Both and are also TODO's for AUTH48.
Section 7.4 says: It should say , not . NAME Would you mind fixing this typo in this PR?
NAME Turns out the RFC editor caught that one (see ), so I don't have to fix it here :)
LGTM
Change:
After stepping each state, the Helper advances its aggregation job to the Leader's "AggregationJobContinueReq.round". <ins> If the "round" in the Leader's request is 0, then the Helper MUST abort with an error of type "unrecognizedMessage". </ins> If the "round" in the Leader's request is equal to the Helper's current round (i.e., this is not the first time the Leader has sent this request), then the Helper responds with the current round's

Discussion:
During implementation of round skew recovery in Janus ([1]), we noticed that the specification is unclear about what the helper should do if . This commit clarifies that this value is illegal and should be rejected. [1]: URL After handling , the helper's aggregation job will be on round 0, because the helper is waiting for the leader to send it the first-round broadcast prepare message, with which helper will advance to round 1. So before this commit, the applicable statement in the text was: Which means the helper would have to retransmit its first-round prepare shares, which it had previously sent in response to . This is implementable but weird: if the leader dropped the response to , then it should recover by re-sending it (I just wasted months of my life making sure that PUT to an aggregation job is idempotent). It seems simpler to me to just forbid round to be 0.
Change:
case, it does not make any changes to the TLS messages, but just blindly forwards them. <del> If the server sends a NewSessionTicket message, the corresponding PSK MUST be ignored by all other servers in the deployment when not negotiating ECH, including servers which do not implement this specification. </del> 7.1.1. It is an error for the client to offer ECH before the

Discussion:
This clause is a remnant of when we tried to partition the resumption space across ECH negotiation, which was simplified in .
Change:
2.6. <del> The causes of unpredictable usage described in sec-unpredictable were </del> <ins> The causes of unpredictable usage described in sec-unpredict were </ins> more or less the result of human choices, but we were reminded during a post-IETF 107 meeting that humans are not always in control, and forces of nature can cause enormous fluctuations in traffic patterns.

Discussion:
This is against issue 13.
Do we need anything in here about cache footprint considerations with fragmented MP4 vs. older style ts segments in multiple formats? Could be done as a separate update, but it seems possibly relevant here.
Hearing no other objections, I'll merge this. I'll leave cache footprint fmp4 considerations as a possibility for future prs and resolve this.
NAME had what I think is an excellent suggestion of one line per sentence: URL I've seen other docs use one line per paragraph, which I attempted to use in a recent commit but I kind of hate. Regardless, we should make a whitespace-only pass through the doc and make it all the same. I vote for one line per sentence. (I assume this would not include text inside bullet points and tables--not sure if there's a section of a doc somewhere about the pros and cons of different approaches?)
I'm happy to make a formatting pass and check what kramdown, etc. does with it. Do we want to land the changes in URL first, or reformat first and rebase your PR?
I guess I'm voting for land the changes first and do a whitespace format when we won't have conflicts. Should be pretty quick, right?
(*note, there is another pull request also that would be affected if we do it now: URL )
Closing, don't need to fix this (not expecting many more PRs anyway).
Pulling the TBD out of the draft text and capturing it here instead. Suggestion from mic at IETF 106 (Dave Oran + Glenn Deen responding): Pre-placement for many use cases is useful--distinguish between live vs. cacheable. "People assume high-demand == live, but not always true" with popular netflix example. Pre-placement in caches can ameliorate high-bandwidth needs without having to use e.g. multicast. Explain where it's applicable and not, and what the constraints are. URL (This probably goes in the caching section as that's written.)
+Glenn's comment: also capture latency constraints as a usability/qos part for live+popular vs. pre-recorded and expected-popular.
I would like to think that PR 30 is a start here ...
was merged, but this issue wasn't closed. Closing now ...
Change:
8. A resolver at "simple.example" that supports DNS over TLS on port <del> 853 (implicitly, as this is the default protocol and its default port): </del> <ins> 853 (implicitly, as this is its default port): </ins> A resolver at "doh.example" that supports only DNS over HTTPS (DNS over TLS is disabled): _dns.doh.example. 7200 IN SVCB 1 <del> doh.example. ( no-default-alpn alpn=h2 dohpath=/dns-query{?dns} ) </del> <ins> doh.example. ( alpn=h2 dohpath=/dns-query{?dns} ) </ins> A resolver at "resolver.example" that supports

Discussion:
This change removes the default protocol, which is currently DNS over TLS ("dot"). Several readers have expressed concern that this default is confusing.
Blocked by URL
Section 5.1 says this: The examples are all like this: RFC 6570 says this: I assume that we don't want passed in the SVCB record. Should we clarify that MUST be in relative form, i.e., just the path portion of the URI?
As a normative matter, I think this is already settled in the text, but I'm happy to improve clarity of the description.
Yeah, I think this technically covers it (), but it would be nice to say something at the start of the paragraph to specify that this is just a path segment of the URL.
approved with 1 question
Change:
has two sets of types: one for QUIC internal problems that might lead to connection closure, and one for closures initiated by the application.  An application using QUIC can define application- <del> specific error codes, e.g. see QUIC-HTTP section 8.1.  In the case of a grateful shut-down initiated by the application after application layer negotiation, a NO_ERROR code is expected.  Further, the CONNECTION_CLOSE frame provides an optional reason field, that can be used to append human-readable information to an error code.  Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar </del> <ins> specific error codes (see, for example, QUIC-HTTP, Section 8.1).  In the case of a grateful shut-down initiated by the application after application layer negotiation, a NO_ERROR code is expected.  Further, the CONNECTION_CLOSE frame provides an optional reason field, that can be used to append human-readable information to an error code. Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar </ins> capablities.  Usually application error codes are defined to be applicabile to all three frames.

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:
A test expression either tests the existence of a node designated by an embedded query (see extest) or tests the result of a function <del> expression (see fnex).  In the latter case, if the function result type is declared as "LogicalType" (see typesys), it tests whether the result is "LogicalTrue"; if the function result type is declared as "NodesType", it tests whether the result is non-empty.  If the declared function result type is "ValueType", its use in a test </del> <ins> expression (see fnex).  In the latter case, if the function's declared result type is "LogicalType" (see typesys), it tests whether the result is "LogicalTrue"; if the function's declared result type is "NodesType", it tests whether the result is non-empty.  If the function's declared result type is "ValueType", its use in a test </ins> expression is not well-typed. Comparison expressions are available for comparisons between

Discussion:
I actually ordered the two definition lists in the order the production appear in the grammar, so this is now easy to check (and I have checked it).
The section in question (and subject to some change soon) is URL The part that feels clunky to me is the first line: While not wrong, when you get into the bullet points, it feels odd that we're saying "all of the following are true" when only one things ever applies due to the conditions each item defines. We're saying we have three options, A, B, and C and then we define rules: If A, then ... If B, then ... Otherwise C, then ... (I know I made a about changing "rules" to "scenarios" in a previous PR, but each of these statements conforms to the definition I gave for a "rule.") The thing that feels weird is that we're saying they all_ must be true, which... is "correct" because the requirements are conditionally applied, but also it seems that (because of the conditions) only one ever actually applies, meaning that the other two are more "not applicable" than they are "true." Maybe if we instead said: Previous to the current text (before the type system was introduced), we had:
I was also thinking of turning this into a table.
A table could be nice, too, but the "all of following must be true" language still needs adjustment.
I agree this section is rather tedious to read.
Oh, and regardless of whether a table could be crammed into the document, it would be good to somehow check that all the permutations have been covered correctly. It's too hard to hold the possibilities in my small head while reading the current text...
Change:
off between resource commitment and overhead when determining how large a limit is advertised. <del> A receiver MAY use an autotuning mechanism to tune the frequency and </del> <ins> A receiver can use an autotuning mechanism to tune the frequency and </ins> amount of advertised additional credit based on a round-trip time estimate and the rate at which the receiving application consumes <del> data, similar to common TCP implementations. </del> <ins> data, similar to common TCP implementations.  As an optimization, sending frames related to flow control only when there are other frames to send or when a peer is blocked ensures that flow control doesn't cause extra packets to be sent. </ins> If a sender runs out of flow control credit, it will be unable to send new data and is considered blocked.  It is generally considered

Discussion:
This doesn't need normative text. This adds NAME recommendation about only sending flow control frames when there are other frames to send. Though I added another note about the peer being explicitly blocked, which I think is a useful transition to the next paragraph.
I don't think so. Flow control credits can go out with acknowledgments. The advice is there so that you don't have the MAX_DATA frame go out immediately, with a delayed ACK going out 20ms later. They can both go out together.
Bundling frames definitely makes sense, but I don’t think we need the “or when a peer is blocked” part.
Your assertion being that a blocked peer will already have to live with being blocked for a round trip, so the gain isn't worth documenting?
I’m saying that you shouldn’t let your peer become blocked under normal circumstances. I just noticed that in the corner case where the peer is blocked because the application is consuming data too slowly, it actually makes sense to not bundle the flow control update. So I guess the text is fine as is.
The text just says that sending more packets causes more packets to be sent. That is kind of obvious. Also, sending flow control with other frames isn't working if there isn't anything to ACK or anything to send once the application gets around to drain its buffer and inform transport about more credits.
Looks fine, one suggestion.
In light of the first paragraph which says that I can do whatever I want, what is the purpose of this MAY? It seems like you should either recommend that people do this or just remove the normative language.
I agree the MAY isn't doing anything here. The one thing I think should be encouraged is bundling flow control updates with other data instead of sending them in their own packets, since the frames themselves are very small.
It takes one RTT for the sender to learn that the receiver is blocked and to grant additional flow control credit, so this will lead to frequent stalls of the connection, if one receiver has nothing else to send.
Change:
1.1.4.1. <del> To illustrate the handling options for literals, a link example of RFC8288 is converted. </del> <ins> To illustrate properties of literals, a link example of RFC8288 is converted. </ins> (Note that even the conversion scheme hinted at above for RFC6690 link format makes no claims at being applicable to general purpose

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.