Last Call Review of draft-ietf-ospf-link-overload-09

Request Review of draft-ietf-ospf-link-overload
Requested rev. no specific revision (document currently at 16)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-12-22
Requested 2017-11-29
Requested by Acee Lindem
Authors Shraddha Hegde, Pushpasis Sarkar, Hannes Gredler, Mohan Nanduri, Luay Jalil
Draft last updated 2017-12-22
Completed reviews Rtgdir Last Call review of -09 by Martin Vigoureux (diff)
Genart Telechat review of -10 by Joel Halpern (diff)
Secdir Telechat review of -11 by Sean Turner (diff)
Opsdir Telechat review of -13 by Tim Chown (diff)
Genart Last Call review of -11 by Joel Halpern (diff)
Genart Telechat review of -12 by Joel Halpern (diff)
It is not a long draft so hoping it can be reviewed this year.
Assignment Reviewer Martin Vigoureux 
State Completed
Review review-ietf-ospf-link-overload-09-rtgdir-lc-vigoureux-2017-12-22
Reviewed rev. 09 (document currently at 16)
Review result Has Nits
Review completed: 2017-12-22



I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see 

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-ospf-link-overload-9
Reviewer: Martin Vigoureux
Review Date: 2017-12-22
IETF LC End Date: date-if-known
Intended Status: Standard Track

This document is basically ready for publication, but has nits (see 
Comments) that should be considered prior to publication.

So, before accepting this review I took a look at the draft and told 
myself "oh, not long, not apparently complicated.". Then I started 
reading it...
I have to admit that beyond the apparent simplicity of the objective, I 
did not understand much at first read. So I went on reading the mailing 
list and discovered a field of information and more specifically 
discussions explaining why certain design choices were made.

These are missing in the draft. I think that we should not expect 
readers and implementers to dig into the mailing list to understand the 
design described in a draft.

So I'd like to encourage the authors to add some text which summarizes 
the discussions that happened on the list and which explains why such 
and such design was in the end decided.