This is a review of a draft that is in its early stages so its unsurprising that a number of items are called out in this review that will likely be refined as the draft progresses. The larger issues as I see them are scope of applicability (local? global? something else?) and explicitly noting the reliance on mDNS to detect conflicts in self-assignment of multicasst addresses.

Issues:

- The document proposes the reservation of the eth-addr.arpa as a special-use domain. RFC6761, section 4 is relevant here.As it stands I do not see these  "MUST" requirements being addressed in the draft, and the cursory  treatment of this requirement in Section 4.1 is inadequate.

- The document proposes the use of mDNS probing algorithm described in [RFC6762], RFC6762 appears to make some assumptions about the use of mDNS in the context of a local scope. particularly in the area of the timers and repeat count specified in the probing procesures. Are the same RFC6762 probe timers when considering a multicast configuration of extended scope? Some text that explains why algorithm would still be effective in a global context might be useful.

- The document notest that records MUST be published using the IPv6 multicast address for mDNS, but MAY also be published using the IPv4 multicast address for mDNS. The use of IPv4 multicast in this context appears to be counter-intuitive in this context. What purpose would publishing this using IPv4 multicast serve?

-  The document notest that "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 (for any scope excluding global scope)." This text appear to assert that this is not applicable for globally scoped  multicast, but is ambivalent about the scenarios that extend beyond a local subnet (a link-layer multicast scope). It seems to me to be an important consideration in terms of applicability and perhaps should be explicitly called out in the introduction and perhaps given its own section ("Scope pf Applicability"?) 

- The document proposes that Veto records are published without probing. What does "publish" entail in mDNS? Does it multicast this record? Or does it just respond to mDNS queries?

- "Applications respond to the conflict the same as to a collision.  The application retains its new group ID, so the same conflict is not repeated in the future."" Previous text says that an application stops transmitting the multicast stream and starts the process over using a different group ID, yet this text says that the applications retains its new Group ID? This does not make sense to me, and I guess more clarifying text would help a reader to understand the protocol behaviour here.

- The document notes that ""[I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] contains a list of criteria to evaluate potential solutions.  The protocol described in this document satisfies all of the required criteria." It may be useful the enumerate these crieria and explain how this protocol satisfies each of these criteria.

- The document notes that "it can take a signficant amount of time to detect a record collision after a network partition is repaired." and "a greater concern on networks where multicast streams may be established at any time.  Deployments on these networks may consider engaging a detection mechanism and prompting hosts to send unsolicited mDNS response messages when the partition is repaired." But I had the impression that this was exactly the scenario envisaged here, and I read this text as saying "Well you need to rely on some form of detection mechanisms mot described here. Seems to me that this is an extremely important shortcoming in this document.

- "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. Which document enumerates the criteria referred to here? What are these criteria? How are these criteria met? It may be helpful to have this document show how tjhese criteria are satisfied.

- "The "eth-addr.arpa." domain is effectively a reverse-mapping domain and so has the same considerations as the reverse-mapping domains listed in [RFC6761], Section 6.1." Multicast changes many things and I think this handwaving is inadequate here.There are a set of questions in RFC6761 that MUST be answered in this document before any name can be entered into the register of special use domain names.

- "Special thanks to the National Marine Electronics Association for their contributions in developing marine industry standards and their support for this research." - What "research" is being referred to here?