jiebi/CodeConvo huggingface dataset:
Change:
addresses has privacy implications.  This document describes a way to share local IP addresses with other clients while preserving client privacy.  This is achieved by obfuscating IP addresses with <del> dynamically generated Multicast DNS RFC6763 names. </del> <ins> dynamically generated Multicast DNS RFC6762 names. </ins> 1.

Discussion:
Some additional comments may be needed in the prflx section?
NAME I went ahead and added a commit for my proposed changes. Let me know if the proposed changes are fine with you.
NAME Did you only commit the html changes? Can you include the markdown?
Oh, I probably messed up with the commit. I was expecting to commit only the markdown. I'll fix it.
It is conceivable that a server would implement ICE with mDNS candidates. There should be nothing in the ICE candidate processing that prevents this from working. Therefore we should call out what should happen when an mDNS query returns multiple IP addresses. E.g. use the 'best' on (where IPv6 is better than IPv4)?
This is a complex area. A simpler option could be that we mandate 1:1 for mDNS, and/or pick the first address of the expected type.
Mandating 1:1 for mDNS in the context of WebRTC is probably the straightforward approach. We should probably also define the behavior in the case of multiple responses, picking the first record makes sense to me. This requirement causes a potential issue when using MDNS for non default route though: it creates a fingerprinting vector by counting the number of different MDNS names for a given peer connection. I am not sure what reliable means we have to know the expected type of the address and whether this is a requirement at all. The easy solution would be to include this information in the MDNS name.
Good point about type not being known a priori, and we could put a hint in the name. Another option could be to resolve the name before forming pairs, take the first record found, and then only pair the resolved address with local candidates of the appropriate family.
Fixed by
LGTM with one comment
Change:
the application deploys its relay servers, this could obfuscate location to a metro or possibly even global level. <del> Although it can be overridden by local policy, the default ICE candidate policy MUST be set to allow all candidates, as this minimizes use of application STUN/TURN server resources. </del> <ins> The default ICE candidate policy MUST be set to allow all candidates, as this is generally the desired policy, and also typically reduces use of application TURN server resources significantly. </ins> If a size is specified for the ICE candidate pool, this indicates the number of ICE components to pre-gather candidates for.  Because pre-

Discussion:
Not sure if this is done but what is there LGTM
Yes, I think this is complete.
LGTM
URL talks about browser local policy. It should make this more concrete by referring to URL as the source of this policy.
Do you see it as normatively depending on that or more just "useful implementor advice can be found in ..."
I guess it depends on what we think the purpose of the ip-handling draft is. If we think all browsers should implement this, then it should be a normative dependency. I'll make a PR as such and we can debate the details there.
I think if it is something all browser need to implement, then we probably just want to move the normative text into this draft.
I think there is enough text that it warrants being in its own document.
Change:
"index" field in "PSKLabel" corresponds to the index of the PSK in the "psk" array, while the "count" field contains the total number of PSKs.  In other words, the PSKs are chained together with KDF.Extract <del> invocations, as follows: </del> <ins> invocations (labelled "Extract" for brevity in the diagram), as follows: </ins> In particular, if there are no PreSharedKey proposals in a given Commit, then the resulting "psk_secret" is "psk_secret_[0]", the all-

Discussion:
Adjust ASCII art to fit within 72 character limit. Did not fix tables or code in appendices.
Change:
the verification have the same security properties as they would have in TLS normally. <ins> In order for certificate compression to function correctly, the underlying compression algorithm MUST be deterministic and it MUST output the same data that was provided as input by the peer. </ins> Since certificate chains are typically presented on a per-server name or per-user basis, the attacker does not have control over any individual fragments in the Certificate message, meaning that they

