Last Call Review of draft-ietf-grow-ix-bgp-route-server-operations-03
review-ietf-grow-ix-bgp-route-server-operations-03-opsdir-lc-comstedt-2014-10-17-00
Request | Review of | draft-ietf-grow-ix-bgp-route-server-operations |
---|---|---|
Requested revision | No specific revision (document currently at 05) | |
Type | IETF Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2014-10-14 | |
Requested | 2014-09-12 | |
Authors | Nick Hilliard , Elisa Jasinska , Robert Raszuk , Niels Bakker | |
I-D last updated | 2018-12-20 (Latest revision 2015-06-08) | |
Completed reviews |
Genart IETF Last Call review of -03
by Dan Romascanu
(diff)
Genart Telechat review of -03 by Dan Romascanu (diff) Secdir IETF Last Call review of -03 by Catherine Meadows (diff) Opsdir IETF Last Call review of -03 by Niclas Comstedt (diff) Rtgdir IETF Last Call review of -03 by John Scudder (diff) |
|
Assignment | Reviewer | Niclas Comstedt |
State | Completed | |
Request | IETF Last Call review on draft-ietf-grow-ix-bgp-route-server-operations by Ops Directorate Assigned | |
Reviewed revision | 03 (document currently at 05) | |
Result | Has nits | |
Completed | 2014-10-17 |
review-ietf-grow-ix-bgp-route-server-operations-03-opsdir-lc-comstedt-2014-10-17-00
Hi, I reviewed draft-ietf-grow-ix-bgp-route-server-operations-03 for its operational impact. Intended status: Informational Summary: This is a document focused on operational considerations for running a BGP route-server in an Internet Exchange context. As such its operationally focused by nature. I found it well written with no real concerns or issues. I do have some minor comments and questions. - Should there be a recommendation around path hiding? As the doc goes along its gets clearer around recommendations - 4.2.1.3, this I think is a little too loose but cleared up later (in 4.8). Before getting to 4.8 it seems this lacks a suitable recommendation (see next item) - Section 4.8, NH validation a ‘must’ instead of ’should’? With the RS approach this validation isn’t easily done by the clients and is important. So feels like this validation should either be available by the client (explicit enforcement) or generically validated (i.e. ‘must’). /nco