Dear Adrian, Thank you for your comments. We will address your comments after this last call as follows. > idnits shows a couple of issues with your references > > == Unused Reference: 'RFC3945' is defined on line 373, but no explicit > reference was found in the text > > == Unused Reference: 'RFC4927' is defined on line 402, but no explicit > reference was found in the text > > These both seem like relevant references and I suggest that you find a place > in the text to point to them. RFC3945 shall be referred in section 1, paragraph 2, sentence 2 as follows: As the same case with MPLS, service providers (SPs) have also come up with requirements for path computation in GMPLS-controlled networks [RFC3945] such as wavelength, TDM-based or Ethernet-based networks as well. RFC4927 shall be referred in section 1 paragraph 3 as follows: Note that the requirements for inter-layer and inter-area traffic engineering described in [RFC6457] and [RFC4927] are outside of the scope of this document. > Some work on acronyms, please. > > PCE needs to be expanded on first use in the Abstract and the main text > (not on the second use :-) > > OTOH, MPLS and GMPLS do not need to be expanded. > > PCC shows up in section 2.1 > PCReq and PCRep are in 2.1 (but expanded a little later) P2MP is in section > 2.2 ERO and XRO show in section 3.1 PCEP shows in section 3.2 All acronyms indicated above shall be correctly expanded or not expanded. > Section 1 para 4 seems to say that SRLG is covered in RFC 3473. Are you > sure? Or do you need a different reference? SRLG shall be moved to the previous sentence and refer RFC 4202 as follows: Constraint-based shortest path first (CSPF) computation within a domain or over domains for signaling GMPLS Label Switched Paths (LSPs) is usually more stringent than that of MPLS TE LSPs [RFC4216], because the additional constraints, e.g., interface switching capability, link encoding, link protection capability, SRLG (Shared Risk Link Group) [RFC4202] and so forth need to be considered to establish GMPLS LSPs. > In Section 3.1 reqs (1), (2) and (3) you appear to be limiting the supported > values to only those listed or those in the referenced RFCs. > > You may do better to say less. Just point at the base definition of the > signaling fields (in RFC 3473?) and then say "all current and future values". reqs (1), (2) and (3) shall be rewritten as follows: (1) Switching capability/type: as defined in [RFC3471], [RFC4203] and, all current and future values. (2) Encoding type: as defined in [RFC3471], [RFC4203] and, all current and future values. (3) Signal Type: as defined in [RFC4606] and, all current and future values. > Section 6 > > Julien Meuric not Meulic Sorry Julien, we shall correct this typo. Thanks, Kenichi -- Kenichi Ogaki KDDI | IP Transport Network Development Dept. +81-(0)80-5945-9138 | www.kddi.com > -----Original Message----- > From: Adrian Farrel [mailto:adrian@xxxxxxxxxxxx] > Sent: Saturday, May 25, 2013 7:20 PM > To: ietf@xxxxxxxx > Cc: draft-ietf-pce-gmpls-aps-req.all@xxxxxxxxxxxxxx > Subject: RE: [Pce] Last Call: <draft-ietf-pce-gmpls-aps-req-07.txt> > (Requirements for GMPLS applications of PCE) to Informational RFC > > Hi, > > Here are my review comments as responsible AD. Because they are minor > comments, I am entering them as part of IETF last call rather than getting > them fixed before last call. That should expedite the publication a little. > > Thanks, > Adrian > > === > > idnits shows a couple of issues with your references > > == Unused Reference: 'RFC3945' is defined on line 373, but no explicit > reference was found in the text > > == Unused Reference: 'RFC4927' is defined on line 402, but no explicit > reference was found in the text > > These both seem like relevant references and I suggest that you find a place > in the text to point to them. > > --- > > Some work on acronyms, please. > > PCE needs to be expanded on first use in the Abstract and the main text > (not on the second use :-) > > OTOH, MPLS and GMPLS do not need to be expanded. > > PCC shows up in section 2.1 > PCReq and PCRep are in 2.1 (but expanded a little later) P2MP is in section > 2.2 ERO and XRO show in section 3.1 PCEP shows in section 3.2 > > > --- > > Section 1 para 4 seems to say that SRLG is covered in RFC 3473. Are you > sure? Or do you need a different reference? > > --- > > In Section 3.1 reqs (1), (2) and (3) you appear to be limiting the supported > values to only those listed or those in the referenced RFCs. > > You may do better to say less. Just point at the base definition of the > signaling fields (in RFC 3473?) and then say "all current and future values". > > --- > > Section 6 > > Julien Meuric not Meulic > > > -----Original Message----- > > From: pce-bounces@xxxxxxxx [mailto:pce-bounces@xxxxxxxx] On Behalf Of > > The IESG > > Sent: 25 May 2013 02:26 > > To: IETF-Announce > > Cc: pce@xxxxxxxx > > Subject: [Pce] Last Call: <draft-ietf-pce-gmpls-aps-req-07.txt> > > (Requirements > for > > GMPLS applications of PCE) to Informational RFC > > > > > > The IESG has received a request from the Path Computation Element WG > > (pce) to consider the following document: > > - 'Requirements for GMPLS applications of PCE' > > <draft-ietf-pce-gmpls-aps-req-07.txt> as Informational RFC > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@xxxxxxxx mailing lists by 2013-06-07. Exceptionally, comments may > > be sent to iesg@xxxxxxxx instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > The initial effort of the PCE WG is specifically focused on MPLS > > (Multi-protocol label switching). As a next step, this draft > > describes functional requirements for GMPLS (Generalized MPLS) > > application of PCE (Path computation element). > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-aps-req/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-aps-req/ballot/ > > > > > > The following IPR Declarations may be related to this I-D: > > > > http://datatracker.ietf.org/ipr/1869/ > > _______________________________________________ > > Pce mailing list > > Pce@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/pce