Anycast-RP Using Protocol Independent Multicast (PIM)
draft-ietf-pim-anycast-rp-07

Non-blocking comments from Gen-ART review by Joel Halpern:

minor:
    I am not sure calling section 2.0 "Requirements" is a good use of naming.  Section 2 is a really useful section.  It describes what you are trying to do nicely and clearly.  But "requirements" it isn't.  "Overview"would do nicely as a title.

    It seems to require interesting management control to achieve the conditions required to mix non-supporting RPs into this, as described in section 4.0.  I understand that technically, as long as the non-supporting RP has only receivers, it works.  But a little more explication as to when / how this can be ensured might be appropriate.

    Isn't it a bit odd for the authors to thank themselves?  The work they are acknowledging is worth noting (the authors did two prototypes of the draft.)  But different wording might be nice. 

[BC: "The authors thank each other..."?]

  Section 3.0 says:
  >
  > RP1 is configured with RP2 and RP3's IP address.
  >
  I suggest the following rewording:
  >
  > RP1 is configured with the IP addresses of RP2 and RP3.

The draft says :

  o An IP address is chosen to use as the RP address. This address is
     statically configured, or distributed using a dynamic protocol, to
     all PIM routers throughout the domain.


Later requirements indicate that this is inserted into the unicast
routing system, so this is a unicast address.  It might be useful to
specify that here.  

It might also be useful to specify whether any events
in the unicast routing system have an impact on this mechanism
either in set-up or in later operation.