jiebi/CodeConvo huggingface dataset:
Change:
Less emphasis on load balancers, more on the other stuff. More text on the use cases and less on "how".

Discussion:
Abstract <del> QUIC connection IDs allow continuation of connections across address/ port 4-tuple changes, and can store routing information for stateless or low-state load balancers.  They also can prevent linkability of connections across deliberate address migration through the use of protected communications between client and server.  This creates issues for load-balancing intermediaries.  This specification standardizes methods for encoding routing information given a small set of configuration parameters.  This framework also enables offload of other QUIC functions to trusted intermediaries, given the explicit cooperation of the QUIC server. </del> <ins> The QUIC protocol design is resistant to transparent packet inspection, injection, and modification by intermediaries.  However, the server can explicitly cooperate with network services by agreeing to certain conventions and/or sharing state with those services. This specification provides a standardized means of solving three problems: (1) maintaining routability to servers via a low-state load balancer even when the connection IDs in use change; (2) explicit encoding of the connection ID length in all packets to assist hardware accelerators; and (3) injection of QUIC Retry packets by an anti-Denial-of-Service agent on behalf of the server. </ins> 1.
Change:
Addresses
The stream and block cipher configuration are locked to AES-ECB. AES-128-ECB too (this needs to be clear). This is a fine design. If a better design is required, that can be achieved by adding a new arm to . It might pay to say that and cite URL at the same time.
LGTM. A suggestion, but I'm OK either way.

Discussion:
balancer uses the first two bits of the connection ID to multiplex incoming DCIDs over these schemes. <ins> Encryption in the algorithms below uses the AES-128-ECB cipher. Future standards could add new algorithms that use other ciphers to provide cryptographic agility in accordance with RFC7696.  QUIC-LB implementations SHOULD be extensible to support new algorithms. </ins> This section describes three participants: the configuration agent, the load balancer, and the server.
Change:
There are so many variable length fields that the ASCII art doesn't serve much of a purpose. Just switch to the notation used in quic-transport for the various CID and token formats.

Discussion:
For brevity, "Connection ID" will often be abbreviated as "CID". <ins> 1.2. All wire formats will be depicted using the notation defined in Section 1.3 of QUIC-TRANSPORT.  There is one addition: the function len() refers to the length of a field which can serve as a limit on a different field, so that the lengths of two fields can be concisely defined as limited to a sum, for example: x(A..B) y(C..B-len(x)) indicates that x can be of any length between A and B, and y can be of any length between C and B provided that (len(x) + len(y)) does not exceed B. The example below illustrates the basic framework: </ins> 2. 2.1.

The first octet has the following fields: <del> CR: Config Rotation bits. </del> <ins> Config Rotation: Indicates the configuration used to interpret the CID. </ins> <del> CID Len: Length Self-Description (if applicable).  Encodes the length of the Connection ID following the First Octet. </del> <ins> CID Len or Random Bits: Length Self-Description (if applicable), or random bits otherwise.  Encodes the length of the Connection ID following the First Octet. </ins> 4.
Change:
Ended up rewriting the Retry Requirements for shared-state while adding the bit about port verification. Inspired by the review here: URL

Discussion:
6.3.3. <ins> In inactive mode, the Retry service forwards all packets without further inspection or processing. Retry services MUST NOT issue Retry packets except where explicitly allowed below, to avoid sending a Retry packet in response to a Retry token. </ins> When in active mode, the service MUST generate Retry tokens with the format described above when it receives a client Initial packet with no token. <del> In active mode, the service SHOULD decrypt the incoming tokens.  The service SHOULD drop packets with unknown key sequence, or an AEAD checksum that does not match the expected value.  (By construction, the AEAD checksum will only match if the client IP Address also matches.) </del> <ins> The service SHOULD decrypt incoming tokens.  The service SHOULD drop packets with unknown key sequence, or an AEAD checksum that does not match the expected value.  (By construction, the AEAD checksum will only match if the client IP Address also matches.) </ins> If the token checksum passes, and the ODCIL and RSCIL fields are both <del> zero, then this is an expired NEW_TOKEN token generated by the server.  An active Retry Service MUST drop the packet and issue a Retry packet with the appropriate token. The service SHOULD drop packets if the Timestamp of the retry token points to a past date; however, in order to allow for clock skew, it SHOULD NOT drop packets if the Timestamp merely points to a a few seconds in the past. It SHOULD forward packets if the AEAD checksum and the Timestamp can be verified, regardless of the other fields. However, the service MUST NOT decrypt or validate tokens if there is a NAT between it and the servers. In inactive mode, the service SHOULD forward all packets to the server so that the server can issue an up-to-date token to the client. </del> <ins> zero, then this is a NEW_TOKEN token generated by the server. Processing of NEW_TOKEN tokens is subtly different from Retry tokens, as described below. The service SHOULD drop a packet containing a token where the ODCIL is greater than zero and less than the minimum number of octets for a client-generated CID (8 in QUIC version 1).  The service also SHOULD drop a packet containing a token where the ODCIL is zero and RSCIL is nonzero. If the Timestamp of a token points to time in the past, the token has expired; however, in order to allow for clock skew, it SHOULD NOT consider tokens to be expired if the Timestamp encodes a few seconds in the past.  An active Retry service SHOULD drop packets with expired tokens.  If a NEW_TOKEN token, the service MUST generate a Retry packet in response.  It MUST NOT generate a Retry packet in response to an expired Retry token. If a Retry token, the service SHOULD drop packets where the port number encoded in the token does not match the source port in the encapsulating UDP header. All other packets SHOULD be forwarded to the server. </ins> 6.3.4.
Change:
PIM ([I-D.liu-pim-yang]) is outadated
see
URL
Closed with commit

