Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP
draft-ietf-pals-p2mp-pw-04

Please check idnits. It flags some issues that should be resolved, especially 2119 language issues.

The security considerations seem inadequate. I'm no expert here, but it seems like adding p2mp support in addition to p2p support has a good chance of creating some new considerations. If it really doesn't, it would be helpful to see arguments to that effect.

Here is Sarah's OPS DIR review. Her Why (Do I care?) comment resonates with me: I could not find the information.

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments.

	I think the document is almost ready to go. I don't have technical issue with the content, but I think the document reads in parts like several authors cut/paste/contributed, and the document doesn't flow well in spots. Perhaps this is a personal choice, but I believe that documents that read with some amount of approachability with respect to all interested readers, and not just hard core whatever-the-protocol-is-fanatics, benefits our community for the better. Last, maybe it's the product manager in me, and not the development engineer, but why do I care? Is this just to add LDP as another mechanism for establishing the PW? Is there some deficit that's being addressed by LDP that existing mechanisms don't solve? This isn't addressed in a way that resonates in the document, for me.
	Last, while super picky, the acronym "PSN" was used in the abstract before being properly introduced. This was mostly made more noticeable by the fact that the rest of the draft does a fantastic job of introducing the terms before using the acronym.

I agree with Kathleen about the MD5 issue. I recognize it's not unique to this document, but eventually we do need to deal with it.

  intended for bidirectional service whereas the latter is intended for
   both unidirectional, and optionally bidirectional service.
   Requirements for P2MP PW are described in [RFC7338]. P2MP PW can be

This is quite hard to read because P2MP and P2P are close. Perhaps replace "former" and "latter" with names.

   constructed as either Single Segment (P2MP SS-PW) or Multi Segment
   (P2MP MS-PW) Pseudowires as mentioned in [RFC7338]. P2MP MS-PW is
   outside the scope of this document. A reference model or a P2MP PW is

Nit: you have singular/plural disagreement


   Parameters field in octets. If this value is 0, then it references
   all PWs using the specified grouping ID. In this case, there are
   neither other FEC element fields (AGI, SAII, etc.) present, nor any

Which grouping ID? It's not clear to me what field this corresponds to.

Thanks for addressing my DISCUSS point.