[dnsdir] draft-ietf-pim-ipv6-zeroconf-assignment-07 early Dnsdir review

[Geoff Huston via Datatracker <[e-mail]>]

Document: draft-ietf-pim-ipv6-zeroconf-assignment
Title: Zero-Configuration Assignment of IPv6 Multicast Addresses
Reviewer: Geoff Huston
Review result: Not Ready

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?