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?