The following edits make the document more readable/understandable to me: Abstract Existing: This document specifies extensions to mLDP to support MTR with FA such that when building a Multipoint LSPs(Label Switched Paths) it can follow a particular topology and algorithm. Better: This document specifies extensions to mLDP to support MTR, with FA, in order for Multipoint LSPs(Label Switched Paths) to follow a particular topology and algorithm. 4. MT Scoped mLDP FECs Existing: The same applies to the IPA. The IPA needs to be encoded as part of the mLDP FEC to create unique MP-LSPs and at the same time is used to signal to mLDP (hop-by-hop) which Algorithm needs to be used to create the MP-LSP. Better: The same applies to the IPA. The IPA needs to be encoded as part of the mLDP FEC to create unique MP-LSPs. The IPA is also used to signal to mLDP (hop-by-hop) which Algorithm needs to be used to create the MP-LSP. 6.1. Typed Wildcard MP FEC Elements Existing: The MT extensions proposed in document do not require any extension in procedures for Typed Wildcard FEC Element support [RFC5918], and these procedures apply as-is to Multipoint MT FEC wildcarding. Like Typed Wildcard MT Prefix FEC Element, as defined in [RFC7307], the MT extensions allow use of "MT IP" or "MT IPv6" in the Address Family field of the Typed Wildcard MP FEC element in order to use wildcard operations for MP FECs in the context of a given (sub)-topology as identified by the MT-ID and IPA field. Better: The MT extensions, proposed in this document, do not require any extension to procedures for Typed Wildcard FEC Element support [RFC5918] and these procedures apply as-is to Multipoint MT FEC wildcarding. Similar to Typed Wildcard MT Prefix FEC Element, as defined in [RFC7307], the MT extensions allow use of "MT IP" or "MT IPv6" in the Address Family field of the Typed Wildcard MP FEC element. This is done in order to use wildcard operations for MP FECs in the context of a given (sub)-topology as identified by the MT-ID and IPA field. 8. LSP Ping Extensions Existing: The rules and procedures of using this new sub-TLV in an MPLS echo request message are same as defined for P2MP/MP2MP LDP FEC Stack Sub-TLV in [RFC6425] with only difference being that Root LSR address is now (sub-)topology scoped. Better: The rules and procedures of using this new sub-TLV in an MPLS echo request message are the same as defined for P2MP/MP2MP LDP FEC Stack Sub-TLV in [RFC6425]. The only difference is that the Root LSR address is now (sub-)topology scoped. 10. Security Considerations Existing: This extension to mLDP does not introduce any new security considerations beyond that already apply to the base LDP specification [RFC5036], base mLDP specification [RFC6388], and MPLS security framework [RFC5920]. Better (applied rather than apply): This extension to mLDP does not introduce any new security considerations beyond that already applied to the base LDP specification [RFC5036], base mLDP specification [RFC6388], and MPLS security framework [RFC5920].