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.
signature.asc
Description: PGP signature
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
