Alia Atlas has entered the following ballot position for draft-ietf-grow-irr-routing-policy-considerations-05: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-grow-irr-routing-policy-considerations/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Adrian's Discuss on the need to have Terry's review comments addressed. I also found this draft a bit hard to read and parse - though not to the extent of pulling out specific examples, but please do think about Barry's comments as well. Although the abstract and intro claim that the draft will provide a discussion of the existing or remaining concerns, I would STRONGLY (not quite DISCUSS but...) like them to be pulled out more clearly. Without this, the draft seems to be more retrospective and rambling than clearly articulating what was a problem, what changed, and what still remained as a problem. For instance, from reading the draft, I would say that: a) Getting fresh IRR data is still a problem. Pull mechanisms use long intervals based upon historic problems (see Sec. ...) and push mechanisms are not fully described. b) RPKI provides a solution only for verifying route origination but this is not sufficient for verifying IRR data because such data also includes asnum, etc. c) Stale data in IRRs: incentives don't exist for removing stale data and overriding the existing data requires work and has the risk of black-holing if the data wasn't really stale d) Propogation delay across different ISPs affect how rapidly changes can occur. e) Configuration based on the new IRR data is less operator-intensive because of the ability to use NetConf to deliver the updates, but a lack of vendor-agnostic models still makes such updates complicated. f) Router capabilities are rarely a problem anymore. (Incremental updates of prefix-lists, more static memory, BGP extensions to push new config in without traffic-impacting side-effects). I'm sure I've missed some and maybe gotten a few wrong- but I'd really like to see some actual takeaways. This currently leaves me feeling like I had a good dinner conversation chatting about how bad the old times were but without any action items or guidance for the future to improve. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
