Bit Indexed Explicit Replication
charter-ietf-bier-02

1. The first work item says the WG "will specify the information that is required by a BIER header to support BIER forwarding."  That doesn't parse right to me.  Will the WG specify what information is needed by a router to support BIER forwarding?  Will the WG specify what information is needed in a BIER header?  A little clarification would be good.

2. Work item #2 (non-MPLS data plane) combined with the last paragraph of the charter seems to preclude the WG from looking at the BIER and PIM/IGMP/MLD interactions.  Is that the intent?

3. Does the WG need to develop an Applicability Statement for the non-MPLS data plane, if they choose to move that direction?

4. Does the charter require the WG to publish the use cases document?

So the size of the bier domain is bounded I suppose by the number of egress points you're willing to include in your header. given the inherent suitability of such a method for overlays it seems like it distinctly bounds the size of such an overlay based on the header size/  if you chain bier domains (no subdomain) how do you do loop detection (or don't you).

One question. This text

   9) Deployment Experience: Once there is deployment experience, the
   WG will produce a document describing the benefits, problems, and
   trade-offs for using BIER instead of traditional multicast
   forwarding mechanisms.  Ideally, this should also contain an
   analysis of the impact and benefit of the new BIER data-plane to
   the overall Internet architecture.  This document is intended to be
   used to evaluate whether to recharter BIER to produce Standards
   Track RFCs.
   
seems like a lot of words to say "once there is deployment experience, BIER may be rechartered to produce Standards Track RFCs". Do you need to define the gates they must pass through now? (What if you think of something else later?)

"produce a document" sounds like we're likely to be having the usual discussion about whether to publish a working paper as an RFC when that happens. If they sent the ADs an e-mail, would that be wrong?

I'm fine with this going for external review.

I would like to see the security properties of Bier called out more
as something that the proposed WG will address, e.g. does the
work to date include any integrity mechanisms so that one could
check if a bit-flip is causing packets to be sent to the "wrong"
places? Is there some (usable) security mechanism in place 
for establishing the bit-mask value to use at ingress? Etc.