Discussion:
BGP (I-D.ietf-idr-bgp-model) <del> PIM (I-D.liu-pim-yang) </del> <ins> PIM (I-D.ietf-pim-yang) </ins> NAT management (RFC8512)
Change:
Error: Unable to parse the XML document: draft-ietf-opsawg-l3sm-l3nm-URL : Line 4822: Entity 'RFC6991' not defined : Line 4823: Entity 'RFC8294' not defined : Line 4867: Entity 'RFC8277' not defined The command "xml2rfc draft-ietf-opsawg-l3sm-l3nm-URL" exited with 1. can you update?

Discussion:
reused by other VPN-related YANG modules (e.g., L3NM, L3SM, Layer 2 Network Model): "ietf-vpn-common". <del> The YANG data models defined in this document conform to the Network Management Datastore Architecture (NMDA) RFC8342. </del> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Change:
The term was used with signalling and signaling. I modified it to signaling, so it is aligned with L2NM as well

Discussion:
Relies upon application-specific classification. Groups a set of parameters that are used when CsC is enabled such <del> the use of BGP for signalling purposes RFC8277. </del> <ins> the use of BGP for signaling purposes RFC8277. </ins> Time synchronization may be needed in some VPNs such as infrastructure and management VPNs.  This container is used to
Change:
Allows a controller to expose the L3SM to which an L3NM is bound
OK! It is optional. Should work typically the other way around, allows the service orchestrator to maintain the match and facilitate reconciliation. NAME Please add some text in the draft to explain the parameter
Please see the change: Will add more text once we will work seriously on the tree structure part.

Discussion:
the L3NM attribute (e.g., actual forwarding policies).  Some of the information captured in L3SM may be maintained locally within the Orchestrator; which is supposed to maintain a "glue" between a <del> Customer view and its network instantiation. </del> <ins> Customer view and its network instantiation.  Likewise, some of the information captured and exposed using L3NM can fed the service layer (e.g., capabilities) to derive L3SM and drive VPN service order handling. </ins> The L3NM module does not attempt to address all deployment cases especially those where the L3VPN connectivity is supported through
Change:
PR of
Currently it contains: c=IN IP4 address/ttl Obviously, putting one of the candidate's IP address there would defeat the purpose of use mDNS. Options: Can this be omitted? Should it have a fake IP address of the right address family? Should it be allowed to have an mDNS name?
Just use the mDNS name.
If we run into issues, we could use 0.0.0.0:9 as we do when there are no candidates, but that starts to get complicated (i.e. may require updates to other specs)
mDNS name with IP4?
good point - shouldn't matter that much, but IP4 seems like the safest choice.
Agreed to use mDNS + IP4. We'll reevaluate if this causes problems.
Fixed by
We have observed an interop issue in the experimental deployment. Endpoints can fail to parse the SDP when the c= line contains a FQDN. This is the current solution.
Well, at least we thought of the solution already :)

