[Ballot discuss]
>    R = 1 indicates a multicast address that embeds the address on the
>    RP.  Then P MUST be set to 1, and consequently T MUST be set to 1, as
>    specified in [RFC3306].  If R = 1, but P is set to 0, the packet MUST
>    be discarded.  The behaviour if T is set to 0 when P is set to 1 is
>    derived from [RFC3306] and is unspecified in this memo.

"MUST be discarded" seems like a bad thing to specify. Are we really
saying there are illegal addresses that one is not allowed to use? (In
the unicast space, we have tried very hard not to have any addresses
that are "reserved" in the sense that implementations check for them
and don't process them.)  Better to leave unspecified, and have hosts
treat them as if they were normal multicast addresses (i.e, with no
special semantics)

>    RIID = 0 must not be used as using it would cause ambiguity with the
>    Subnet-Router Anycast Address [ADDRARCH].

Are there other conflicts?

Actually, a whole range of anycast addresses has been reserved. See
RFC 2526. So, the addresses in this document potentially conflict with
other ones. Need clarification on what the right thing to do is.

[Ballot discuss]
>    R = 1 indicates a multicast address that embeds the address on the
>    RP.  Then P MUST be set to 1, and consequently T MUST be set to 1, as
>    specified in [RFC3306].  If R = 1, but P is set to 0, the packet MUST
>    be discarded.  The behaviour if T is set to 0 when P is set to 1 is
>    derived from [RFC3306] and is unspecified in this memo.

MUST be discarded seems like a bad thing to specify. Are we really
saying there are illegal addresses that one is not allowed to use?
Better to leave unspecified, and have hosts treat them as if they
were  normal multicast addresses (i.e, with no special semantics)

>    RIID = 0 must not be used as using it would cause ambiguity with the
>    Subnet-Router Anycast Address [ADDRARCH].

Are there other conflicts?

Actually, a whole range of anycast addresses has been reserved. So,
the addresses in this document potentially conflict with other
ones. Need clarification on what the right thing to do is.

[Ballot comment]
Comments received from gen-art (by Mark Allman <mallman@icir.org>):

I'd say this draft is not quite ready.  A few points ....
                                                                                 
* I'd **really** like to see an introduction that says what problem is
  being solved in very high-level terms.  By the end of the document I
  sort of have an understanding, but I was immediately lost because
  the document seems to assume context that just isn't there for some
  of us.  I understand that this is really only going to be used by
  folks implementing, but still --- I don't think it too much to ask
  to craft a statement on the problem the document solves that
  everyone else can understand.
                                                                                 
* Please define all acronymns.  There are plenty of cases when an
  acronymn is just used without being defined or even spelled out.
  Please check them all.  (A concrete example is the use of "DR"
  starting in section 6.)
                                                                                 
* Likewise, this (S,G) notation is weird to an outsider.  A word or
  two about it's meaning would be useful (not an entire tutorial -- I
  understand the document is not for "outsiders", but a little help
  would be appreciated).
                                                                                 
* The text does not refer to appendix A, but should.
                                                                                 
* Section 3:
                                                                                 
  The first half of the section seems un-needed to me (before the
  diagram).  This text says things like if the flags are set to "01".
  But, that is not really what is meant.  Rather, the document is
  keying on the second bit being one.  At the moment, the first bit is
  unassigned and should be zero.  But, the document even notes that
  this may change in the future.  So, why does the document specify
  the first bit when it doesn't need to?

  Also, what happens when R=1 and either P or T (or both) are not 1?
  It seems that the failure cases should be considered more.
                                                                                 
* In the diagram on page 6, I assume "ID" is really "RIID"?  I'd
  suggest changing the diagram for consistency.

[Ballot discuss]
>    R = 1 indicates a multicast address that embeds the address on the
>    RP.  Then P MUST be set to 1, and consequently T MUST be set to 1, as
>    specified in [RFC3306].

The spec needs to say what to do if R==1 && P==0 && T==0

[Ballot discuss]
I don't get why Example 2 seperates "zzzz:zzzz" and [group ID].  You're really moving the boundary between group ID and prefix, right, so it's more like FF7x:y20:2001:DB8:[group ID], and the group ID is 64 bits in this case.  An alternate way of saying this is that using the 20 plen results in being able to assign addresses out of FF7x:y20:2001:DB8/64.

I think the confusing part is 'and "zzzz:zzzz" will be assignable to anyone'.  If you don't want to switch notations, please reword this part.

I don't see the difference between example 2 and example 3, other than that example 3 has a more concrete address (replaces zzzz:zzzz with DEAD::).

--

In the section on Group-to-RP Mapping, I think it would be useful to completely specify in the terms of the PIM algorithm - for example - For addresses in the range FF70::/12, the Embedded-RP mapping is considered to be the longest possible match and higher priority than any other mechanism - this uses the terms of the PIM spec to say
    the group-to-RP mapping specified
  in this memo MUST be used for all embedded-RP groups (i.e., addresses
  with prefix FF70::/12).
so is more likely to be easily implementable.

[Ballot discuss]
Perhaps I'm misreading this, but:

6.3. Guidelines for Assigning IPv6 Addresses to RPs

  With this mechanism, the RP can be given basically any network prefix
  up to /64. The interface identifier will have to be manually
  configured to match "RIID".

seems to limit this mechanism to entities which control a
specific prefix length.  That limit, though, does not appear
to be present in Example 1, and the discussion in the
"design trade-offs" section on this point (and the related
text in 3306) does not clarify it enough.  It seems to the
non-expert review that it would be better to start off with
something like "Within the prefix FF70::/12 ...." and go on
from there.  But some clarification would be appreciated.

IANA Last Call Comments:
There is not mention of IANA.  Does this affect the following
registries in any way?
<http://www.iana.org/assignments/ipv6-multicast-addresses>
<http://www.iana.org/assignments/perm-mcast-groupids>

We would just like this to be confirmed.