Early Review of draft-ietf-pce-pcep-service-aware-11
review-ietf-pce-pcep-service-aware-11-rtgdir-early-hopps-2016-08-09-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-pcep-service-aware-11
Reviewer: Christian Hopps
Review Date: August 7th, 2016
IETF LC End Date: Unknown
Intended Status: Standards Track

Summary:
========

    This document is basically ready for publication, but has nits that
    should be considered prior to publication.

Comments:
=========

    This document is clearly written and easy to understand.

Major Issues:
=============

    No major issues found.


Minor Issues:
=============

    - [4.1.5.1] Indicates inserting second METRIC object is optional ("may"),
      but doesn't say MUST or MAY for the first METRIC object. The implication
      is that the first METRIC object is required in the reply, if this isn't
      the case then a MAY/SHOULD would be useful here as well.

Nits:
=====

    - [4.1.5.1] uppercase "may" to MAY.

    - [4.2.1] parenthetical reference uses ``"Utilized Bandwidth"'' to refer to
      the IS-IS and OSPF values which are actualy defined in their respective
      documents using the text: "Unidirectional Utilized Bandwidth". I suggest
      updating this to match the referenced documents (i.e., add
      "Unidirectional").

    - [4.2.1] It's clear to me that the first paragraph is defining what LBU is;
      however, it never actually says this explicitly incase you wanted to.

    - [4.3] I found the formatting a bit odd with the "Objective Function Code:"
      the "Name:" and "Description:" being the final lines in the section
      defining them, but it's also hard to misinterpret the text when you
      actually read it so I don't know if any changes are needed.

    - [4.3 last paragraph] an unnamed procedure is referred to in RFC5541 here,
      I believe its use is more thoroughly described earlier in the document
      under "[4.2.3.1] Elements of Procedure", if so perhaps the reference
      should be to the text earlier in this document?

    - [6.1, 6.2] It's interesting that this text is actually replacing the
      message definition from the original specification. I understand it's
      trying to show where the new <bu-list> fits in, but it also is sort of
      redefining the actual makup of the entire message format. Using this
      method of description, each future extension to a message format must comb
      through any and all previous extensions, and also incorporate their
      changes as well; however, as this document isn't actually replacing
      RFC5541 (and neither would other extensions), or the STATEFUL-PCE
      document, so there's no document pointer trail to follow to do this --
      it's messy. A simple way to avoid this would be to present the change to
      the message definition using a diff like format indicating where the new
      <bu-list> fits into the already defined format and leave the overall
      definition of the message format in RFC5541.


Attachment:


signature.asc




Description:

 PGP signature