Hi, It otherwise looks good, but I think you should keep "Path Computation Element (PCE) [RFC4655]" in section 1, because it's the first occurance (not counting the Abstract).
Regards, Christer From: Daniel King [[email protected]] on behalf of Daniel King [[email protected]] Sent: Tuesday, 17 June 2014 7:23 PM To: Christer Holmberg; [email protected] Cc: draft-ietf-pce-pcep-inter-domain-p2mp-procedures....@tools.ietf.org; [email protected]; [email protected] Subject: RE: Gen-ART review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07 Hi Christer, We recently posted the new version with the agreed text updates to address the items you highlighted. Please let us know if the new versions addresses your comments. http://tools.ietf.org/html/draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08 Thanks for all your help and review effort. Br, Dan. From: Christer Holmberg [mailto:[email protected]] Sent: 10 June 2014 10:03 To: Daniel King; [email protected] Cc: draft-ietf-pce-pcep-inter-domain-p2mp-procedures....@tools.ietf.org Subject: RE: Gen-ART review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07 Hi Dan, I am happy with your reply and way forward :) Regards, Christer From: Daniel King [mailto:[email protected]] On Behalf Of Daniel King Sent: 6. kesäkuuta 2014 23:04 To: Christer Holmberg; [email protected] Cc: draft-ietf-pce-pcep-inter-domain-p2mp-procedures....@tools.ietf.org Subject: RE: Gen-ART review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07 Dear Christer, Thank you for your Gen-ART review, please see my responses inline (“DK>>”): Br, Dan. From: Christer Holmberg [mailto:[email protected]] Sent: 06 June 2014 09:01 To: [email protected] Cc: draft-ietf-pce-pcep-inter-domain-p2mp-procedures....@tools.ietf.org Subject: Gen-ART review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> 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. DK>> Agree. Well spotted, indeed: 1.2 Scope 3. Examination of Existing Mechanisms DK>> These can be truncated to “PCE”. Q2-G: Same as Q_G_1, but for PCEP, which I believe you in addition to the Introduction also expand in section 3. DK>> Agree. 3. Examination of Existing Mechanisms DK>> Again, this can be truncated to “PCEP”. 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? DK>> These are well-known terms, but we do also state we reuse terminology which is better defined in specific RFCs in our terminology section. In summary, I think its ok to leave “as is”. 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”? DK>> Agree. The word “usage” would be more apt. 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? DK>> Aha, I see the ambiguity. RFC6006 defines how PCEP is used to compute P2MP paths in single domain (intra-domain) networks. So perhaps a better word would be “defined” rather than “supported”. 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”) DK>> Agree. Q7_7: In section 7, s/ has following impact -/ has following impacts: DK>> Agree. In fact, I might suggest “has the following impact:” 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”. DK>> Agree. “requirements specified in section 6. 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.” DK>> Agree. 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 …” DK>> Ok, if you think it helps the reader. Q11_7_2: In section 7.2, s/ messages format as per [RFC5440]/ messages format defined in [RFC5440] DK>> Agree. 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”) DK>> Agree. Regards, Christer DK>> Again, thank you for your review and comments. Br, Dan. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
