Skip to main content

Last Call Review of draft-ietf-isis-route-preference-02
review-ietf-isis-route-preference-02-genart-lc-sparks-2015-10-27-00

Request Review of draft-ietf-isis-route-preference
Requested revision No specific revision (document currently at 02)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-10-30
Requested 2015-10-22
Authors Les Ginsberg , Stephane Litkowski , Stefano Previdi
I-D last updated 2015-10-27
Completed reviews Genart Last Call review of -02 by Robert Sparks
Secdir Last Call review of -02 by Hannes Tschofenig
Opsdir Last Call review of -02 by Ron Bonica
Assignment Reviewer Robert Sparks
State Completed
Request Last Call review on draft-ietf-isis-route-preference by General Area Review Team (Gen-ART) Assigned
Reviewed revision 02
Result Ready
Completed 2015-10-27
review-ietf-isis-route-preference-02-genart-lc-sparks-2015-10-27-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-isis-route-preference
Reviewer: Robert Sparks
Review Date: 27Oct2015
IETF LC End Date: 30Oct2015
IESG Telechat date: Not yet scheduled

Summary: Ready for publication as Proposed Standard

This document reads easily despite most of it being detailed lists. I
have no objection to it moving forward, but I would like to check one thing:

The sparsity of detail at the end of section 2, where you call out
potential interoperability issues and suggest that "implementers may
wish to support transition mechanisms" is concerning.  It might be worth
being explicit here about the interoperability issues, and what a
transition mechanism might look like, particularly if there's a chance
of having to deal with a peer that won't implement what's described in
this draft?

Did the group consider defining a couple of new code points and
deprecating these two, to avoid that transition issue?