jiebi/CodeConvo huggingface dataset:
Change:
bytes of data to ascertain the link MTU and tear down the tunnel if they do not receive a response.  Unless endpoints have an out of band means of guaranteeing that the previous techniques is <del> sufficient, they MUST use this method. </del> <ins> sufficient, they MUST use this method.  If an endpoint does not know an IPv6 address of its peer, it can send the ICMPv6 echo request to the link local all nodes multicast address (ff02::1). </ins> If an endpoint is using QUIC DATAGRAM frames to convey IPv6 packets, and it detects that the QUIC MTU is too low to allow sending 1280

Discussion:
Which IPv6 address is the Client pinging through the tunnel? The Client knows which source address(es) it can use (from the ADDRESSASSIGN(s) that it has received), but not necessarily a good destination address. When ROUTEADVERTISEMENT are networks, it is not clear which hosts if any on those networks are pingable. In the flow forwarding case, there is a clear target host, but do we want to require the target to respond to ICMPv6 echo request pings lest it be unreachable on any protocol over connect-ip? Perhaps the destination address for these pings should be a special address on which the IP Proxy itself is required to respond to ICMPv6 echo requests through the tunnel?
Good question! NAME thoughts?
This was intended to be the link-local address(es)
Good catch. I'll write a PR suggesting to use the link-local all-nodes multicast address if the peer's address is unknown
Change:
4.1.8. <del> A Connection Group is a set of Connections that shares properties and caches.  A Connection Group represents state for managing Connections within a single application, and does not require end-to-end protocol signaling.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together. </del> <ins> A Connection Group is a set of Connections that shares Connection Properties and cached state generated by protocols.  A Connection Group represents state for managing Connections within a single application, and does not require end-to-end protocol signaling.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together. </ins> The API allows a Connection to be created from another Connection. This adds the new Connection to the Connection Group.  A change to

Discussion:
URL In this section - can we be clear on stating what properties we are taking about and what the caches. see the first line of the section. the second paragraph should at least mention why the connection is cloned. We haven't introduced the cloning before. we need to discuss the relation with Connection Context, does a Connection group have same connection context? My current understanding is if the Connection Context is separate then those Connections wont be grouped. But I fear that this can create confusion.
Latest merged master fixes bullet 2. The others need new text.
LGTM! Many thanks for doing this
Change:
contain information related to how they have to be modulated (4) BBFRAMEs are forwarded to the physical-layer; <del> CPE: Customer Premise Equipment; </del> <ins> CPE: Customer Premises Equipment; </ins> COM: COMmunication;

Discussion:
ACM : Adaptative Coding and Modulation; -- Adaptive. This error repeats. CPE: Customer Premise Equipment; -- Premises. (My premise is that this is unfortunate.) FEC: Forward Erasure Correction;-- FEC is traditionally Error. Redefining industry terms to suit your network coding case won't help. FLUTE: File Delivery over Unidirectional Transport;-- just ref RFC6726. bit of a pointless inclusion imo. PEP: Performance Enhanced Proxy [RFC3135]-- the title of RFC3135 is perfectly clear that it's Enhancing and the word 'Enhanced' does not appear in that document. This is not the sort of thing WGLC is for. PLFRAME - see below. Odd to see mention of PLFRAME but not FECFRAME, which is a more direct translation of the packet data.
I have corrected the accronyms in PR We do not mention FECFRAME because it is an internal format and we focus on what is exchanged between access and physical gateways.
Change:
Supported Version. Version Negotiation packets do not use integrity or confidentiality <del> protection.  Specific QUIC versions define mechanisms to authenticate the packet as part of the connection establishment process. </del> <ins> protection.  Specific QUIC versions might include protocol elements that allow endpoints to detect modification or corruption in the set of supported versions. </ins> An endpoint MUST include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID

