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