Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)
draft-ietf-mpls-p2mp-sig-requirement-04

[Ballot discuss]
Technically unclear, and also needs substantial editorial work for
additional clarity.

From Gen-ART review by Harald Alverstrand:

The chief reason is that it does not properly define its target mission. For a document that is a requirements document for point-to-multipoint signalling, it strangely never defines what a point-to-multipoint service is.

From context, it appears to be an unidirectional service capable of
delivering a signal (a lightstream, bitstream or packet stream?) to multiple destinations. But it never discusses the metric that distinguish such a service from a P2P service - namely, whether or not there is a requirement for a consistent service to all destinations, or whether the consistency is part of the quality constraints that the solution has to allow explicit engineering for.

The control model of the service is also unclear.

From context, it appears that one envisions that recipients can join and
leave the tree while it's running; it's not clear whether the requirement is like that for a P2P path, where establishment always involves the head-end of the path, or whether a reasonable solution to the requirements can allow grafting and pruning down the tree without the head-end being involved (as happens in the "traditional IP multicast" service).

Section 4.20 (on GMPLS) is a surprise. While the rest of the document has been carefully phrased in technology-avoiding language (although concepts that I think of as RSVP-TE shine through on a regular basis), this section blatantly specifies specific RSVP-TE objects and features that "have to be" supported. This seems out of place.

The document's security section is inadequate. For a requirements document, I expect the security section to state the security requirements for a solution - in this case, these are likely to be very similar to those for P2P signalling, which (if I understand it correctly) involve identifying the LSRs to each other, and validating that the requester of service has the right to request service (which requires head-end identification to all downstream nodes in some fashion).

In the P2MP context, I would also expect requirements on the listeners - whether or not the head-end is required to be able to identify all egress points seems like a security issue to me.

I'm also unhappy with the clarity of the writing in a number of places - I'll follow up with another message containing a marked-up copy of the draft. [made available to document shepherds and editor]