Skip to main content

Telechat Review of draft-ietf-teas-te-express-path-03
review-ietf-teas-te-express-path-03-genart-telechat-sparks-2015-12-14-00

Request Review of draft-ietf-teas-te-express-path
Requested revision No specific revision (document currently at 05)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-09-29
Requested 2015-09-23
Authors Alia Atlas , John Drake , Spencer Giacalone , Stefano Previdi
I-D last updated 2015-12-14
Completed reviews Genart Last Call review of -03 by Robert Sparks (diff)
Genart Telechat review of -03 by Robert Sparks (diff)
Secdir Last Call review of -03 by Christian Huitema (diff)
Opsdir Last Call review of -03 by Susan Hares (diff)
Assignment Reviewer Robert Sparks
State Completed
Request Telechat review on draft-ietf-teas-te-express-path by General Area Review Team (Gen-ART) Assigned
Reviewed revision 03 (document currently at 05)
Result Ready w/nits
Completed 2015-12-14
review-ietf-teas-te-express-path-03-genart-telechat-sparks-2015-12-14-00
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?

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).

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?

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.

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.

RjS