Christer, Daniel, Thank you for the review and the responses. I have balloted “No-Objection” and expect that the edits will find themselves to a new draft version some day :-)
Jari On 06 Jun 2014, at 23:04, Daniel King <[email protected]> wrote: > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
