Last Call Review of draft-ietf-idr-add-paths-13
review-ietf-idr-add-paths-13-genart-lc-shirazipour-2016-04-28-00

Request Review of draft-ietf-idr-add-paths
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-04-29
Requested 2016-04-18
Draft last updated 2016-04-28
Completed reviews Genart Last Call review of -13 by Meral Shirazipour (diff)
Genart Last Call review of -13 by Meral Shirazipour (diff)
Rtgdir Early review of -10 by Mach Chen (diff)
Rtgdir Early review of -10 by Carlos Pignataro (diff)
Assignment Reviewer Meral Shirazipour
State Completed
Review review-ietf-idr-add-paths-13-genart-lc-shirazipour-2016-04-28
Reviewed rev. 13 (document currently at 15)
Review result Ready with Nits
Review completed: 2016-04-28

Review
review-ietf-idr-add-paths-13-genart-lc-shirazipour-2016-04-28






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-add-paths-13




Reviewer: Meral Shirazipour




Review Date: 2016-04-28




IETF LC End Date: 2016-04-29




IESG Telechat date: 2016-05-05




 




 




Summary:




This draft is ready to be published as Standards Track RFC but I have some comments.




 




Major issues:




 




Minor issues:




-[Page 2] The introduction should give a hint of why this extension is necessary. Section 6 (Application) is pretty much empty in content too.




It would be important to add a few lines explaining the use cases and if any draft is started on those to give a pointer to them.




*An "Add-Paths Applications" section would be useful like the one in draft-ietf-idr-add-paths-guidelines-08.




 




 




-[Page 3], 




"A BGP




   speaker that receives a route SHOULD NOT assume that the identifier




   carries any particular semantics; it SHOULD be treated as an opaque




   value.




"




*It would be good to justify why this restriction is imposed. If someone is using BGP add-Path internally, why prevent giving some semantics to the encoding?




 




 




-[Page 6], security section refers to Information guideline draft (draft-ietf-idr-add-paths-guidelines-08).





Is this draft also for IBGP only ? this was not clear.




 




 




Nits/editorial comments:




-[Page 7], References should be updated to newer versions.




 




 




 




 




Best Regards,




Meral




---




Meral Shirazipour




Ericsson




Research




www.ericsson.com