I am the assigned int-dir reviewer for this draft. For background on int-dir, please see the [FAQ](https://wiki.ietf.org/en/group/intdir). Please resolve these comments along with any other comments you may receive. Comments regarding INT area hot topics (https://wiki.ietf.org/group/iesg/int) -------------------------------------- Section 2 says "For example, given a source address of fe80::a12:34ff:fe56:7890, the IPv6 multicast address may be ff32:00ff:a12:34ff:fe56:7890:9abc:def0". The hot topics asks that example addresses should be from a RFC6890 reserved range. However 2001:db8:: isn't appropriate, as it's unicast. I have little experience with multicast but as far as I can tell the IETF hasn't defined a documentation prefix for multicast. It's clear that the address should start with ffxx. The choice of ff32 implies Source-Specific Multicast and link-local scope. SSM isn't referenced in this document. Should it be? The requirements document only mentions it to say "Cost-effective switches often do not support source-specific multicast (SSM)". If SSM is intended, I suggest describing the connection. If it's not, let's find an example that doesn't refer to it. Also, whichever addresses are used should follow RFC5952 formatting, which implies suppressing leading zeros. Other comments from reading the draft ------------------------------------- Section 2 says "The application … uses that to construct a string like a reverse-mapping domain, using a new "eth-addr.arpa" special-use domain." This standards-track document needs to clearly specify how that eth-addr.arpa name is constructed, e.g. by reference to a section of an existing RFC. Section 2 says "records MUST be published using the IPv6 multicast address for mDNS, but MAY also be published using the IPv4 multicast address for mDNS." Does the working group want to include a recommendation regarding this choice? Section 2 "The application shall retain the group ID value and use it the next time". Should this refer to persistent storage? I'm guessing that retention only in RAM isn't your intention. Section 2 "The host network stack may optionally monitor the network". Is this recommended? Section 2 "While intended primarily for allocating IPv6 multicast addresses on the same subnet (link-local scope), the same technique could also apply to a larger network as long as mDNS traffic is routed between subnets". Blindly forwarding mDNS between subnets is problematic for a number of reasons, which is why DNSSD is defining how mDNS and unicast DNS can work together across multiple links. I suggest reframing the document to explicitly only define link-local behaviour, and leave the question of how to handle multiple links to a future document. Section 2.1 "When an infrastructure component detects a collision it cannot resolve, it triggers a conflict with the application by publishing a veto record." What is this infrastructure component? It hasn't been defined. The requirements draft discusses "infrastructure-free" environments. Section 3 "Deployments on these networks may consider engaging a detection mechanism and prompting hosts to send unsolicited mDNS response messages when the partition is repaired." This informational paragraph feels out of place in a standards track document, because it's not specifying the mechanism. This could be resolved by deleting it, or by fully describing how to do this. Section 3 "The protocol described in this document also satisfies the recommended criteria, to the extent that a deployment supports publishing mDNS-based DNS-SD records across multiple subnets (see [RFC8766])" I'm confused by this. Do you mean to say that deployments needing multiple subnet discoverability should send unicast queries to a Discovery Proxy so that remote eth-addr.arpa names can be found? Section 5 The security considerations section doesn't meet the requirements of https://authors.ietf.org/required-content which says "The text of this section must have a meaningful exploration of security issues raised by the proposal, which should include both risks and a description of solutions or workarounds." You could certainly flesh out the DoS risk. If a malicious device tries to deny service by immediately vetoing every group ID that appears, will it cause all the legitimate applications to remain in a probing state and be unable to offer their services? If yes, is the working group happy that this risk is accepted? Alternatively, should we have defined behaviour about how to detect and ignore malicious vetos? Editorial --------- The first line of the abstract should be made into a complete sentence. The phrase "mDNS is used in favor of a new protocol" perhaps ought to be something like "mDNS is used rather than a new protocol".