Population Count Extensions to Protocol Independent Multicast (PIM)
draft-ietf-pim-pop-count-07

I had been wondering, at the start of reading this, why it was going to turn out as Experimental, and thank you for explaining that.  I wish such explanations were always there, and I think it helps a lot.

- Same question as Stephen on my side.
As an OPS A.D., I have to ask: Any connection with the PIM MIB, RFC5060? Or any other MIB module?
Or is the new information only available via a show command in the routers (as a starting point because it's experimental)?

- I found that many acronyms are not expanded (IGMP, MLD, SSM, ASM, etc..), and are missing references.
Sure they're known if you know multicast.
However, the RFC-editor will flag those, so you might consider easing the RFC-editor lives and at the end the reader not that familiar with multicast

I have no objection to the publication of this experimental document and only have a few non-blocking comments.  Take them or leave them as you see fit.

1. The definition of the A/S flag pair seems incorrect.  If A=0 and S=1, that does not mean that all receivers are "only SSM" receivers.  It means that all receivers are SSM-capable.  The group joined will have an influence on whether all receivers are operating in SSM mode.

2. The idea of tracking if an OIF list crosses a domain boundary is interesting.  How would a router know that a particular OIF links to another domain?  Is it driven by what protocol caused the OIF to be added (e.g., MSDP in IPv4)?  It would be good to expand on how that is determined, if there is a standard way to detect it.

3. Given the use of a PIM Join attribute, these statistics can aggregate up a multicast distribution tree.  What I would be interested in seeing is *how* a network operator accesses these stats.  Is it envisioned that a router's CLI will be used since there is no defined way to push/pull the data out via a management interface?

4. It is unclear to me how useful the time zone information will be.  As mentioned in the draft, that information could be contained as an interface attribute.  However, that may not be sufficient given multi-access interfaces.  Is there more context that can be added as to how these time zone "boundaries" are detected/configured/managed?

  The Gen-ART Review by Pete McCann on 19-Jun-2012 raised two questions
  that deserve a response.

   (1) The Transit and Stub oif-List counts are only 2 octets.  Will
       these fields be large enough to contain the totals for a large
       multicast distribution tree?

   (2) Are there any alignment constraints on the options?  It looks
       like all the two-octet options come first and the single-octet
       options come last.  However, is this a requirement for any
       future options that may be defined?

s3: Any reason you decided to list the Flags in reverse order from the figure?

Seems like a good experiment. I wondered if there are any MIB
modules for PIM and, if so, if the stats here are commensurate
with what the MIB calls for measuring.