Discussion:
IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. <ins> The mDNS name of an mDNS candidate MUST be used in the connection- address field of its candidate attribute.  When an mDNS candidate is the default candidate, its mDNS name MUST be used in the connection- address field of the SDP "c=" line.  Since an mDNS candidate also conceals its address family, the "c=" line SHOULD use "IP4" in the address-type field. </ins> Note that any server-reflexive candidates generated from an mDNS host candidate will have IP addresses as their transport addresses, rather than mDNS hostnames.  Because their transport addresses are different
Change:
PR for
In the section gather candidates, it says: "Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE candidate’s IP address. If one exists, skip ahead to Step 6." We, maybe, should clarify this refers to a registered mDNS hostname as produce by this spec, not another (possibly meaningful) name created in some other context.
Makes sense as an editorial cleanup.
Fixed by

Discussion:
regarding whether an address is safe to expose.  If so, expose the candidate and abort this process. <del> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE candidate's IP address.  If one exists, skip ahead to Step 6. </del> <ins> Check whether the ICE agent has previously generated, registered, and stored an mDNS hostname for this IP address as per Steps 3, 4, and 6.  If it has, skip ahead to Step 7. </ins> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local".
Change:
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

Discussion:
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
Change:
RFC 8445 sayeth in S 5.1.3: We should add a note to make it clear that mDNS candidates have distinct transport addresses from their equivalent IPs, and so a srflx candidate created from a public mDNS candidate MUST NOT be discarded as redundant.

Discussion:
IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. <del> Any server-reflexive candidates generated from an mDNS local candidate MUST have their raddr field set to 0.0.0.0 and their rport field set to 0. </del> <ins> Note that any server-reflexive candidates generated from an mDNS host candidate will have IP addresses as their transport addresses, rather than mDNS hostnames.  Because their transport addresses are different (i.e., not hostnames), they MUST NOT be considered redundant with their host counterparts, per the guidance in RFC8445, Section 5.1.3. To avoid accidental leakage, these candidates MUST have their raddr field set to 0.0.0.0 and their rport field set to 0. </ins> Any candidates exposed to the web application via local descriptions MUST be identical to those provided during candidate gathering (i.e.,
Change:
ping
Will we get sources for these numbers that elaborate distribution and regional differences?
LGTM modulo the thought on mentioning the potential impact of c= line before the update.
No answer to my question?
NAME I struggled to respond to the question since it's so open-ended, and really outside the scope of this PR. Suggest filing an issue and we can discuss more there.

Discussion:
connectivity, reduced throughput and increased latency, as well as increased cost in case of TURN relay. <ins> During experimental testing of the mDNS technique across a set of known mDNS-aware endpoints that had configured a STUN server but not a TURN server, the observed impact to ICE connection rate was 2% (relative) when mDNS was enabled on both sides, compared to when mDNS was only enabled on one side.  In this testing, the percentage of connections that required STUN (i.e., went through a NAT) increased from 94% to 97%, indicating that mDNS succeeded about half the time, and fell back to NAT hairpin for the remainder.  The most likely explanation for the overall connection rate drop is that hairpinning failed in some cases. </ins> One potential mitigation, as discussed in privacy, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits connectivity even in large internal networks or where mDNS is <del> disabled. The exact impact of the mDNS technique is being researched experimentally and will be provided before publication of this document. </del> <ins> disabled.  Future versions of this document will include experimental data regarding this option. </ins> 4.2.

However, some legacy endpoints are not fully spec-compliant and can behave unpredictably in the presence of ICE candidates that contain a <del> hostname, potentially leading to ICE failure.  Such endpoints have been identified during testing of this technique, but appear to be rare. </del> <ins> hostname, potentially leading to ICE failure.  Some endpoints may also fail to handle a connectivity check from an address that they have not received in signaling.  During the aforementioned experimental testing, the connection rate when interacting with endpoints that provided raw IP addresses (and therefore should be unaffected) decreased by 3% (relative), presumably for these reasons. </ins> 5.
Change:
ping
NAME , PTAL
LGTM too
Currently it contains: c=IN IP4 address/ttl Obviously, putting one of the candidate's IP address there would defeat the purpose of use mDNS. Options: Can this be omitted? Should it have a fake IP address of the right address family? Should it be allowed to have an mDNS name?
Just use the mDNS name.
If we run into issues, we could use 0.0.0.0:9 as we do when there are no candidates, but that starts to get complicated (i.e. may require updates to other specs)
mDNS name with IP4?
good point - shouldn't matter that much, but IP4 seems like the safest choice.
Agreed to use mDNS + IP4. We'll reevaluate if this causes problems.
Fixed by
We have observed an interop issue in the experimental deployment. Endpoints can fail to parse the SDP when the c= line contains a FQDN. This is the current solution.
Well, at least we thought of the solution already :)

