Last Call Review of draft-ietf-idr-route-oscillation-stop-02
review-ietf-idr-route-oscillation-stop-02-genart-lc-kyzivat-2016-04-27-00
| Request | Review of | draft-ietf-idr-route-oscillation-stop |
|---|---|---|
| Requested revision | 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 | |
| I-D 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 M. 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 | |
| Request | Last Call review on draft-ietf-idr-route-oscillation-stop by General Area Review Team (Gen-ART) Assigned | |
| Reviewed revision | 02 (document currently at 04) | |
| Result | Ready w/issues | |
| Completed | 2016-04-27 |
review-ietf-idr-route-oscillation-stop-02-genart-lc-kyzivat-2016-04-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-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 Summary: This draft is on the right track but has open issues, described in the review. Major: 0 Minor: 1 Nits: 0 ========== MINOR: 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.