jiebi/CodeConvo huggingface dataset:
Change:
LGTM but travis does not seem happy, not sure why: git -C /tmp/ghpages5574 push -q URL gh-pages 684make: * [ghpages] Error 128
I think the bot doesn't have push credentials on this repo. I'll look into it.
LGTM. The travis failure may render https://rtcweb-URL unavailable but shouldn't impact other parts. I wonder if the failure is caused by name mismatch somewhere in the config.

Discussion:
Using Multicast DNS to protect privacy when exposing ICE candidates <del> draft-ietf-rtcweb-mdns-ice-candidates-latest </del> <ins> draft-ietf-mmusic-mdns-ice-candidates-latest </ins> Abstract
Change:
Fingerprinting question will be tracked in a new issue.
Merging this one with Jeroen's approval.
LGTM

Discussion:
2.1. For any host candidate gathered by an ICE agent as part of RFC8445 <del> section 5.1.1, obfuscation of the candidate is done as follows: </del> <ins> section 5.1.1, the candidate is processed as follows: </ins> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6. <del> If there is a registered hostname, replace the IP address of the ICE host candidate with the hostname.  Expose the candidate and abort these steps. </del> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local".

agent for future reuse. Replace the IP address of the ICE host candidate with its mDNS <del> hostname.  Expose the candidate. </del> <ins> hostname, and expose the candidate as usual. </ins> An ICE agent can implement this procedure in any way so long as it produces equivalent results to this procedure. An implementation may for instance pre-register mDNS hostnames by executing steps 3 to 5 and prepopulate an ICE agent accordingly.  By <del> doing so, only steps 1 and 2 of the above procedure will be executed at the time of gathering candidates. </del> <ins> doing so, only step 6 of the above procedure will be executed at the time of gathering candidates. </ins> An implementation may also detect that mDNS is not supported by the <del> available network interfaces.  The ICE agent may skip step 3 and 4 </del> <ins> available network interfaces.  The ICE agent may skip steps 2 and 3 </ins> and directly decide to not expose the host candidate. This procedure ensures that a mDNS name is used to replace only one <del> IP address.  Specifically an ICE agent using an interface with both </del> <ins> IP address.  Specifically, an ICE agent using an interface with both </ins> IPv4 and IPv6 addresses MUST expose a different mDNS name for each address.

candidate would provide applications an even more reliable tracking mechanism than the private IP addresses that this specification is designed to hide.  The use of registered mDNS hostnames SHOULD be <del> scoped by origin, and have the lifetime of the page. If the generated mDNS hostname candidate does not follow the pattern described, the exposed candidate might be used for fingerprinting. If there are multiple host candidates with different IP addresses, IPv4 and/or IPv6, each results in a separate mDNS hostname candidate. The number of mDNS hostname candidates can provide a fingerprinting dimension.  If so desired an ICE agent MAY expose additional mDNS hostname candidates that are not registered. </del> <ins> scoped by origin, and SHOULD have the lifetime of the page. </ins> 3.3.
Change:
PR of
Anyone else want to take a look?
(browser) execution context -> browsing context
It was suggested to replace the name by "browsing context " in the PR of the security consideration. Execution or browser execution context is consistently used in the new commits, and I will create a PR for this if we decide to change the name.

Discussion:
2. <del> This section uses the concept of ICE agent as define in RFC8445.  In the remainder of the document, it is assumed that each browser execution context has its own ICE agent. </del> <ins> This section uses the concept of ICE agent as defined in RFC8445.  In the remainder of the document, it is assumed that each browsing context (as defined in Section 7.1 of HTMLSpec) has its own ICE agent. </ins> 2.1.

3.3. As noted in IPHandling, privacy may be breached if a web application <del> running in two browser contexts can determine whether it is running </del> <ins> running in two browsing contexts can determine whether it is running </ins> on the same device.  While the approach in this document prevents the application from directly comparing local private IP addresses, a successful local WebRTC connection can also present a threat to user

are running on the same device. To avoid this issue, browsers SHOULD NOT register mDNS names for <del> WebRTC applications running in a third-party browser execution context (i.e., a context that has a different origin than the top- level execution context), or a private browser execution context. </del> <ins> WebRTC applications running in a third-party browsing context (i.e., a context that has a different origin than the top-level browsing context), or a private browsing context. </ins> 4.

