jiebi/CodeConvo huggingface dataset:
Change:
connection.  Connection IDs for either endpoint may change during the lifetime of a connection, with the new connection ID being negotiated via encrypted frames.  See Section 5.1 of QUIC-TRANSPORT.  Therefore, <del> observing a new Connection ID does not necessary indicate a new </del> <ins> observing a new connection ID does not necessary indicate a new </ins> connection. Server-generated connection IDs should seek to obscure any encoding,

Discussion:
We've not been capitalizing this in the main spec; so nor should this document. I've fixed those cases that I've touched in my upcoming PR, but it's going to need more work to clean up properly.
Yep, will do that after we merged the PRs. Thanks!
Change:
"proposal_type" field of a Proposal.  Clients MUST NOT implement any special processing rules for how to handle these values when receiving them, since this negates their utility for detecting <del> extensibility failures.  GREASE values MUST be handled using normal logic for processing unsupported values.  When comparing lists of capabilities to identify mutually-supported capabilities, clients MUST represent their own capabilities with a list containing only the capabilities actually supported, without any GREASE values.  In other words, lists including GREASE values are only sent to other clients; </del> <ins> extensibility failures. GREASE values MUST be handled using normal logic for processing unsupported values.  When comparing lists of capabilities to identify mutually-supported capabilities, clients MUST represent their own capabilities with a list containing only the capabilities actually supported, without any GREASE values.  In other words, lists including GREASE values are only sent to other clients; </ins> representations of a client's own capabilities MUST NOT contain GREASE values.

Discussion:
NAME and I have completed interop testing that covers all of the functionality in the spec. We found a couple of places where there were ambiguities in the spec that led to different implementation decisions, and in the process of resolving those, found a couple of errors / omissions in drarft-19. The current PSK proposal validation forbids with other than . The branch and reinit sections call for the creation of PSK proposals with types and . Given the text in the PSK section, these proposals would be invalid. This PR explicitly allows and in the specific context of those operations. (This is a little pro-forma, since the PSK proposals are only seen by the committer. But it seems good to allow the committer to have consistent PSK proposal validation logic.) The text says that Add, Remove, and ReInit proposals can be sent by external senders, but is silent about other proposal types. This PR explicitly indicates which proposal types may be originated by external senders, and adds an IANA registry column to track. GREASE values for proposal types, credential types, and extension types are defined for use in Capabilities, but nothing currently forbids their use elsewhere. This PR forbids their use in actual Proposal or Credential objects, and in GroupContext extensions. The field of the Proposal object was inconsistently referred to as both and . This PR changes it to be everywhere.
Merge when ready.
Change:
[3] https://mailarchive.ietf.org/arch/browse/mops/ <del> [4] https://datatracker.ietf.org/submit/note-well/ [5] https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s </del> <ins> [4] https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s </ins> <del> [6] https://www.youtube.com/watch?v=4_k340xT2jM&t=7m23s </del> <ins> [5] https://www.youtube.com/watch?v=4_k340xT2jM&t=7m23s </ins> <del> [7] https://www.youtube.com/watch?v=QExiajdC0IY&t=10m25s </del> <ins> [6] https://www.youtube.com/watch?v=QExiajdC0IY&t=10m25s </ins> <del> [8] https://www.youtube.com/watch?v=ZaRsk0y3O9k&t=2m48s </del> <ins> [7] https://www.youtube.com/watch?v=ZaRsk0y3O9k&t=2m48s </ins> <del> [9] https://www.youtube.com/watch?v=vDZKspv4LXw&t=17m15s </del> <ins> [8] https://www.youtube.com/watch?v=vDZKspv4LXw&t=17m15s </ins>

