Last Call Review of draft-ietf-idr-route-oscillation-stop-02

Request Review of draft-ietf-idr-route-oscillation-stop
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-04-29
Requested 2016-04-18
Authors Daniel Walton, Alvaro Retana, Enke Chen, John Scudder
Draft last updated 2016-04-27
Completed reviews Genart Last Call review of -02 by Paul Kyzivat (diff)
Genart Last Call review of -02 by Paul Kyzivat (diff)
Secdir Last Call review of -02 by Chris Lonvick (diff)
Opsdir Last Call review of -02 by Jon Mitchell (diff)
Rtgdir Early review of -00 by Tony Przygienda (diff)
Rtgdir Early review of -02 by He Jia (diff)
Assignment Reviewer Paul Kyzivat
State Completed
Review review-ietf-idr-route-oscillation-stop-02-genart-lc-kyzivat-2016-04-27
Reviewed rev. 02 (document currently at 04)
Review result Ready with Issues
Review completed: 2016-04-27


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 

Document: draft-ietf-idr-route-oscillation-stop-02
Reviewer: Paul Kyzivat
Review Date: 2016-04-27
IETF LC End Date: 2016-04-29
IESG Telechat date: 2016-05-05


This draft is on the right track but has open issues, described in the 

Major: 0
Minor: 1
Nits:  0



I am somewhat confused about the intended status of this document. It is 
declared as Standards Track, and it does use a bit of 2119 language. But 
the majority of the few SHOULDs are qualified in ways that seem to give 
the implementer discretion without clear explanation. (E.g., "Depending 
on the configuration".)

If the document is intended to be normative, then I would think a key 
requirement would be to avoid making advertisements that lead to route 
oscillation, and to require the use of the mechanisms specified here 
unless some alternative approach is used.

Also, in general it is good when using "SHOULD" to identify the 
acceptable conditions for not following it. This would be one way to 
satisfy my above concern.