Discussion:
This clarifies that it is a mechanism in the target QUIC version that authenticates the information. This also lifts the strong requirement on authenticating the contents of Version Negotiation. QUIC version 1 does not do this and so does not comply with this requirement. The intent was always that only information that is used needs to be authenticated in this way. (This is a tiny bit of evasion as Version Negotiation is used in QUIC version 1 as a signal that a version is not supported, which results in clients abandoning connections.)
This is for -invariants-09: Section 6 says: Version Negotiation packets do not use integrity or confidentiality protection. A specific QUIC version might authenticate the packet as part of its connection establishment process. Is the second not contradicting what is said in previous paragraph: A Version Negotiation packet contains no other fields. So to my understanding the authentication that the paragraph above talks about needs to be done in another QUIC packet, it can't be done in a QUIC packet that is Version Negotiation. Can this be made more explicit or do I misunderstand and can you then clarify why this is not a contradiction?
I don't see this as contradictory. The sentence here: Implies that the version fields might be authenticated. Indeed, the document says that they MUST be authenticated (somehow). It doesn't say how. However, this ... means that it can't use any fields that are included in a Version Negotiation packet to do that. If you look at the current proposal for , that uses transport parameters.
Ok, then I would request a very minor tweak in this sentence: A specific QUIC version might authenticate the packet as part of its connection establishment process. So that it is explicit that is in another packet(s) than the Version negotiation packet. For example: A specific QUIC version might authenticate the version negotiation packet as part of its connection establishment process outside of this packet.
I have made a slightly larger tweak.
Change:
4.3. <del> Note that backward compatibility does not present a significant issue for the mDNS technique.  When an endpoint that supports mDNS communicates with an endpoint that does not, the legacy endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint.  In the event the legacy endpoint attempts to resolve mDNS names using </del> <ins> For the most part, backward compatibility does not present a significant issue for the mDNS technique.  When an endpoint that supports mDNS communicates with an endpoint that does not, the legacy endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint. In the event the legacy endpoint attempts to resolve mDNS names using </ins> Unicast DNS, this may cause ICE to take somewhat longer to fully complete, but should not have any effect on connectivity or connection setup time. <ins> However, some legacy endpoints are not fully spec-compliant and can behave unpredictably in the presence of ICE candidates that contain a hostname, potentially leading to ICE failure.  Such endpoints have been identified during testing of this technique, but appear to be rare. </ins> 5. The examples below show how the mDNS technique is used during ICE

Discussion:
LGTM
In the draft, we currently have no clear definition on this aspect. One thought we have is to couple the IP revealing permission with the getUserMedia permission. This is in alignment with the existing practice of the network enumeration permission in browsers. A separate permission from the user for the IP revealing is the alternative that reduces the implications from a single permission.
I think this is outside the scope of this work - it's already addressed in rtcweb-ip-handling.
My concern is the current draft does not provide a precise mapping to modes in rtcweb-ip-handling and the privacy guideline, namely Section 5. We may need the reference to mode 2.1 in ip-handling-ex-mdns, which however delegates the privacy guideline to ip-handling, and meanwhile ip-handling currently has only a brief recommendation after mode 4. A link feels missing in deriving (transitively) the exact condition in the text. This issue will probably be gone after consolidating the two ip-handling drafts and editing Section 5. Let me know what you think.
URL tries to spell this out, referring back to mdns-ice-candidates. I don't think mdns-ice-candidates should ref ip-handling-ex-mdns; I would prefer that any mode discussion be confined to that document.
Discussed and plan is to simply add some text that legacy endpoints are more likely to malfunction with mDNS names (in the same section where we talk about performance/cost downsides)
LGTM
Change:
Another consideration related to uniqueness of the User Equipment is that if the attached User Equipment changes, both the API Server and <del> the Enforcement Device must invalidate their state related to the </del> <ins> the Enforcement Device MUST invalidate their state related to the </ins> User Equipment. The Enforcement Device needs to be aware of the physical interface,