Discussion:
Thanks for doing this NAME I ended up being tied up in a bunch of other stuff.
See message on mailing list from NAME for more details: URL
Do we actually have consensus for this requiring a mitigation?
I probably worded the title wrong. I created this just to keep track of the issue.
lgtm
Change:
A random 16-octet value to be echoed by the server in the "encrypted_server_name" extension. <del> The true SNI, that is, the ServerNameList that would have been sent in the plaintext "server_name" extension. </del> <ins> The true SNI DNS name, that is, the HostName value that would have been sent in the plaintext "server_name" extension.  (NameType values other than "host_name" are unsupported since SNI extensibility failed SNIExtensibilityFailed). </ins> Zero padding whose length makes the serialized PaddedServerNameList struct have a length equal to

Discussion:
[1] URL
Extensibility failed for SNI, no point in repeating that failure. This is less complex:
Are there other ways we expect servers to select certificates? I can imagine a scenario where clients pin server leaf certificates, and hint servers to the right leaf certificate by sending the leaf SPKI hash in the SNI. Would we want to rule something like that out? The Server Name Indication (SNI) extension in TLS has a provision to provide names other than host names[1]. None have even been defined to my knowledge, but it's there. OpenSSL (and possibly others) have had a long-standing bug[2] (fixed in master) that means that different types of names will cause an error. To be clear: I live in a glass house and am not throwing stones; these things happen. However, it means that a huge fraction of the TLS deployment will not be able to accept a different name type should one ever be defined. (This issue might have been caused by the fact that the original[3] spec didn't define the extension in such a way that unknown name types could be skipped over.) Therefore we (i.e. BoringSSL, and thus Google) are proposing to give up on this and implement our parser such that the SNI extension is only allowed to contain a single host name value. (This is compatible with all known clients.) We're assuming that since this is already the de-facto reality that there will be little objection. I'm sending this mostly to record the fact so that, if someone tries to define a new name type in the future, they won't waste their time. If the community wishes to indicate a different type of name in the future, a new extension can be defined. This is already effectively the case because we wouldn't fight this level of incompatibility when there's any other option. (I think the lesson here is that protocols should have a single joint, and that it should be kept well oiled. For TLS, that means that extensions should have minimal extensionality in themselves and that we should generally rely on the main extensions mechanism for these sorts of things.) [1] URL [2] URL – note that the data pointer is not updated. [3] URL Cheers AGL Adam Langley EMAIL URL
Change:
attacker is able to successfully forge a packet; see AEBounds and ROBUST. <ins> Due to the way that header protection protects the Key Phase, packets that are discarded are likely to have an even distribution of both Key Phase values.  This means that packets that fail authentication will often use the packet protection keys from the next key phase.  It is therefore necessary to also track the number of packets that fail authentication with the next set of packet protection keys.  To avoid exhaustion of both sets of keys, it might be necessary to initiate two key updates in succession. </ins> For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, the limit on the number of packets that fail authentication is 2^36. Note that the analysis in AEBounds supports a higher limit for the

