jiebi/CodeConvo huggingface dataset:
Change:
For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and <del> RFC3264, Section 6.1.  The REQUIRED audio and video codecs to support are specified in I-D.ietf-rtcweb-audio (see Section 3) and I-D.ietf-rtcweb-video (see Section 5).  Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. </del> <ins> RFC3264, Section 6.1.  The audio and video codecs that MUST be supported are specified in I-D.ietf-rtcweb-audio (see Section 3) and I-D.ietf-rtcweb-video (see Section 5).  Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. </ins> If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the

Discussion:
This looks basically good. I see one missing reference and some places where I think the text might read better. Feel free to ignore my advice on the text, but you should probably fix the reference
PTAL
LGTM
Depends on resolution of FEC on mailing list
This will be dealt with in a future rev.
Justin, where are we here? Should I unmark this discuss?
Unmark as discuss since we need a proposal to discuss first (which I have the action for)
Action to write draft here listing FEC mechanisms that are MTI
Draft completed; now we just need JSEP to refer to uberti-rtcweb-fec.
Change:
Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid <del> attribute to the MID of the m= section. </del> <ins> attribute to the MID of the m= section.  If the m= section does not include a MID (i.e., the remote side does not support the MID extension), generate a value for the RtpTransceiver mid attribute, following the guidance for "a=mid" mentioned in sec.initial-offers. </ins> For each specified payload type that is also supported by the local implementation, establish a mapping between the payload

Discussion:
LGTM
PTAL
In the WebRTC 1.0 spec we have text talking about generating a mid if the remote description is missing one. That text has a faulty link to a JSEP (as described in issue w3c/webrtc-pc/issues/698). I can't seem to find any text in JSEP about this. Should there be such text? I did find text that said that an answer only should have a mid if the offer did.
OK, I agree we need some additional text in 3.5.2.1 to indicate that if a MID is not negotiated in SDP, a MID is locally generated (but not included in SDP).
Fixed by
Thank you!
Change:
optimize its behavior based on the application requirements and network conditions, without requiring changes to the applications. This flexibility enables faster deployment of new features and <del> protocols.  It can support applications by offering racing and </del> <ins> protocols, and can support applications by offering racing and </ins> fallback mechanisms, which otherwise need to be separately implemented in each application. <del> It derives specific path and protocol selection properties and </del> <ins> This API derives specific path and protocol selection properties and </ins> supported transport features from the analysis provided in RFC8095, RFC8923, and RFC8922.  The design encourages implementations underneath the interface to dynamically choose a transport protocol

Discussion:
Fix a bunch of nits
Looks good.
I would just go ahead and merge it, but, sigh, it has a conflict... I hope someone more git-savvy than me can solve this.
Looks good
Change:
A GNAP AS offering RS-facing services can publish its features on a well-known discovery document using the URL ".well-known/gnap-as-rs". <del> This endpoint contains a JSON document consisting of a single JSON object with any combination of the following optional fields: </del> <ins> This endpoint contains a JSON document RFC8259 consisting of a single JSON object with any combination of the following optional fields: </ins> The URL of the endpoint offering introspection.

Discussion:
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit 24fa4dc27f079697512f5eb15ca85b15f1c7ec62 https://deploy-preview-1--gnap-resource-servers-editors-URL
Change:
flagged and stored. If present, a single "a=rtcp" attribute MUST be parsed as <del> specified in RFC3605, Section 2.1, but its value is ignored. </del> <ins> specified in RFC3605, Section 2.1, but its value is ignored, as this information is superfluous when using ICE. </ins> If present, a single "a=msid" attribute MUST be parsed as specified in I-D.ietf-mmusic-msid, Section 3.2, and its value

