<HTML><HEAD>
<STYLE id=eMClientCss>blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
.plain pre, .plain tt { font-family: monospace; font-size: 100%; font-weight: normal; font-style: normal; white-space: pre-wrap; }
a img { border: 0px; }body {font-family: Tahoma;font-size: 12pt;}
.plain pre, .plain tt {font-family: Tahoma;font-size: 12pt;}
</STYLE>
<STYLE>#x7ef7692f1a26454f8791d223fbb27639 BLOCKQUOTE.cite
{PADDING-LEFT: 10px; MARGIN-LEFT: 5px; BORDER-LEFT: #cccccc 1px solid; PADDING-RIGHT: 0px; MARGIN-RIGHT: 0px}
#x7ef7692f1a26454f8791d223fbb27639 BLOCKQUOTE.cite2
{PADDING-TOP: 0px; PADDING-LEFT: 10px; MARGIN-LEFT: 5px; BORDER-LEFT: #cccccc 1px solid; MARGIN-TOP: 3px; PADDING-RIGHT: 0px; MARGIN-RIGHT: 0px}
#x7ef7692f1a26454f8791d223fbb27639 .plain PRE, #x7ef7692f1a26454f8791d223fbb27639 .plain TT
{FONT-SIZE: 100%; FONT-FAMILY: monospace; WHITE-SPACE: pre-wrap; FONT-WEIGHT: normal; FONT-STYLE: normal}
#x7ef7692f1a26454f8791d223fbb27639 A IMG
{BORDER-TOP: 0px; BORDER-RIGHT: 0px; BORDER-BOTTOM: 0px; BORDER-LEFT: 0px}
#x7ef7692f1a26454f8791d223fbb27639 .plain PRE, #x7ef7692f1a26454f8791d223fbb27639 .plain TT, #x7ef7692f1a26454f8791d223fbb27639
{FONT-SIZE: 12pt; FONT-FAMILY: Tahoma}
</STYLE>
</HEAD>
<BODY scroll=auto class>
<DIV>Thanks for comments. My interest was to continue the discussion that Job hosted at RIPE70, and to get to some guidelines for those that need to exploit temporary redirection with BGP; whether customers or providers of services.</DIV>
<DIV> </DIV>
<DIV>Job, thanks for your observation that "the RIPE database supports this, you can create multiple route-objects covering the same prefix but with different "origin:" values.". Randy states agreement.</DIV>
<DIV>However, this does conflict with some other Internet documents, like BCP-6. That can only be confusing and may inhibit global consensus. If IETF BCP documents are inaccurate then the RIPE community has some responsibility to point it out.</DIV>
<DIV> </DIV>
<DIV>The dual authorisation that RIPE requires on a ROUTE object seems an unnecessary hurdle, and gives rise to the cross-border concern that Job raised in the BoF.</DIV>
<DIV>
<DIV> </DIV></DIV>
<DIV>The consensus from RPKI seems to be that the inetnum maintainer has the authority to grant ROA. </DIV>
<DIV>I do not know the history of why RIPE asks for AS maintainer also. Is there still some good reason? (If so, I am puzzled that it does not apply to RPKI, but that is a separate discussion).</DIV>
<DIV>Removing the AS maintainer from the route object Creation authorisation seems to solve the cross-region problem.</DIV>
<DIV>Are there reasons not to do this?</DIV>
<DIV>Job mentioned that RaDB seems to have neither authorisation requirement, so creating a global view of the IRR is challenging without policy agreement leading to trust on these things. </DIV>
<DIV> </DIV>
<DIV>Summary:</DIV>
<DIV>1/ ask IETF to update BCP-6. Is this something RIPE NCC should do?</DIV>
<DIV>2/ discuss why AS maintainer authorisation is required for RIPE ROUTE object Creation.</DIV>
<DIV> </DIV>
<DIV>
<DIV>I subsequently read the article by <A href="https://labs.ripe.net/Members/den_is/security-and-trust-in-the-internet-routing-registries-operated-by-the-rirs#long-term-solution-of-cross-registry-authorisation-across-some-rir-databases">Den Is </A> May 2015, which comments that there is no written policy for IRR.</DIV></DIV>
<DIV> </DIV>
<DIV>Steve</DIV>
<DIV> </DIV></BODY></HTML>