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
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
