Dear John, ARIN, NANOG, On Mon, Aug 07, 2023 at 06:24:09PM +0000, John Curran wrote:
We have made some fairly significant changes for those customers using ARIN Online for routing security administration – see attached message for specifics.
Yes, significant changes! I very much appreciate ARIN's efforts to streamline IRR & RPKI operations for INR holders. :-) I too think that having to enter "sorta similar" data in 2 places of course is more prone to error (in terms of internal discrepancies between the two inputs of data) compared to entering routing data in just one place. I imagine the scheduled simplification of the user interface (intertwining IRR & RPKI) will lead to improved data accuracy and fewer operator errors. Thank you ARIN for that! I think the industry's transition from plain-text IRR data towards cryptographically verifiable RPKI data really starts happening when there are automated processes coupling the two sets of data, and indeed also retroactively glueing the two together (within ARIN's auspices the 'ARIN Online' environment). A few questions arose in my mind while wondering about implementation aspects on ARIN's side: - is the IRR state directly derived from the RPKI state? An example for context: should some kind of unfortunate failure happen in ARIN's HSMs and thusly a new Manifest + CRL pair isn't signed and published before the 'nextUpdate' timestamp of the previous pair, would the associated IRR objects be deleted via NRTM? Or is the creation of ROAs and IRR route:/route6: objects discoupled in the sense that an operator creates an abstract object which then is transformed into both IRR and RPKI objects? - What is the expected delay (if any) between creating a RPKI ROA and the associated IRR route/route6 objects appearing via NRTM? Is there online documentation outlining expectations, and is there internal monitoring on the delivery of the RPKI-to-IRR transformation service? - The documentation states "If the creation of a ROA would result in more than 256 IRR Route Objects, no managed IRR Route Objects will be created." - but, why not? Would it not be advantageous to create at a minimum the 256 of the 'least-specific' objects? I wonder if the current approach violates the principle of least astonishment in the sense that an operator picking an unfortunate 'maxLength' value results in no IRR objects at all. Kind regards, Job