Early Review of draft-ietf-idr-as-migration-05
review-ietf-idr-as-migration-05-rtgdir-early-morin-2015-06-04-00

Request Review of draft-ietf-idr-as-migration
Requested rev. no specific revision (document currently at 06)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2015-06-04
Requested 2015-05-06
Draft last updated 2015-06-04
Completed reviews Secdir Last Call review of -03 by Paul Wouters (diff)
Rtgdir Early review of -02 by Thomas Morin (diff)
Rtgdir Early review of -05 by Thomas Morin (diff)
Assignment Reviewer Thomas Morin
State Completed
Review review-ietf-idr-as-migration-05-rtgdir-early-morin-2015-06-04
Reviewed rev. 05 (document currently at 06)
Review result Has Nits
Review completed: 2015-06-04

Review
review-ietf-idr-as-migration-05-rtgdir-early-morin-2015-06-04

Hello,



In the context of Routing Area QA reviews (see 


https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

 ), 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 ‚Äč 


http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir








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.






//// Note well: this review comes as a complement to a first review I 


did last September. ////





Document: 

http://tools.ietf.org/html/draft-ietf-idr-as-migration-05


Reviewer: Thomas Morin
Review Date: 2015-06-02
Intended Status: standards track

*Summary:* This document is I think ready for publication.

*Comments:*



This is overall a very well written document, with a clear goal and 


addressing its target goal.






Although it is all about local behavior, it makes sense to make a 


standard track document that (a) can be used as a reference for 


implementors and deployers to implement this properly, and (b) keep 


track of these features in future evolutions of the protocol (as 


motivated in the Conclusion section of the document).






The document has taken into account my comments made on -02, and has 


gone to additional changes that bring significant improvements to the 


document.




*Major Issues:*  No major issues found

*Minor Issues:*



- it sounds weird to name "customer C" the customer attached to ISP B, 


not naming it, or naming it CE-B would better match figures 4 and 5



- figures 1 and 2 could be left-right reversed to match fig 4 and 5


- "are service interrupting to the eBGP sessions of the PE", maybe could 


be worded as "result in a service interruption of eBGP sessions of the 


PE" ?  (or, at least,  "service-interrupting", with a dash)





_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.