Discussion:
and therefore distinct from the hostname transport address of the associated mDNS candidate, and as such MUST NOT be considered redundant per the guidance in RFC8445, Section 5.1.3.  To avoid <del> accidental IP address, this server-reflexive candidate MUST have its raddr field set to 0.0.0.0 and its rport field set to 0. </del> <ins> accidental IP address disclosure, this server-reflexive candidate MUST have its raddr field set to "0.0.0.0"/"::" and its rport field set to "9", as discussed in ICESDP, Section 9.1. </ins> Once an address has been identified as public, the ICE agent MAY cache this information and omit mDNS protection for that address in

3.1.2.3. The mDNS name of an mDNS candidate MUST be used in the connection- <del> address field of its candidate attribute.  When an mDNS candidate is the default candidate, its mDNS name MUST be used in the connection- address field of the SDP "c=" line.  Since an mDNS candidate also conceals its address family, the "c=" line SHOULD use "IP4" in the address-type field. </del> <ins> address field of its candidate attribute.  However, when an mDNS candidate would be the default candidate, typically because there are no other candidates, its mDNS name MUST NOT be used in the connection-address field of the SDP "c=" line, as experimental deployment has indicated that many remote endpoints will fail to handle such a SDP.  In this situation, the IP address values "0.0.0.0"/"::" and port value "9" MUST instead be used in the c= and m= lines, similar to how the no-candidates case is handled in ICESDP, Section 4.3.1. </ins> Any candidates exposed to the application via local descriptions MUST be identical to those provided during candidate gathering (i.e., MUST
Change:
Fixes URL
An implementation should probably expose mDNS candidates to a page regardless of successful registration or mDNS support in the network.

Discussion:
as the hostname is expected to be unique, the ICE agent SHOULD skip probing of the hostname. <del> If registering of the mDNS hostname fails, abort these steps.  The candidate is not exposed. </del> Store the mDNS hostname and its related IP address in the ICE agent for future reuse.

ICE agents can implement this procedure in any way as long as it produces equivalent results.  An implementation may for instance pre- <del> register mDNS hostnames by executing steps 3 to 6 and prepopulate an ICE agent accordingly.  By doing so, only step 7 of the above </del> <ins> register mDNS hostnames by executing steps 3 to 5 and prepopulate an ICE agent accordingly.  By doing so, only step 6 of the above </ins> procedure will be executed at the time of gathering candidates. <del> An implementation may also detect that mDNS is not supported by the available network interfaces.  The ICE agent may skip steps 3 and 4 and directly decide to not expose the host candidate. </del> <ins> In order to prevent web applications from using this mechanism to query for mDNS support in the local network, the ICE agent SHOULD still provide mDNS candidates in step 6 even if the local network does not support mDNS or mDNS registration fails in step 4. </ins> This procedure ensures that an mDNS name is used to replace only one IP address.  Specifically, an ICE agent using an interface with both
Change:
Fixes URL
It is required not to pair local relay candidates with remote mDNS candidates to avoid the leak via CreatePermission requests. As Phillip points in this issue (URL), an ICE agent should not rely on the candidate type field in a hostname candidate to reinforce this constraint. The a=candidate line in signaling can be modified to inject an arbitrary type. Suggest that we clarify the remote mDNS candidates include all hostname candidates with the .local pseudo-TLD.
Seems reasonable. The text does not restrict to "typ host", but being extra specific here would still be a good idea. Phillip also points out that we may want to do this for all DNS names, to prevent the browser from becoming a roundabout DNS resolver, but that is probably outside the scope of this document.

Discussion:
To prevent disclosure of the host IP address to a TURN server, the ICE agent MUST NOT form candidate pairs between its own relay <del> candidates and remote mDNS candidates.  Note that the converse is not an issue; the ICE agent MAY form candidate pairs between its own mDNS candidates and remote relay candidates, as in this situation host IPs will not be sent directly to the TURN server. </del> <ins> candidates and remote mDNS candidates.  This restriction must not be limited to remote mDNS candidates of a specific candidate type, typically host, as mDNS candidates are identified from their connection-address fields.  their connection-address field.  Note also that the converse is not an issue; the ICE agent MAY form candidate pairs between its own mDNS candidates and remote relay candidates, as in this situation host IPs will not be sent directly to the TURN server. </ins> This restriction has no effect on connectivity; in the cases where host IP addresses are private and need to be wrapped with mDNS names,