Discussion:
Merged after discussion with NAME ...
This was a brillant ideq, and has worked in other groups, but I can't remember any contribution that was made using this template ...
We should probably talk about how to update This document aims to provide a taxonomy of networking issues as they relate to quality of experience in internet video delivery. The focus is on capturing characteristics of video delivery that have surprised network designers or transport experts without specific video expertise, since these highlight key differences between common assumptions in existing networking documents and observations of video delivery issues in practice. NAME might suggest this (but didn't put it in -05): This document focuses is on capturing characteristics of video delivery that have surprised network designers or transport experts without specific video expertise, since these highlight key differences between common assumptions in existing networking documents and observations of video delivery issues in practice. Thoughts from NAME or NAME
Sure, that works for me.
Change:
client issues a query for "_dns.resolver.arpa" with the SVCB resource record type (64) I-D.ietf-dnsop-svcb-https. <ins> Because this query is for an SUDN, which no entity can claim ownership over, the SVCB response MUST NOT use the "." value for the SvcDomainName.  Instead, the domain name used for DoT or used to construct the DoH template MUST be provided. The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.resolver.arpa": The following is an example of an SVCB record describing a DoT server discovered by querying for "_dns.resolver.arpa": </ins> If the recursive resolver that receives this query has one or more Designated Resolvers, it will return the corresponding SVCB records. When responding to these special queries for "dns://resolver.arpa",

Discussion:
This PR addresses issues and to ensure smoother implementation and deployment (avoid name resolution deadlock and clearly illustrate why "." cannot be used for target names when discovering Designated Resolvers using the URL SUDN).
The existing examples in the document all use the "." for the SvcDomainName. Per the SVCB draft section 2.5.2, this would mean that queries for the SUDN that contain this value (".") would mean that the DoH template should use the SUDN as the domain name. While the examples do not query the SUDN, meaning the examples themselves are not erroneous, there is no useful example of the SUDN case. We need to add some examples showing an SUDN query response that carries the DoH domain name in the SvcDomainName field instead of the ".".
RFC8484 section 10, para 3 talks about the need for servers to ensure client do not need DNS lookups to validate the server's certificate to avoid deadlocks. DDR should reference this and reaffirm the need to have resolvers help clients avoid this deadlock.
Thanks! These examples are very useful!
Change:
1.5. <del> The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are used in this document.  It's not shouting; when they are capitalized, they have the special meaning defined in BCP 14 RFC2119 RFC8174. </del> <ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2.

Discussion:
Please pay special attention to b872e53 and e74ba45 when reviewing this.
LGTM with some proposed simplifying text.
Change:
To avoid conflicts between stream ids, the following procedure is recommended: the first Connection, for which the SCTP association has <del> been created, MUST always use stream id zero.  All additional </del> <ins> been created, must always use stream id zero.  All additional </ins> Connections are assigned to unused stream ids in growing order.  To avoid a conflict when both endpoints map new Connections <del> simultaneously, the peer which initiated association MUST use even stream ids whereas the remote side MUST map its Connections to odd </del> <ins> simultaneously, the peer which initiated association must use even stream ids whereas the remote side must map its Connections to odd </ins> stream ids.  Both sides maintain a status map of the assigned stream <del> ids.  Generally, new streams SHOULD consume the lowest available </del> <ins> ids.  Generally, new streams should consume the lowest available </ins> (even or odd, depending on the side) stream id; this rule is relevant when lower ids become available because Connection objects associated with the streams are closed.

Discussion:
Two items here: Normative MUST? I guess this is just a guidance document so doesn't need anything normative. There's some later "should" as well which I would generally ask the same question for. but... here we have some NORMATIVE language. That SHOULD should probably be non-capitalised to align with earlier usage. (and so on later in the document, e.g. in the SCTP description)
The first one can just be "uses the default values", without normative text. Second one can be lowercase as well. SCTP has normative SHOULDs and MUSTs that can be removed.
Change:
read the ECN codepoints from the enclosing IP packet, which is not possible on all platforms. <del> A packet detected by a receiver as a duplicate does not affect the receiver's local ECN codepoint counts; see (security-ecn) for relevant security concerns. </del> <ins> An IP packet that results in no QUIC packets being processed does not increase ECN counts.  A QUIC packet detected by a receiver as a duplicate does not affect the receiver's local ECN codepoint counts; see security-ecn for relevant security concerns. </ins> If an endpoint receives a QUIC packet without an ECT or CE codepoint in the IP packet header, it responds per generating-acks with an ACK

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:
3.4.2. RtpSenders allow the application to control how RTP media is sent. <del> In particular, the application can control whether an RtpSender is active or not, which affects the directionality attribute of the associated m= section. </del> 3.4.3. RtpReceivers allows the application to control how RTP media is <del> received.  In particular, the application can control whether an RtpReceiver is active or not, which affects the directionality attribute of the associated m= section. </del> <ins> received. </ins> 3.5.

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:
The entity message body is a JSON object consisting of the following two fields: <ins> When processing such a call, the AS MUST protect itself against SSRF attacks as discussed in security-ssrf. </ins> When receiving the request, the client instance MUST parse the JSON object and validate the hash value as described in interaction-hash. If the hash validates, the client instance sends a continuation

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: ba30f871d34a7516b6402d161b2c9a5924eafe68 Inspect the deploy log: Browse the preview:
If the client instance can cause the AS to fetch a URL, especially if that URL is dynamic, this can be used as a means to make the AS call URLs within its own protected domain and cause errors. Will need to be addressed in new security considerations paragraph.
Change:
Following the "m=" line, specific processing MUST be applied for the following non-attribute lines: <del> The "c=" line, if present, MUST be parsed as specified in RFC4566, Section 5.7, and its contents stored. </del> <ins> As with the "c=" line at the session level, the "c=" line MUST be parsed according to RFC4566, Section 5.7, but its value is not used. </ins> The "b=" line, if present, MUST be parsed as specified in RFC4566, Section 5.8, and the bwtype and bandwidth values stored.

Discussion:
NAME is this OK? NAME
lgtm with the one comment above
Ignored is the wrong word to use here. The value is not used is true but ignored is just simply not true.
Hmm.... We're not checking it and not doing anything with it. I'm happy to use another word, but I'm going to need you to suggest one. , Cullen Jennings EMAIL wrote:
NAME please r+ if you are happy. NAME please merge if you are happy.
I really don't care but it like 1 of the 3 things I raised got fixed
I see I missed the trickle thing. What else is there? , Cullen Jennings EMAIL wrote:
Around line 2216 I had another change "SHOULD be ignored" to "is not used". I think we are running into the limitations of using github for review here.
Indeed, I think I missed it. , Cullen Jennings EMAIL wrote:
NAME I think this is ready to merge if you are still happy.
LGTM
lgtm with minor change
When JSEP recommends that lines are ignored (absent some syntax validation), it violates a rule in RFC 5245 regarding mismatch processing. 5245 requires that the values for port and IP address in and correspond to a candidate that appears in the media section. Consensus in Dallas was to prohibit checking of the value in against and , which requires an explicit mention in the draft, since this is different to what 5245 says.
The sole point of mismatch processing is to allow applications to see if some SBC messed with their addresses: If the agent is not proceeding with ICE because there were a=candidate attributes, but none that matched the default destination of the media stream, the agent MUST include an a=ice- mismatch attribute in its answer. Not proceeding with ICE isn't an option here, and this is somewhat problematic with trickle ice (at least the initial 0.0.0.0 candidate), so I think ignoring makes sense.
Change:
applicable to TLS, and its usage for DTLS 1.3 is described in I- D.ietf-tls-dtls13. <del> IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType Registry".  The tls12_cid ContentType is only applicable to DTLS 1.2. </del> <ins> 10.3. IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType" registry.  The tls12_cid ContentType is only applicable to DTLS 1.2. </ins>

Discussion:
Tom Petch's review: URL
URL Some editorial quirks s.2 lacks the boiler plate of RFC8174 s.3 I found this unclear until I had understood it all (or perhaps I do not understand it) "URL again, alternately, to use a zero-length CID)." This suggests that a zero length CID is valid in Application Data which later text seems to contradict; otherwise I cannot see what this is saying. " If DTLS peers have negotiated the use of a CIDs using the ClientHello and the ServerHello messages " arguably sending a zero CID and receiving a zero CID is a successful Hello negotiation perhaps " If DTLS peers have negotiated the use of a non-zero CID in at least one direction, using the ClientHello and the ServerHello messages" "The DTLS peers determine whether incoming and outgoing messages need.." seems not to cater for unidirectional CIDs; perhaps "The DTLS peers determine whether incoming or outgoing, or both, messages need.. " s.4 /always recieve CIDs/always receive CIDs/ s.5.1 "the with Encrypt-then-MAC processing described in [RFC7366]." I do not understand why 'with' is needed s.5.2 ditto s.8 /this aspects SHOULD refuse/these aspects SHOULD refuse/ s.10 I would find this clearer as three sections for the three IANA actions new column for ExtensionType new value for ExtensionType new value for ContentType " IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in [RFC5246],.." well no; whatever you think of RFC8447 the name has changed " IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, defined in [RFC5246],.." or, if you are picky (which I am not), IANA is requested to allocate an entry to the existing "TLS "ExtensionType Values" registry, defined in [RFC5246], and renamed by RFC8447 An extra column is added but I cannot see what value should be placed in that column for existing entries. "The tls12_cid ContentType is only applicable to DTLS 1.2." Good information but I struggle to see what IANA will do with it; I see nowhere for it to go. Tom Petch >
Change:
Set the confirmed transcript hash in the new state to the value of the "confirmed_transcript_hash" in the GroupInfo. <del> Verify the confirmation MAC in the GroupInfo using the derived </del> <ins> Verify the confirmation tag in the GroupInfo using the derived </ins> confirmation key and the "confirmed_transcript_hash" from the GroupInfo.

Discussion:
This PR gets rid of the explicit HMAC reference and uses KDF.Extract instead (which internally uses HMAC). Also is renamed to .
I don't love the extra , but I can live with it.
Change:
4.6.3. <del> Protocols that provide multiplexing of streams into a single five- </del> <ins> Protocols that provide multiplexing of streams into a single four- </ins> tuple can listen both for entirely new connections (a new HTTP/2 stream on a new TCP connection, for example) and for new sub- connections (a new HTTP/2 stream on an existing connection).  If the

Discussion:
These are mostly wording changes for clarification. Feel free to cherry pick.
Can't find any problems here - this looks good.
This LGTM, many thanks!
Change:
The input plaintext for the AEAD is the token body.  The output ciphertext of the AEAD is transmitted in place of the token body. <del> The AEAD Checksum is computed as part of the AEAD encryption process, and is verified during decryption. </del> <ins> The AEAD Integrity Check Value(ICV), defined in Section 6 of RFC4106, is computed as part of the AEAD encryption process, and is verified during decryption. </ins> 7.3.2.

Discussion:
detail info: fix a typo. change AEAD checksum to AEAD ICV(defined in rfc4106)
Hi martin: is not a standard name of AEAD verification message, which should be , see section 6 of rfc4106
Change:
11.1. <del> The Connection Properties defined as independent, and available on all Connections are defined in the subsections below. </del> <ins> The Connection Properties defined as independent of the chosen protocol stack, and available on all Connections are defined in the subsections below. </ins> <del> Note that many protocol properties have a corresponding selection property, which prefers protocols providing a supporting transport feature. </del> <ins> Note that many Connection Properties have a corresponding Selection Property, which enables applications to express their preference for protocols providing a supporting transport feature. </ins> 11.1.1.

Discussion:
When reading the API draft, I noticed that in some places it was still using the outdated term "Protocol Properties" where it actually means Connection Properties or Message Properties. I replaced the terms in this PR. We do still define "Specific Protocol Properties", so I kept these.
Change:
3.3. <del> Once a connection is established, both endpoints MUST send a </del> <ins> Once a connection is established, each endpoint MUST send a </ins> Capabilities and Settings message (CSM see csm) as their first message on the connection.  This message establishes the initial settings and capabilities for the endpoint, such as maximum message

Discussion:
Partially addresses
It is analogous, because the structure of the subregistry is slightly different (additional column). We can add a sentence that the value of the additional column does not influence the choice of the policy. Good point. OK, “update” is not the right word them. Good point. It was smeared all over the document, and then we collected it in an appendix. I don’t think anyone would have a strong opposition against making it a mainline section. Should we?
In general, I prefer to separate out unrelated issues (editorial or not) to simplify tracking/closing: Regarding: There are at least three similar cases of "both endpoints" which would need to be corrected together.
NAME - Regarding Ben's comment (which you seem to concur with ...): 7.6: The "updates" in this section are confusing. I understand this to mean that the procedures for TCP and WS are identical to those for UDP except for the mentioned steps. But the language of the form of "This step from [RFC7252] is updated to:" makes it sound like this intends to actually change the language in 7252 to this new language. If the latter, then that effectively removes UDP support from 7252 as updated. This could easily be fixed by changing that to something to the effect of "When using TCP, this step changes to ..." The text actually updates RFC7252 to address all cases. I don't see how it effectively removes UDP support since the text is additive. For example: This step from [RFC7252]: If does not equal the request’s destination UDP port, include a Uri-Port Option and let that option’s value be . is updated to: If does not equal the request’s destination UDP port or TCP port, include a Uri-Port Option and let that option’s value be .
NAME - I do not feel strongly about moving Appendix A - but I'm open to suggestions. It's hard to find the right place in the flow - perhaps before/after Section 6?
This issue is partially addressed by - which I'm merging now since I'm on leave for the next two weeks. The other potential editorial changes are pending responses from NAME
Change:
Therefore, local-IDs has to be unique on each edge and relay nodes. Local-ID is unambiguously bound to the DetNet flow. <ins> [Note to Editor - again I think previous para needs to be removed] </ins> 4.2. DetNet service layer introduces packet replication and elimination

Discussion:
I have started to address the comments as agreed on the call 2nd May. Before I do a more significant edit next week I want to test out the pull mechanism,
Merged Stewart's first three commits to the master.
I wonder why we need to have/propose two approaches for the aggregation?