I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at   Document:                         draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07   Reviewer:                           Christer Holmberg   Review Date:                     6 June 2014   IETF LC End Date:             26 May 2014   IETF Telechat Date:        12 June 2014   Summary:                         The document is well written, with some editorial nits that the authors may want to address before publication.   Major Issues: None   Minor Issues: None   Editorial nits:   Q1-G:                                    In the Introduction section, you expand PCE (“Path Computation Element (PCE)”). After that, I suggest you don’t expand it anymore. I think you do it in a couple of places, in section 1.2 and 3.     Q2-G:                                    Same as Q_G_1, but for PCEP, which I believe you in addition to the Introduction also expand in section 3.     Q3_1:                                    In section 1, the draft says:   “The ability to compute constrained Traffic Engineering Label Switched Paths (TE                 LSPs) for point-to-multipoint (P2MP) LSPs in Multiprotocol Label                 Switching (MPLS) and Generalized MPLS (GMPLS) networks across                 multiple domains are therefore required.”                                                   Are all these so called well-known terms (I guess at least MPLS is), or would it be useful to add some references when/if appropriate?     Q4_1_2:                               In section 1.2, the draft says:                   “The experiment is intended to enable research for the Path Computation Element (PCE)”                                                   Do you mean to say “to enable research of the usage of the PCE”?     Q5_1_2:                               In section 1.2, the draft says:                   “This document is not intended to replace the intra-domain P2MP path                 computation approach supported by [RFC6006],”                                                   It is a little unclear to me what you mean be “supported by”. Does RFC 6006 defined the approach, or does RFC 6006 use an approach defined somewhere else, or?     Q6-7_4_2:                           In section 7.4.2, s/ The procedure as described in this document/The procedure described in this document           (remove “as”)     Q7_7:                                    In section 7, s/ has following impact -/ has following impacts:     Q8_7:                                    In section 7, instead of saying “requirements specified in the previous section”, please point to the actual section, e.g. “requirements specified in section X of this document”.     Q9_7:                                    In section 7, the text says:                   “The following sections describe the core-tree based procedures to                 satisfy the requirements specified in the previous section.”                                                   Would it be good to also mention the PCEP extensions? E.g.:                   “The following sections describe the core-tree based procedures, including PCEP extensions, to satisfy the requirements specified in the previous section.”     Q10_7:                                  As section 7 (including the sub sections) is quite large, I would suggest to have a section called “7.1 General”:                   “7.  P2MP Path Computation Procedures                   7.1. General   A P2MP Path computation can be broken down into two steps of core-                 tree computation and grafting of sub-trees. Breaking the procedure                 …”     Q11_7_2:                             In section 7.2, s/ messages format as per [RFC5440]/ messages format defined in [RFC5440]     Q12_7_4_2:                        In section 7.4.2, s/ The procedure as described in this document/ The procedure described in this document           (remove “as”)       Regards,   Christer