the addition of remote ICE host candidates with mDNS names generates mDNS queries for names of each candidate; <del> the removal of names could happen when the execution context of the ICE agent is destroyed in an implementation, and goodbye responses should be sent to invalidate records generated by the ICE agent in the local network (RFC6762, Section 10.1). </del> <ins> the removal of names could happen when the browsing context of the ICE agent is destroyed in an implementation, and goodbye responses should be sent to invalidate records generated by the ICE agent in the local network (RFC6762, Section 10.1). </ins> A malicious Web application could flood the local network with mDNS messages by: <del> creating execution contexts that create ICE agents and start </del> <ins> creating browsing contexts that create ICE agents and start </ins> gathering of local ICE host candidates; destroying these local candidates soon after the name registration
Change:
LGTM too, will resolve conflicts
If we resolve a name N1 to 1.1.1.1, should we pair it with relay candidates? If we do so, 1.1.1.1 will be sent to the TURN server, which seems like a leak (could be under the control of the web app). Probably need to add a section in the privacy considerations saying any remote mdns candidates MUST NOT be paired with local relay candidates (although the reverse should be OK).
I am thinking about the impact on the connectivity, and if we can ever resolve the remote mdns candidate, the chance of selecting relaymdns even if this is allowed could probably be low if the local side also gathers a host candidate. The MUST level lgtm.
yeah, and keep in mind that usually these host IPs will be things like 192.168.1.3 that are not even reachable by the outside world.
Well thought! Agreed, I always thought TURN and STUN were intertwined (TURN server is probably also a STUN server or at least hosted in the same network) so that we can use server reflexive candidates for TURN without losing much.
yeah - we already throw away private IPs for TURN to avoid creating connections that won't work, so the actual impact here is negligible.
LGTM

Discussion:
4.2. <ins> When sending data to a TURN RFC5766 server, the sending client tells the server the destination IP and port for the data.  This means that if the client uses TURN to send to an IP that was obtained by mDNS resolution, the TURN server will learn the underlying host IP and port, and this information can then be relayed to the web application, defeating the value of the mDNS wrapping. To prevent disclosure of the host IP address to a TURN server, the ICE agent MUST NOT form candidate pairs between its own relay 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. This restriction has no effect on connectivity; in the cases where host IP addresses are private and need to be wrapped with mDNS names, they will be unreachable from the TURN server, and as noted above, the reverse path will continue to work normally. 4.3. </ins> It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname candidate would provide applications an even more reliable tracking

designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page. <del> 4.3. </del> <ins> 4.4. </ins> As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running
Change:
PR of
I will upload a PR for this.
OK, bad merge, thanks for catching
Fixed by
E.g. "Step 5 in Section {{gathering}}" in .md becomes "Step 5 in Section Section 2.1" in .html or "Step 5 in Section Section 2.1" in the raw html source.
Was this fixed?
No, it looks to me an issue with the generator code. Or, can I fix it inline? I was assuming the html would be auto-generated, but if it is supposed to just upload a copy, I will fix it inline asap.
I was wrong. This issue is gone in the newly generated HTML (from the "here" link), but we probably need to regenerate it after merging PR
OK, will do as part of the upload
Resolved in latest HTML.

Discussion:
4.3. <del> When sending data to a TURN RFC5766 server, the sending client tells the server the destination IP and port for the data.  This means that if the client uses TURN to send to an IP that was obtained by mDNS resolution, the TURN server will learn the underlying host IP and port, and this information can then be relayed to the web application, defeating the value of the mDNS wrapping. To prevent disclosure of the host IP address to a TURN server, the ICE agent MUST NOT form candidate pairs between its own relay 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. This restriction has no effect on connectivity; in the cases where host IP addresses are private and need to be wrapped with mDNS names, they will be unreachable from the TURN server, and as noted above, the reverse path will continue to work normally. 4.4. </del> It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname candidate would provide applications an even more reliable tracking

designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page. <del> 4.5. </del> <ins> 4.4. </ins> As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running
Change:
PR for
IANA Considerations A. Must specify if IANA has to create a new registry or modify rules for an existing registry. B. Must specify if the document requires IANA to assign or update values in an IANA registry before RFC publication. C. See "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) and in some cases also "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers" [RFC2780] (Bradner, S. and V. Paxson, “IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers,” March 2000.) [RFC5237] (Arkko, J. and S. Bradner, “IANA Allocation Guidelines for the Protocol Field,” February 2008.). In some case "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] (Narten, T., “Assigning Experimental and Testing Numbers Considered Useful,” January 2004.) may help as well. D. If there is no action for IANA, the section should say that, e.g., including something like "This document has no actions for IANA."
Good catch. Do you want to take a shot at this? JSEP says
Not blocking for today's doc, to be clear.
Fixed by

