Skip to main content

Last Call Review of draft-ietf-pce-rfc6006bis-02
review-ietf-pce-rfc6006bis-02-rtgdir-lc-niven-jenkins-2017-07-02-00

Request Review of draft-ietf-pce-rfc6006bis
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-05-12
Requested 2017-04-26
Requested by Deborah Brungard
Authors Quintin Zhao , Dhruv Dhody , Ramanjaneya Reddy Palleti , Daniel King
I-D last updated 2017-07-02
Completed reviews Secdir Telechat review of -03 by Charlie Kaufman (diff)
Rtgdir Last Call review of -02 by Ben Niven-Jenkins (diff)
Genart Last Call review of -03 by Roni Even (diff)
Opsdir Last Call review of -03 by Fred Baker (diff)
Assignment Reviewer Ben Niven-Jenkins
State Completed
Request Last Call review on draft-ietf-pce-rfc6006bis by Routing Area Directorate Assigned
Reviewed revision 02 (document currently at 04)
Result Has issues
Completed 2017-07-02
review-ietf-pce-rfc6006bis-02-rtgdir-lc-niven-jenkins-2017-07-02-00
 Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-pce-rfc6006bis-02
Reviewer: Ben Niven-Jenkins
Review Date: 2nd July 2017
Intended Status: Standards Track

Summary: I have some minor concerns about this document that I think should be
resolved before publication.

Comments: The document was generally well written and readable.

Major Issues: No major issues found.

Minor Issues:
1) Section 3.2 SERO & SRRO objects - In Section 6.5 you have them listed with
Object-Type 0: Reserved, whereas in section 3.2 you start at 1. you should be
consistent and list them the same in section 3.2 as you do in 6.5?

Also in Section 6.5 the reference is to [This I-D] whereas in section 3.2 it is
to [RFC6006].

2) Section 3.10 says “When adding new leaves to or removing old leaves from the
existing P2MP tree, by supplying a list of existing leaves, it SHOULD be
possible to optimise the existing P2MP tree.” I don’t see why you have used a
capitalised SHOULD here as you are simply making a statement rather than
placing a requirement on an implementation.

3) Section 5 says “PCEP implementations SHOULD consider the additional security
provided by Transport Layer Security (TLS) [I-D.ietf-pce-pceps].”

Use of SHOULD says to me you expect the majority of implementations to
implement I-D.ietf-pce-pceps. So should the reference to I-D.ietf-pce-pceps be
normative?

4) Section 6.5 - PCEP Objects. Should you specify the meaning of Object-Types
0, 1 & 2 for the END-POINTS object, like you do for the other objects in this
section?

Nits:
Section 3.9 says
“The only difference is that the user MUST insert the list of RROs and SRROs
after each type of END-POINTS in the PCReq message”

and Section 3.10 also says

“To add new leaves, the user MUST build a P2MP request using END-POINTS with
leaf type 1.”

“To remove old leaves, the user must build a P2MP request using END-POINTS with
leaf type 2.

“For old leaves, the user MUST provide the old path as a list of RROs that
immediately follows each END-POINTS object.”

You haven’t used or defined the term “user” up until now. By user do you really
mean PCC? If not I think you should explain what/who this user is.