Last Call Review of draft-ietf-idr-add-paths-13
review-ietf-idr-add-paths-13-genart-lc-shirazipour-2016-04-28-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-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