Discussion:
7. <ins> This document requires no actions from IANA. 8. </ins> The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP section 4.1 could be updated to explicitly allow mDNS names in the
Change:
Original text: I'm not sure this provides an actual new fingerprinting surface - assuming the interface is in fact exposed to the outside world, a srflx candidate will also be generated for each mDNS candidate - and in the mode we are most concerned about, Mode 2, there will either be 1 or 2 mDNS candidates.
If we decide that this draft only applies to mode 2 or default routes, I agree that there is no fingerprinting surface. However, that assumption hasn't been called out anywhere in this doc AFAIK.
We still get a srflx and TURN candidate for each interface though.
Ok, good point. I agree, we should remove that paragraph. I'll create a PR
If an interface cannot connect to a STUN server, there will be no srflx candidate. I don’t think we can assume that such interface will also not support multicast.
Right, as noted in the OP, but this seems like an edge case.
I think it is better to mention an issue even though this is an edge case. Something like: If there are multiple host candidates with different IP addresses, IPv4 and/or IPv6, each results in a separate mDNS hostname candidate. The number of mDNS hostname candidates might provide a fingerprinting dimension. This is in particular the case for network interfaces whose existence are not exposed through other means like provided STUN servers. No new information is provided when exposing default route candidates.
Filed URL to follow up on that.
Approved with minor suggestions

Discussion:
a context that has a different origin than the top-level browsing context), or a private browsing context. <ins> 6.5. Even when local IP addresses are not exposed, the number of mDNS hostname candidates can still provide a fingerprinting dimension. This is in particular the case for network interfaces with limited connectivity that will not generate server-reflexive or relay candidates. The more mDNS names an endpoint exposes through mDNS hostname candidates, the higher the fingerprinting risk.  One countermeasure is to limit this number to a small value. Note that no additional fingerprinting risk is introduced when restricting mDNS hostname candidates to default route only. </ins> 7. 7.1.
Change:
From the 'nits' link on top of the IETF submitted version. ** The abstract seems to contain references ([RFC6762]), which it shouldn't. Please replace those with straight textual mentions of the documents in question.
Probably can just move the ref to the intro section.
URL
LGTM

Discussion:
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 (mDNS) RFC6762 names. </del> <ins> dynamically generated Multicast DNS (mDNS) names. </ins> 1.

not be supported. This document proposes an overall solution to this problem by <del> registering ephemeral mDNS names for each local private IP address, and then providing those names, rather than the IP addresses, to the web application when it gathers ICE candidates.  WebRTC implementations resolve these names to IP addresses and perform ICE processing as usual, but the actual IP addresses are not exposed to the web application. </del> <ins> registering ephemeral mDNS RFC6762 names for each local private IP address, and then providing those names, rather than the IP addresses, to the web application when it gathers ICE candidates. WebRTC implementations resolve these names to IP addresses and perform ICE processing as usual, but the actual IP addresses are not exposed to the web application. </ins> 2.
Change:
As pointed by NAME one can stuff ICE candidates with mDNS names that are not UUID. This may ease exposing some devices (URL) to some unsolicited mDNS/STUN traffic.
To be noted that a web application can currently synthesize candidates with well-known IP addresses/address ranges. Allowing non UUID mDNS resolution might ease such attacks. We should evaluate whether this is fine as is or not. One possibility would be to mandate mDNS resolution for UUID-based names only.
I am inclining towards mandating mDNS resolution for UUID-base names only. My rationale is the technique proposed is essentially intended to expose no handle to applications to tweak. A general name + .local could fall back to the path of FQDN ICE supported by unicast DNS currently, with better security scrutiny.
Implementations might use the same code path for mDNS and unicast DNS, so I am not sure this will be easy to do this distinction in practice. I would do the distinction between applications that trust the source of ICE candidates (in which case any mDNS is fine) from cases where there is no trust (web browsers typically). In the latter case, I would go with a SHOULD statement.
Started PR URL
Fixed via
Approved with a few editorial comments

Discussion:
IPv6 address resolved, if one exists, or the first IPv4 address, if not. <ins> An ICE agent MAY add additional restrictions regarding the ICE candidates it will resolve using mDNS, as this mechanism allows attackers to send ICE traffic to devices with well-known mDNS names. </ins> 4. 4.1.

