Hi Robert,
Thanks for your review.
On Mon, Sep 28, 2015 at 3:29 PM, Robert Sparks
<rjsparks(_at_)nostrum(_dot_)com> wrote:
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-teas-te-express-path-03
Reviewer: Robert Sparks
Review Date: 28 Sep 2015
IETF LC End Date: 30 Sep 2015
IESG Telechat date: 1 Oct 2015
Summary: Ready for publication as Informational, with nits
Nits/editorial comments:
This document is all about considerations. Specifically, it discusses what
to consider if you were to build a path computation function that uses the
kind of information you get from the TE metric extensions in RFC7471 and
draft-ietf-isis-te-metric-extensions. It does not appear to be requirements
for standardization work - rather, it is information for operators to use
when building functions that don't necessarily need standardization.
However, it looks as if the document may have once contemplated actually
specifying a path computation function, and has legacy text from that
thought?
No - it was always about how one could use the information and isn't trying
to standardize a particular function.
The abstract says "This specification uses network performance data ... to
perform such path selections." But this document doesn't perform such path
selections (or specify how to do them).
Would you prefer
"This specification describes how a path computation function may use
network performance data, such as is advertised via the OSPF and ISIS TE
metric extensions (defined outside the scope of this document) to perform
such path selections."
Section 1.1 says "The following are the requirements that motivate this
solution." But this draft doesn't actually specify a "solution". It
discusses what to consider if you were to build a path computation
function. Could this be framed as a set of goals to keep in mind while
building your own such function?
Would you be ok with changing it to ".. that motivate this document?"
The third paragraph of section 1.2 could use clarification. I suspect the
word "even" in the 4th sentence should be removed, and the judgement in
"There may be legitimate use" is out of place. Consider rewriting the
paragraph using simpler sentences.
I've removed the word "even" and changed the last sentence about "There may
be legitimate use..." to be
"However, there may be uses of a..."
Section 2.3 appears to be considerations specifically for interpreting the
anomalous bit in one specific extension? If so, the introduction to the
section should call that out. If not, the section's structure needs
improvement. The section also calls out two questions, but only discusses
one of them explicitly.
In Sec 2.3.1, the anomalous bit behavior is described for latency, loss,
and jitter. On double-checking, I see that the Anomalous Bit was removed
for jitter in RFC7471 and draft-ietf-isis-te-metric-extensions. I've
removed the last sentence in the second paragraph of 2.3.1 that discussed
how to handle that case.
Sec 2.3.2 discusses the second question and how to handle it in detail.
Thanks again for the review! The changes will be in 04.
Regards,
Alia
RjS