Discussion:
This is an update to , so check where it is being merged to carefully.
I'm going to merge this into the other PR.
NAME pointed out to me that when you receive junk (i.e., unauthenticated) packets, the odds are that these will be distributed evenly between the "current" packet protection keys and the "next" packet protection keys, as the key phase bit will be nearly random if they are true forgeries. The result is that an endpoint that approaches the integrity limit on key usage will update to the next packet protection keys and find that those keys will have similar amounts of authentication failures. That might lead to needing two updates in quick succession. That isn't fatal, but if the timing is tight, then more time might be needed for an update. We might say that endpoints shouldn't be calculating the forgery rate and trying to delay updates as late as possible, nor should they be allowing that many forgeries without doing anything but react with key updates. However, as a matter of good hygiene, it's worth saying something about this. Taking this as an editorial follow-on to .
Integrated into .
Change:
[Editor's note: this section is still work in progress] <ins> 2.10. The YANG model defined in this document supports the following protection architectures: Individual OTSi protection OMS MCG protection = TE-link protection between adjacent WDM-TE- nodes [Editor's note: this section is still work in progress] 2.10.1. Individual OTSi protection is a protection architecture where an individual OTSi signal is protected as defined in Appendix III of ITU-T Recommendation G.873.1 G.873.1.  This protection architecture requires dedicated photonic protection functions that are typically provided by dedicated protection hardware.  These photonic protection functions are a photonic splitter function splitting the OTSi signal in transmit direction and a photonic selector function selecting the OTSi signal in receive direction from one of the two protection legs between the protection functions terminating the individual OTSi protection.  This individual OTSi protection scheme can be considered as a photonic 1+1 protection scheme (1+1 sub-network connection protection (SNCP) in ITU-T terminology). In case of individual OTSi protection, there are two network media channel paths associated with the OTSi signal.  In the YANG model, this is modeled as a leaf list of the otsi providing the nmc-path-id for the two network media channel paths associated with the individually protected otsi. [Editor's note: this section is still work in progress] 2.10.2. OMS MCG protection is a protection architecture where a TE-link between two adjacent WDM-TE-nodes is protected.  This is a local protection scheme, which can be modeled as a TE-link property. [Editor's note: this section is still work in progress] </ins> 3. [Editor's note: tree view below always has to be updated before

Discussion:
draft-ietf-ccamp-optical-impairment-topology-URL for IETF 114 submission --> draft-ietf-ccamp-optical-impairment-topology-yang-URL Related to pull request . Addressing and resolving several open issues.
May need to rebase this branch with the master branch to make sure all the validation checks pass
Change:
QUIC is deliberately designed to fail rather than persist when the network cannot support its operation.  For HTTP/3, this extends to recommending a fallback to TCP-based versions of HTTP rather than <del> persisting with a QUIC connection that might be unstable.  And I- D.ietf-quic-applicability recommends TCP fallback for other protocols on the basis that this is preferable to sudden connection errors and time outs.  Furthermore, wide deployment of NATs with this behavior </del> <ins> persisting with a QUIC connection that might be unstable.  And QUIC- APPLICABILITY recommends TCP fallback for other protocols on the basis that this is preferable to sudden connection errors and time outs.  Furthermore, wide deployment of NATs with this behavior </ins> hinders the use of QUIC's migration function, which relies on the ability to change the connection ID any time during the lifetime of a QUIC connection.

Discussion:
I set the ready to merge label but there are merge conflict, so please don't merge before accepting my suggestions...
[Ding2015] and [IPIM] are in the references of the manageability draft, but aren't actually... referenced anywhere. That suggests either some text is missing or these entries are spurious.
Yes this has been already flagged by and is fixed in (which we will all merge on Monday when Brain is back). Thanks anyway!
Unused Reference: 'Ding2015' is defined on line 1272, but no explicit reference was found in the text Unused Reference: 'IPIM' is defined on line 1293, but no explicit reference was found in the text
Duplicate reference: draft-ietf-quic-applicability, mentioned in 'QUIC-APPLICABILITY', was also mentioned in 'I-D.ietf-quic-applicability'.
There are two paragraphs that include 2119-language: RFC 2119 keyword, line 578: '... RECOMMENDED. First, it only provid...' RFC 2119 keyword, line 969: '... NOT RECOMMENDED....' Should these be made lowercase or is a 2119 paragraph needed?
I see what was done. Looks ready to go.
Change:
It may be the case that one or more 307-Redirects have taken the Pledge from the built-in Cloud Registrar to one operated by a VAR. <del> When the Pledge is directed to the Owner's EST Registrar, the Pledge validates the TLS connection with this server using the "pinned- domain-cert" attribute in the voucher.  There is no provisional TLS connection, and therefore there are no risks associated with being behind a captive portal. </del> <ins> When the Pledge is directed to the Owner's EST RFC7030 Registrar, the Pledge validates the TLS connection with this server using the "pinned-domain-cert" attribute in the voucher.  There is no provisional TLS connection, and therefore there are no risks associated with being behind a captive portal. </ins>

Discussion:
[EST] and [RFC7030] are duplicates.
s/are/is/ That sentence is really hard to decode. Please rewrite using more words! Please define VAR. Please define EST. Hard to parse. Maybe you mean "does not discover a local domain registrar or an owner registrar"?
Change:
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.

Discussion:
Ended up rewriting the Retry Requirements for shared-state while adding the bit about port verification. Inspired by the review here: URL
Change:
"and are, or will be, resolvable in the global DNS" or "but only using the presentation format". <del> An ordered list of zero or more octets and which makes up a portion of a domain name.  Using graph theory, a label identifies one node in a portion of the graph of all possible domain names. </del> <ins> An ordered list of zero or more octets that makes up a portion of a domain name.  Using graph theory, a label identifies one node in a portion of the graph of all possible domain names. </ins> Using the short set of facets listed in "Naming system", the global DNS can be defined as follows.  Most of the rules here come

Discussion:
Agree with the first one, although I don't care which way it comes out from the RFC Editor. For the second one, I have changed the wording to 'An authoritative server is named in the NS ("name server") record in a zone.' We don't need to stray into which zone has authoritative data; the double use of "authoritative" will confuse the reader without helping with the terminology.
l 179, s/octets which/octets that. This has been changed to violate the that/which conventions of the RFC Editor. l844 (new) the authoritative name server is named in the parent zone but is not authoritative data there (NS is authoritative in the child). This is discussed elsewhere in the document, and I find this addition confusing. I won't hold up pver either of these. The rest looks ok.
Change:
attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, <del> which is most rigorously achieved with encryption. </del> <ins> which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the Connection ID in the Connection ID itself, instead of remembering it, e.g. by using the first few bits to indicate a certain size of a well-known set of possible sizes with multiple values that indicate the same size but are selected randomly. QUIC_LB further specified possible algorithms to generate Connection IDs at load balancers. </ins> 9.2.

Discussion:
…ancers for further algos
The intention was not to encrypt the length (as you say that would not be helpful) but you should probably "grease" the length such that those bit can not be used to identify a certain system. That was the intention here. However, maybe this is too much detail and we should remove that sentence and only refer to the load-balancer draft instead...?
Note in section about CID that as the server chooses the CIDs, it could use some own scheme to embed the length of the CID in the CID itself, instead remembering it, e.g. use the first few bits to indicate which of the sizes that are support was chosen.
can be done together with , referencing the LB draft
PR to address this and reference to load balancer draft
Reading this again, I'm not sure how I would improve the phrasing. Perhaps "embed the length of the connection ID in plaintext ...".
Change:
connection by different web origins (RFC6454) are made by mutually distrustful entities. <del> 7.3. </del> <ins> 7.1.2. </ins> Users of HTTP that require confidentiality for header or trailer fields can use values with entropy sufficient to make guessing

Discussion:
Magnus Nystrom : not be able (based on no current known attack against static Huffman encodings) to mount the previously described "probing" attack? If so, adding a sentence at the end of the section along the lines of "Thus, the previously mentioned probing attack is not known to be applicable for any fields where static Huffman encoding is used."
This section is not related to the probing attack. I think some of the confusion here is lost formatting when importing from RFC 7541. The TOC should be:
Change:
8. <del> QUIC version 1 features retry packets, which the server can send to </del> <ins> QUIC version 1 features Retry packets, which the server can send to </ins> validate the client's IP address before parsing the client's first <del> flight.  This impacts compatible version negotiation because a server who wishes to send a retry packet before parsing the client's first flight won't have parsed the client's Version Information yet.  If a future document wishes to define compatibility between two versions that support retry, that document MUST specify how version </del> <ins> flight.  A server that sends a Retry packet can do so before parsing the client's first flight.  A server that sends a Retry packet therefore might not have processed the client's Version Information before doing so. If a future document wishes to define compatibility between two versions that support retry, that document MUST specify how version </ins> negotiation (both compatible and incompatible) interacts with retry during a handshake that requires both.  For example, that could be <del> accomplished by having the server send a retry packet first and validating the client's IP address before starting version negotiation and deciding whether to use compatible version negotiation on that connection (in that scenario the retry packet would be sent using the original version). </del> <ins> accomplished by having the server send a Retry packet first and validating the client's IP address before attempting compatible version negotiation.  In that scenario the Retry packet would be sent using the original version. </ins> 9.

Discussion:
Retry packets have a capital R protocols aren't "who" paragraphs are good minor edits for brevity