Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP

Note: This ballot was opened for revision 03 and is now closed.

Deborah Brungard Yes

Ben Campbell No Objection

Comment (2017-08-28 for -03)
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.

(Benoit Claise) No Objection

Comment (2017-08-31 for -03)
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.

Spencer Dawkins No Objection

Suresh Krishnan (was Discuss) No Objection

Comment (2017-11-12)
Thanks for addressing my DISCUSS point.

Mirja K├╝hlewind No Objection

Terry Manderson No Objection

Eric Rescorla No Objection

Comment (2017-08-30 for -03)
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.

Alvaro Retana No Objection

Adam Roach No Objection

(Kathleen Moriarty) (was Discuss) Abstain

Comment (2017-12-22)
In response my discuss, a document to detail out security options was promised, but has not materialized as of yet.  While the added text for my discuss points out that MD5 isn't the best choice, there is no alternative or even a plan to follow from this document (a reference to the promised draft would have been helpful, but it doesn't exist yet).  As such, I am abstaining.  I do hope that document will be pursued and the routing ADs will ensure follow through.