Skip to main content

Last Call Review of draft-ietf-pce-rfc6006bis-03
review-ietf-pce-rfc6006bis-03-opsdir-lc-baker-2017-09-06-00

Request Review of draft-ietf-pce-rfc6006bis
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-08-24
Requested 2017-08-10
Authors Quintin Zhao , Dhruv Dhody , Ramanjaneya Reddy Palleti , Daniel King
Draft last updated 2017-09-06
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 Fred Baker
State Completed
Review review-ietf-pce-rfc6006bis-03-opsdir-lc-baker-2017-09-06
Reviewed revision 03 (document currently at 04)
Result Ready
Completed 2017-09-06
review-ietf-pce-rfc6006bis-03-opsdir-lc-baker-2017-09-06-00
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review. Document editors and WG chairs should treat
these comments just like any other last call comments.

I have read the document. I profess no particularly relevant protocol
expertise; apart from a general perception that the issues raised in section
two sound about right and that I don't see glaring issues in the protocol
description, I have little to say on that.

The operational question is how it will behave in a network, and whether it
will be suitable for the purpose. For this, I note the issues raised in the
Security Considerations, the remedies in RFC 5440 referenced there, and our
general experience with IP Multicast. Any statement can be made arbitrarily
complex by adding the words "using IP Multicast", and I suspect that might be
true of this as well. I would suggest that people deploying this in their
network give careful consideration to those unless and until we have enough
experience with the protocol to trust it. It is not without its dangers, but in
careful hands the proposed remedies should be adequate.

Hence, my summary: Be Ye Not Afraid. Suitably cautious, but not afraid :-)