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:adr...@olddog.co.uk]
> Sent: Saturday, May 25, 2013 7:20 PM
> To: ietf@ietf.org
> Cc: draft-ietf-pce-gmpls-aps-req....@tools.ietf.org
> 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-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of
> > The IESG
> > Sent: 25 May 2013 02:26
> > To: IETF-Announce
> > Cc: p...@ietf.org
> > 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@ietf.org mailing lists by 2013-06-07. Exceptionally, comments may
> > be sent to i...@ietf.org 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
> > p...@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce


Reply via email to