Discussion:
Oh, I see: Issue .
Rewrote to remove some typos, and overall simplification
From the interim, there was some confusion on whether ignoring a=rtcp prohibited unmuxed RTCP; the intention here was that a=rtcp is superfluous because the RTCP port/IP information is carried in a=candidate lines. Suggest we just spell out this rationale explicitly.
That is, unless we use a=rtcp:0 to indicate exclusive.
This appears to be section 5.6.2's statement: If present, a single "a=rtcp" attribute MUST be parsed as specified in [RFC3605], Section 2.1, but its value is ignored. (This is no longer on page 52) Would work?
Change:
(300 Try Alternate) MUST be supported. The WebRTC implementation MAY support accessing the Internet through <del> an HTTP proxy.  If it does so, it MUST support the "ALPN" header as </del> <ins> an HTTP proxy.  If it does so, it MUST include the "ALPN" header as </ins> specified in RFC7639, and proxy authentication as described in Section 4.3.6 of RFC7231 and RFC7235 MUST also be supported.

Discussion:
Fixes URL
From Cullen Jennings, RTCWEB mailing list Feb 3 2016: I think we need to make the ALPN a bit more explicit. We agreed to include the ALPN header so that a proxy knows it might receive video packet rates tunnelled across it. However the text on this is not 100% clear. Right now it says If it does so, it MUST support the "ALPN" header as specified in [RFC7639], But some people have posted out including this header is optional in 7639 so there might be some ubiquity here about what is meant. I think we should change the word “support” to “include” to make it clear this needs to be sent to the proxy so that it would read specified in [RFC7639], I believe that correctly reflects what we intended on this. There is no requirement for the proxy to understand or do anything with this header. Old proxies will just ignore it and cary on as if it was not there.
Fixed in version -10.
Seems "support" never got changed to "include", so reopening issue.
Change:
application-experienced RTT.  RTT samples measured from the spin bit can also be used to generate RTT distribution information, including minimum RTT (which approximates network RTT over longer time windows) <del> and RTT variance (which approximates jitter as seen by the application). </del> <ins> and RTT variance (which approximates one-way packet delay variance as seen by an application end-point). </ins> 4.