As above, mitigation of this threat is beyond the scope of this proposal. <ins> 7.4. As noted in Section 4.2 of RTCWebSecurity, an attacker may use ICE as a way to send unsolicited network traffic to specific endpoints. While this is not specific to mDNS hostname candidates, this technique makes it easier to target devices with well-known mDNS names. As noted in processing, ICE agents may decide to not resolve mDNS names, for example, if these names are not in the format defined by gathering. </ins> 8. This document requires no actions from IANA.
Change:
This work is already in motion in the desired documents.
LGTM
IOW, should this document define the new modes, or just how mDNS should be used to hide local IP addresses? If the latter, we would then also need to write a ip-handling v2 that defined the new modes, and pointed at this doc for details on how the technique should work.
From last meeting discussions, the plan was to define the new modes in this document and add a note in the ip-handling document that new modes might be defined with an informative reference to this document. I think defining the new modes in this document will also ease the authoring work and the review from the RTCWeb WG. In the long run, I think an ip-handling v2 might be a better place for the definition of the modes. For instance the guidelines around a default mode does belong in the ip-handling document, not the mdns-ice-candidate document.
OK. This particular document may be in the wrong WG then, but we can leave those details for later.
Leaving this open to cull the Specification Requirements section once it has been fully incorporated into ip-mdns-ext.

Discussion:
8. This document requires no actions from IANA. <del> 9. The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP section 4.1 could be updated to explicitly allow mDNS names in the connection-address field. The proposal relies on adding the ability to register mDNS names at ICE gathering time.  This could be described in ICESDP and/or WebRTCSpec. The proposal allows updating IPHandling so that mode 2 is not the mode used by default when user consent is not required.  Instead, the default mode could be defined as mode 3 with mDNS-based ICE candidates. </del>
Change:
This might be a bit nitpicky, but I think the draft should explicitly say that contains YAML.
If you are ok with the integration, feel free to squash and merge NAME

Discussion:
2.1. <del> The following information serves as the registration form for the "application/yaml" media type. </del> <ins> The media type for YAML text is "application/yaml"; the following information serves as the registration form for this media type. </ins> application
Change:
no default frag-id for +yaml media types have to explicitly declare syntax and semantics
Compile fragment identifier section [ ] for [x] for ? Can we pospone this?
It seems strange to me that a media type would define a new "language" intrinsic.
I believe the registration should include the fragment identifier. +json does not identify one, which creates problems. It probably should have a registration update to address it. Not registering fragment handling means that a reference to a YAML-borne schema cannot be referenced. The part beyond the # would be formally nonsensical (as it is today). We can take some inspiration from the work on the same issue for JSON Schema. JSON Pointer tells us how to craft fragments. The same format applies to the semantic equivalent in YAML documents. I'll put in a pull request.
NAME we have splitted the two documents. I think that yaml fragment identifiers should probably be delegated to "structured" media types since there are multiple possibilities (eg. json-path, json pointers, ...) WRT openapi+yaml for example, we can state that the fragment uses json pointers.
NAME Can you confirm that the YAML community agrees with the current statement wrt fragment identifiers?
I'm pretty sure that fragment identifiers should not be defined for at least for now. As demonstrated e.g. by the work going on even in this repo, YAML is used to represent multiple different forms of structured data, some of which may at times be represented by other formats, such as JSON. So while YAML 1.1 and 1.2 do explicitly support on nodes that would rather naturally work as fragment identifiers, there's somewhat significant risk that this would complicate usage with sub-formats that natively use different methods, such as JSON Pointers. On the other hand, defining fragment identifiers for to follow the YAML spec for referring to anchors would make sense.
FWIW, I completely agree.
The choice to leave the fragment identifier of the structured syntax suffix to the media type is sensible: I will PR that.

Discussion:
see <del> The syntax and semantics of fragment identifiers specified for +yaml SHOULD be as specified for application-yaml The syntax and semantics for fragment identifiers for a specific "xxx/yyy+yaml" SHOULD be processed as follows: For cases defined in +yaml, where the fragment identifier resolves per the +yaml rules, then process as specified in +yaml. For cases defined in +yaml, where the fragment identifier does not resolve per the +yaml rules, then process as specified in "xxx/yyy+yaml". For cases not defined in +yaml, then process as specified in "xxx/yyy+yaml". </del> <ins> Differently from "application/yaml", there is no fragment identification syntax defined for +yaml.  A specific "xxx/ yyy+yaml" media type needs to define the syntax and semantics for fragment identifiers because the ones in application-yaml do not apply unless explicitly expressed. </ins> See