Bit Indexed Explicit Replication
charter-ietf-bier-02

I support Alissa's BLOCK.

Some of the proposed deliverables appear to potentially be support documents <https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html> -- items 3) and 8) in particular appear to fall into this category. I would like to see the charter explicitly indicate, for each of these two deliverables, whether the documents will be proposed for publication as RFCs.

Thanks for addressing my BLOCK.

I support Alissa's BLOCK comments.

Otherwise, I have some mainly editorial comments:

"  1) Transition Mechanisms and Partial Deployments: The WG will
     describe how BIER can be introduced in existing multicast
     networks to shift multicast delivery either end-to-end or in part
     of a network from mechanisms such as PIM, ng-MVPN, etc."

I can't parse that sentence, especially after "end-to-end". I wonder if two different ideas got merged. 

" 3) Use Case:"

I suspect that should be "Use Cases".

"  5) Management models:"

Would it make sense to say "Management data models"? (remembering there are still kinds of models other than yang models :-) )

Thanks for addressing my BLOCK.

Thanks for addressing my concerns!

There's no mention of security.  I know the options aren't great with MPLS, but is there anything that could/should be done?  It's late or I'd have better suggestions. I wanted to note this gap and may have better suggestions in the morning.

Most of these observations are attempts at friendly amendments, but I'm really thinking the first one needs help. The existing working group participants may understand that perfectly, but I'm not even close to understanding.

I'm not sure I can parse this text.

     A minimum of the necessary mechanisms
     to support incremental deployment and/or managing
     different BIER mask-length compatibility may be defined.

If I was guessing, I'd guess 

     At a minimum, the necessary mechanisms needed to 

     o support incremental deployment, 
     o manage different BIER mask-length compatibility
     o or both

     may be defined.

but guessing isn't helping me understand clearly. What am I getting wrong?

Unless "non-congruent topologies" is a term of art in this text,

     Operation of BIER in non-congruent topologies, i.e.
     topologies where not all routers are BIER capable can
     also be addressed.

ISTM that

     Operation of BIER in topologies where not all routers 
     are BIER capable can also be addressed.

would be clearer. (Since the term is expanded, I assumed it wasn't a term of art)

I think I understand where 

     Each such mechanism must include an
     applicability statement to differentiate its necessity from
     other proposed mechanisms.

is headed, but ISTM that as stated, this is combinatorial - every time a new mechanism shows up, all the previously proposed mechanisms must add a statement about differentiation from the new mechanism. I bet that's not what's intended. Perhaps maintaining a separate applicability statement differentiating between all mechanisms would be more tractable?

I note that 

 8) BIER Traffic Engineering:  An architecture for BIER-TE is defined
     in draft-ietf-bier-te-arch; associated fundamental technology is 
     included.

says "is defined", but that draft looks like a -00 that's a couple of weeks old. Would "is being defined" be more accurate? (This is not the usual moan about naming individual drafts as starting points in a new working group)

In 

 13) Applicability of BIER to Applications: The WG may advise on the
      applicability of BIER to various applications.

is "advise" intended to be some flavor of RFC, or just a "sounds like a plan"/"sounds like a bad idea" e-mail? I don't need to know the answer to that, but the working group might benefit from knowing it.

I wonder if the paragraph about working groups to be coordinated with and advised would be clearer as a bulleted list?