Discussion:
Using the Spin Bit for Passive RTT Measurement ... Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of [acm] suggest s/any/all/ ... Since the spin bit logic at each endpoint considers only samples from packets that advance the largest packet number, signal generation itself is resistant to reordering. However, reordering can cause problems at an observer by causing spurious edge detection and therefore inaccurate (i.e., lower) RTT estimates, if reordering occurs across a spin-bit flip in the stream. [acm] thanks for mentioning this! ... Raw RTT samples generated using these techniques can be processed in various ways to generate useful network performance metrics. A simple linear smoothing or moving minimum filter can be applied to the stream of RTT samples to get a more stable estimate of application-experienced RTT. RTT samples measured from the spin bit can also be used to generate RTT distribution information, including minimum RTT (which approximates network RTT over longer time windows) and RTT variance (which approximates jitter as seen by the application). [acm] (let's avoid the clocky term "jitter", and clarify) Suggest: (which over-estimates one-way packet delay variance as seen by an application end-point).
Change:
packet; the client has to rely on the exchange that included the Retry packet for that property. <del> test-vectors-initial contains test vectors for the initial packet encryption. </del> <ins> test-vectors contains test vectors for packet encryption. </ins> 5.3.

Discussion:
Can someone please verify my work? I've written two implementations here and the values match, but I value independent validation.
NAME The value matches what quic-go is calculating. Will add this test vector as a unit test to my implementation.
Woo! I'm not as bad at this as I thought. Thanks NAME
I can also confirm that it verifies in Wireshark. (Likewise for the samples in Appendix A.)
The Retry integrity check is different than the protection for other packets, so it would make sense to include an example in the document. We need code for it in addition to the sample so that it can be updated more readily.
I also tested these vectors and it works fine. Thanks!
Change:
2.1. When used with HTTP/3, the Datagram Data field of QUIC DATAGRAM <del> frames uses the following format (using the notation from the "Notational Conventions" section of QUIC): </del> <ins> frames uses the following format: </ins> Receipt of a QUIC DATAGRAM frame whose payload is too short to allow parsing the Quarter Stream ID field MUST be treated as an HTTP/3

Discussion:
Inspired by Martin Duke's suggestion to reference integer encoding more directly, this change just sticks it all in one place and makes it clear that there is no expectation to minimally-encode varints. Styled on similar references to QUIC made in URL
Change:
that supports QUIC version 1 generates and consumes a Version Negotiation packet. <del> 6. </del> <ins> 7. </ins> It is possible that middleboxes could use traits of a specific version of QUIC and assume that when other versions of QUIC exhibit

Discussion:
Remove the normative reference to -transport in -invariants. This is an editorial change, but I'll pass it to the list. Includes some consistency updates.
Yes, but I think that - at least in principle - each should be as independent of the other as possible. Sure, -transport is a concrete instantiation of -invariants, but you can implement it without -invariants. Similarly, -invariants exists to support -transport, but it describes something bigger than it. So while we might have some pointers, you can read each without the other, which is nice.
introduced a new bespoke packet format. I don't have issues with the format itself, but as I reviewed I was surprised to see it used there without any explanation as to how to decipher it. I think it would be nicer if each document that uses this format either: References the "Notational Conventions" section from draft-ietf-quic-transport Has a "Notational Conventions" section of its own explaining this format
-- URL There is a lot more that the document leans on than the packet format grammar, so any expansion of this might explode. I tend to think that this is adequate.
I agree that the reference is sufficient, except for one aspect: We do want the invariants drafts to be readable without needing to get into the v1 spec, because the target audience is people who need to handle QUIC without regard to versions. I think it's wrong that the reference to QUIC-TRANSPORT is normative instead of informative, and this reference for conventions and definitions is the only reference in the doc that actually needs to be normative. I'm almost be more inclined to move the notation definition across, just as we ultimately did for the definition of VN, and let -transport refer to -invariants for it.
Looks good. Technically, we could reference this draft for the notation, but we don't need to if it makes transport easier to read.
Change:
message that on datagram transports is provided by the UDP/DTLS datagram layer. <del> TCP ensures reliable message transmission, so the CoAP over TCP messaging layer is not required to support acknowledgements or to </del> <ins> TCP ensures reliable message transmission, so the message layer of CoAP over TCP is not required to support acknowledgements or to </ins> detect duplicate messages.  As a result, both the Type and Message ID fields are no longer required and are removed from the CoAP over TCP message format.

Discussion:
Also updated one more case of "messaging layer" rather than "message layer of"
Consider either removing the UDP to TCP gateway section (URL) or merging into another section as an example. Given the differences in message format in UDP vs TCP, this is a topic that may be useful as an example, but left as an implementation detail of a gateway.
Good point - in Hannes's earlier draft, this was more of an example than a separate section - URL A UDP-to-TCP gateway will therefore discard all empty messages, such as empty ACKs (after operating on them at the message layer), and re- pack the contents of all non-empty CON, NON, or ACK messages (i.e., those ACK messages that have a piggy-backed response) into untyped messages (that happen to look like NON messages).
Change:
proxies, and also to support security for CoAP over different transport in a uniform way, is to provide security on application layer using an object-based security mechanism such as CBOR Encoded <del> Message Syntax (COSE) I-D.ietf-cose-msg. </del> <ins> Message Syntax I-D.ietf-cose-msg. </ins> One application of COSE is OSCOAP I-D.selander-ace-object-security, which provides end-to-end confidentiality, integrity and replay

Discussion:
I went through the overview section and updated the text. The text is already good and only a few minor changes had to be made. I believe we may need to determine (some time in the future) whether it is worthwhile to combine the introduction with the text in the overview section since there is some overlap.
I spotted a few sentences that were missing a word to make sense. I'll go through and try to fix this on Monday, unless someone else manages before me. Otherwise the changes look fine.
Change:
client" is used in this document to denote the client from which a request originates; to distinguish from clients in proxies. <ins> A message's "freshness" is a measure of when a message was sent on a time scale of the recipient.  A server that receives a request can either verify that the request is fresh or determine that it cannot be verified that the request is fresh.  What is considered a fresh message is application dependent; examplary uses are "no more than one hour ago" or "after this server's last reboot". </ins> The terms "payload" and "body" of a message are used as in RFC7959. The complete interchange of a request and a response body is called a (REST) "operation".  An operation fragmented using RFC7959 is called

Discussion:
Closes: URL The text is a mixture of the suggestions of .
From Ines' Genart review: NAME and NAME do you know of established references we could use there to avoid rolling our own definition?
Hi, Googling a bit, I think we might need to define this ourselves. Found some papers and presentations taking about freshness, but they did not define it well. Found a very mathematical definition in some other paper that we do not want to use. I suggest something like this: Freshness is a measure of the time since time since the message was sent. What is considered a fresh message is application dependent. The Echo mechanism specified in this document allow a server to calculate an upper bound for when the message was encrypted. With this bound, the server can either verify that the message is fresh (fresher than some application defined limit) or determine that it cannot be verified that the message is fresh. Cheers, John
Maybe we can slim that down and avoid talking of time too much (because yes it's time even in the event-based case, but a very odd discrete time, so might confuse people): Would that work for you?
Change:
RFC8126 is REQUIRED to register an extension with the value "Yes". IESG action is REQUIRED for a Yes->No transition. <ins> The following is from I-D.ietf-tls-tls13 and is included here to ensure aligment between these specifications. I-D.ietf-tls-tls13 also uses the TLS ExtensionType Registry originally created in RFC4366.  IANA has updated it to reference this document.  The registry and its allocation policy is listed below: IANA [SHALL update/has updated] this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes", "early_data", "cookie", "supported_versions", "certificate_authorities", "oid_filters", "post_handshake_auth", and "signature_algorithms_certs", extensions with the values defined in this document and the Recommended value of "Yes". IANA [SHALL update/has updated] this registry to include a "TLS 1.3" column which lists the messages in which the extension may appear.  This column [SHALL be/has been] initially populated from the table in Section 4.2 of I-D.ietf-tls-tls13 with any extension not listed there marked as "-" to indicate that it is not used by TLS 1.3. </ins> 9. Experience has shown that the IETF Consensus registry policy for TLS

Discussion:
NAME let me know what you think.
I.e., if you actually deploy on the Internet with these experimental code points, and you run into someone using the same code point, you're going to have a bad day. For widespread experiments, we should really be using temporary reservations of some kind instead.
NAME NAME How about we add the following note everywhere we added private use: NOTE: : As specified in {{RFC5226}}, assignments made in the Private Use space "are not generally useful for broad interoperability." It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.
LGTM.
Addressed by .
Change:
carry. An endpoint received transport parameters that were badly <del> formatted, included an invalid value, was absent even though it is mandatory, was present though it is forbidden, or is otherwise in error. </del> <ins> formatted, included an invalid value, omitted a mandatory transport parameter, included a forbidden transport parameter, or were otherwise in error. </ins> The number of connection IDs provided by the peer exceeds the advertised active_connection_id_limit.

Discussion:
Error because you were going to violate the transport parameters we negotiated. You know you were! YOU KNOW IT!
NAME said:
I guess we were missing future tense, which would have made this sentence really fun.
Change:
sequence, a Verifier evaluates an Attester and returns signed Attestation Results back to this original Attester no less frequently than a well-known interval.  This interval may also be asynchronous, <del> based on the changing of certain Evidence as described in I- D.birkholz-rats-network-device-subscription. </del> <ins> based on the changing of certain Evidence as described in I-D.ietf- rats-network-device-subscription. </ins> When a Relying Party is to receive information about the Attester's trustworthiness, the Attesting Environment assembles the minimal set

Discussion:
I want to wait until we have the new definitions being worked in the CCC nailed down. (They look like they are getting close.) Then we can just reference or copy these. Eric
WFM. I have raised to track this.
LGTM, I've left a note unrelated to the change, but close enough to maybe deserve being addressed in the same PR?
Change:
An Endpoint Object can be configured with the following identifiers: <del> Hostname (string) </del> <ins> Hostname (string): </ins> <del> Port (a 16-bit integer) or a Service (string) that maps to a port </del> <ins> Port (a 16-bit integer) or a Service (string) that maps to a port: </ins> <del> IP address (IPv4 or IPv6 address) </del> <ins> IP address (IPv4 or IPv6 address): </ins> <del> Interface (string name) </del> <ins> Interface name (string): </ins> An Endpoint cannot have multiple identifiers of a same type set. That is, an endpoint cannot have two IP addresses specified.  Two

Discussion:
Fix a bunch of nits
Looks good.
I would just go ahead and merge it, but, sigh, it has a conflict... I hope someone more git-savvy than me can solve this.
Looks good
Change:
generation function, if the Forward Secrecy extension is taken into use.  It will also at the same time indicate the used or desired ECDHE group.  A new attribute is needed to carry this information, as <del> AT_KDF carries the legacy KDF value which is still used together with the forward secrecy KDF value.  The legacy KDF value is also used by </del> <ins> AT_KDF carries the basic KDF value which is still used together with the forward secrecy KDF value.  The basic KDF value is also used by </ins> those EAP peers that cannot or do not want to use this extension. <ins> This specification only specifies the behaviour relating to the following combinations of basic KDF values and forward secrecy KDF values: The basic KDF value in AT_KDF is 1, as specified in RFC5448 and RFC9048, and the forward secrecy KDF values in AT_KDF_FS are 1 or 2, as specified below and in kdf2. Any future specifications that add either new basic KDF or new forward secrecy KDF values need to specify how they are treated and what combinations are allowed.  This requirement is an update to how RFC5448 and RFC9048 may be extended in the future. </ins> The format of the AT_KDF_FS attribute is shown below. The fields are as follows:

Discussion:
I'm flying later today and unsure about how much I can do on Monday. I will need to deploy this change and submit the draft.
ATKDF carries the legacy KDF value for those EAP peers that cannot or do not want to use this extension. Gives the impression that ATKDF is ignored when ATKDFFS is used... Gives the impression that they are used together... The Specification is clear on how to derive keys when ATKDF in {1} and ATKDF_FS in {1,2} but does not give any descriptions on how other combinations are supposed to work.
I don't know how this is supposed to work but there are several options for how they are used together. ATKDF is completely ignored when ATKDFFS is used. ATKDF determines how to derive MK, Kaut, Kre ATKDFFS determines how to derive MKECDHE, Kre, MSK, EMSK Like 2. but the PRF used in deriving MKECDHE is determined by ATKDF.
Reasons that this need to be specified is. If someone specifies ATKDF = 2. How would that work with EAP-AKA' FS If someone wants to specify a PQC KEM for ATKDF_FS. Exactly what should they specify.
Ok this seems like a fair issues. Thanks for spotting this.
I see two options. Either we are (a) trying to be clever and split what impacts what (MK, K_aut) vs. everything else or (b) we only specify a specific combination (KDF=1 + FS=1 or 2) and explicitly say that future specs need to specify how new KDF or FS algorithms can be combined with others. Both have some drawbacks ... not sure we always want to have the same split in option a. And option b leaves out a lot of room for future extensions to forget to do this. Maybe go for option b? I will try to make a PR.
I am fine with b. The PR should make clear that this updates RFC 9048 with this new requirement.
Ok
A PR has been proposed: URL
Solved per the PR so that I can submit the draft (may not be able to work on Monday due to travel).