Robert - Thanx for the review. Responses inline. > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@xxxxxxxxxxx] > Sent: Tuesday, October 27, 2015 12:14 PM > To: General Area Review Team; draft-ietf-isis-route-preference.all@xxxxxxxx; > ietf@xxxxxxxx; isis-wg@xxxxxxxx > Subject: Gen-art LC review: draft-ietf-isis-route-preference-02 > > 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? > [Les:] Appendix A provides a real-life example of how the interoperability issue manifests itself. As far as how a transition mechanism might be implemented this gets into non-normative aspects. I have always had a strong bias for avoiding non-normative statements in specifications. Transition here really means having some configuration knob to specify whether old/new behavior should be used. Specifying a CLI is not something I would want to put into a standard. For folks who have an IS-IS implementation it isn’t difficult to figure out how to do this. > Did the group consider defining a couple of new code points and deprecating > these two, to avoid that transition issue? [Les:] This would not help - it would only make things more difficult. You would then have to deal with the transition between the old TLV and the new TLV - which has a much broader impact because it affects all IPv6 prefix reachability advertisements in all deployments - whereas the existing problem only occurs in certain deployments (multiple instances of IS-IS on the same router with redistribution between the instances at Level-2). Les