Discussion:
Does this also need to update the boilerplate text that defines SHOULD, MUST, etc?
forgot to mention that, but the draft is already updated to use 8174 boilerplate
In the paragraph starting at line 633, we say: In particular, " Consequently, any solution using the IP address should proactively" and "the components of the architecture must remove or update their" I think we should either capitalize these two or rephrase them.
Aside from my one comment, lgtm. I don't think the intention of the issue was to rephrase everything that used lowercase, but to make sure that we capitalized everything we needed to.
changed the 2 to capital case
lgtm, thanks.
A scrub for these to determine which are really requirements is a good idea. Also, update SS1.1 to use RFC 8174 boilerplate.
looks OK to me
Change:
a clear handshake, like TCP, then the obvious choice is to declare that node "connected" when the last packet of the three-way handshake has been received.  If the only protocol being used is an <del> "unconnected" protocol, like UDP, the implementation may consider the node fully "connected" the moment it determines a route is present, before sending any packets on the network, see further unconnected- racing. </del> <ins> connectionless protocol, like UDP, the implementation may consider the node fully "connected" the moment it determines a route is present, before sending any packets on the network, see further connectionless-racing. </ins> For protocol stacks with multiple handshakes, the decision becomes more nuanced.  If the protocol stack involves both TLS and TCP, an

Discussion:
Just check "connected" - in case we mean connection-oriented; and that usage of "connect" is sane, we need care.
UDP is best described as connectionless, not unconnected: it has no notion of a connection, where "unconnected" might imply a particular usage pattern for a protocol that also supports connections.
YES! UDP is "connectionless"; confusing APIs do support a "connected mode". Please remove unconnected.
Change:
In addition to these, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as <del> detailed below. </del> <ins> detailed below.  (Note that this class of attack is not possible if each member uses the SNI extension RFC6066 and terminates the connection on mismatch.  See Selfie for details.) </ins> Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows:

Discussion:
The Selfie paper points out that if each party uses the SNI extension and terminates a connection on mismatch, rerouting attacks like Selfie aren't possible. I added this note to the explanation of such attacks.
Change:
5.1.1. <del> For static SID allocation, the server ID length is limited to 16 octets.  The nonce length MUST be zero. </del> <ins> See cid-format. </ins> 5.1.2. On each incoming packet, the load balancer extracts consecutive octets, beginning with the second octet.  These bytes represent the <del> server ID. </del> <ins> server ID.  It ignores the nonce. </ins> 5.1.3. <del> The server chooses how many octets to reserve for its own use, which MUST be at least one octet. </del> When a server needs a new connection ID, it encodes one of its <del> assigned server IDs in consecutive octets beginning with the second. </del> <ins> assigned server IDs in consecutive octets beginning with the second and chooses a nonce.  This nonce MUST appear to be random (see cid- entropy). </ins> 5.2.

Discussion:
the server no longer has discretion to lengthen the CID. Also, the algorithms are more aligned so there has to be less unique text associated with each algorithm.
In any given deployment, the server use length should be consistent. The load balancer doesn't strictly need to know what it is, but obviously not doing this will lead to observable correlations.
As we've generalized the concept of a nonce, we should abolish the concept of "server use" and make it all a nonce. If the servers need to use the same length to prevent linkability, best to make it part of the configuration.
Change:
decoupling of the ICE and signaling state machines allows it to accommodate either model. <del> Through its abstraction of signaling, the JSEP approach does require the application to be aware of the signaling process.  While the application does not need to understand the contents of session descriptions to set up a call, the application must call the right APIs at the right times, convert the session descriptions and ICE information into the defined messages of its chosen signaling protocol, and perform the reverse conversion on the messages it receives from the other side. </del> <ins> Although it abstracts signaling, the JSEP approach requires that the application be aware of the signaling process.  While the application does not need to understand the contents of session descriptions to set up a call, the application must call the right APIs at the right times, convert the session descriptions and ICE information into the defined messages of its chosen signaling protocol, and perform the reverse conversion on the messages it receives from the other side. </ins> One way to make life easier for the application is to provide a JavaScript library that hides this complexity from the developer;

Discussion:
…or already fixed. NAME Change in normative text (previous ART AD requested it), please review.
LGTM, approved.
eom
LGTMOne minor comment.
Change:
2. The protocol consists of two HTTP-based target resources presented by <del> the receiver: A target resource enabling the publisher to discover what optional capabilities a receiver supports.  Publishers SHOULD query this target when before sending any notifications or if ever an error occurs. A target resource enabling to publish to send one or more notification to a receiver.  This document defines support for sending only one notification per message; a future effort MAY extend the protocol to send multiple notifications per message. </del> <ins> the receiver.  These two resources share a common prefix that the publisher must know.  If the data model in section 6.2 is used, this common prefix is defined by the "path" leaf in the "http-client- parameters" container. "capabilities": A target resource enabling the publisher to discover what optional capabilities a receiver supports. Publishers SHOULD query this target before sending any notifications or if ever an error occurs. "relay-notifications": A target resource enabling the publisher to send one or more notification to a receiver.  This document defines support for sending only one notification per message; a future effort MAY extend the protocol to send multiple notifications per message. </ins> The protocol is illustrated in the diagram below:

Discussion:
Getting the draft ready for publication. Did file a bug with libyang folks and even though it was an operator error on my part, the default in yanglint now is to enable all features when none are mentioned. The examples now validate correctly.
Change:
before the second offer is sent, then media can be transmitted immediately by the callee immediately upon answering the call, minimizing perceived post-dial-delay.  The second offer/answer <del> exchange can also change the preferred codecs or other information. </del> <ins> exchange can also change the preferred codecs or other session parameters. </ins> This example also makes use of the "relay" ICE candidate policy described in sec.ice-candidate-policy to minimize the ICE gathering

Discussion:
a=simulcast, a=rid a=imageattr (maybe) differing codecs/preferences for either side
I started on this; should be straightforward
Change:
If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator request.  If there is no authenticator request, the extensions are <del> chosen from the TLS handshake.  That is, the extensions received in a ClientHello (for servers), ServerHello (for clients in TLS 1.2), or EncryptedExtensions (for clients in TLS 1.3). </del> <ins> chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request.  In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </ins> 4.2.1.

Discussion:
In Section 4, clients are required to have an authenticator request before generating and sending an authenticator. Later, in Section 4.2, the draft states that clients may get authenticator information from a SH or EncryptedExtensions in the event that no authenticator request is present. This seems to contradict the requirement in Section 4.
Change:
Records, to add new Records, and to remove existing Records.  The names, times, and units of the Patch Records are given and matched in same way as for the Fetch Records, except each Patch Record MUST <del> match at most one Target Record.  Patch Packs can also include new values and other SenML fields for the Records.  Application of Patch Packs is idempotent; hence PATCH and iPATCH methods for SenML Packs are equivalent. </del> <ins> match at most one Target Record.  A Patch Record matching more than one Target Record is considered invalid.  Patch Packs can also include new values and other SenML fields for the Records. Application of Patch Packs is idempotent; hence PATCH and iPATCH methods for SenML Packs are equivalent. </ins> When the name in a Patch Record matches with the name in an existing Record, the resolved time values and units (if any) are compared.  If the time values and units either do not exist in both Records or are equal, the Target Record is replaced with the contents of the Patch Record.  All Patch Records MUST contain at least a SenML Value or Sum <del> field.  A Patch Pack with invalid Records MUST be rejected. </del> <ins> field. </ins> If a Patch Record contains a name, or combination of a time value, unit, and a name, that do not exist in any existing Record in the

Discussion:
Patch records must match only one Target record Invalid records result in error No Pack state is changed if any invalid records Also: Noted Fetch response must contain each target only once Updated author info
Change:
The Shared-State Retry Service defined in shared-state-retry describes the format of retry tokens or new tokens protected and encrypted using AES128-GCM.  Each token includes a 96 bit randomly <del> generated unique token number, and an 8 bit identifier of the AES-GCM encryption key.  There are three important security considerations for these tokens: </del> <ins> generated unique token number, and an 8 bit identifier used to get the AES-GCM encryption context.  The AES-GCM encryption context contains a 128 bit key and an AEAD IV.  There are three important security considerations for these tokens: </ins> An attacker that obtains a copy of the encryption key will be able to decrypt and forge tokens.

Discussion:
Made the changes to merge this.
Hi martin: The defination of and brought me a great confusion when I implement the share-state retry service. Though finally I got what the draft want to express, I still suggest we should give more information about them According to section 1.5 of rfc5084: According to section 3.4 of rfc5116 I guess that in current draft is the define in rfc5116, is just a random value(or a incrementing number) to generate . If I were true, please consider my PR for my suggestion.
Additional, it's no need to make the length of (current draft define) variable, just 96 bit is sufficient. Current aes-128-gcm related cipher suites all use this value
We can also add some illustration of , draft use in other place