<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 20 January 2015 at 15:47, Job Snijders <span dir="ltr"><<a href="mailto:job@instituut.net" target="_blank">job@instituut.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jan 20, 2015 at 03:35:40PM -0200, George Michaelson wrote:<br>
> Yes, thats exactly the kind of thing I am talking about, and I welcome<br>
> your initiative, and I think its good its exposed here so routing-wg<br>
> people can reflect on it. Clearly, its not only a DB-WG question!<br>
<br>
</span>Sorry, that was not clear to me. :-)<br></blockquote><div><br></div><div>I have a strong personal sense that the DB-WG group has interest, but so do the people who are seeking to steer routing and understand where permission to route vests from, and thats as much a routing-wg group issue as a DB-WG issue. Its just my opinion mind you.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> The other part of the story is a concern I have heard stated in DB-WG<br>
> that 'referential integrity' is very hard to maintain in a database<br>
> when it refers to external objects, which may cease to exist<br>
> asynchronously because the constraint cannot be maintained between<br>
> disparate independent sources.<br>
> I think that problem is a general problem, and cannot be fixed. I<br>
> worry, that this may be a 'blocker' for some people.<br>
<br>
</span>I don't know what you mean with the above paragraph. Can you maybe<br>
provide an example to illustrate the issue?<br></blockquote><div><br></div><div>Sure. Say I make an object which implicitly refers to an ASN held in another place. So some line eg in a route: object magically referred to a hypothetical external reference APNIC::AS1 in the place where it would refer to an aut-num or as-set named object.</div><div><br></div><div>In the RIPE DB, referential integrity is maintained so if you try to delete AS1, and its referred to in a key dependent way by any object, you can't delete it: there is a reference. Referential integrity is maintained by the Database constraints. This is what Wilfred went to some lengths to explain to me. So you can't delete a maintainer while objects remain which are maintained by the maintainer. You can't make a new person object and a new maintainer at the same time simultaneously 'without magic in the back' because the referential constraints are not met during the creation cycle, so the RIPE DB has special logic to cope. and so on.</div><div><br></div><div>Now, consider APNIC::AS1. Its external. It has no back-reference to objects in source=RIPE which refer to it. How can it? there is no clear definition for an external reference for source=APNIC held at APNIC to know, its been included in an object in the RIPE DB (I can imagine heuristics to know, but not a low level method which is a constraint)</div><div><br></div><div>So, I can delete it, any time I like, if nothing inside source=APNIC refers to it: there is no referential integrity break. But I then make the object at source=RIPE illegal, because the (hypothetical) external reference can't be met.</div><div><br></div><div>This is what I believe worries the DB architects behind single-source whois models, and why they elected to permit the creation of AS1 inside the DB, rather than have to refer to it as an external reference: You cannot enforce the constraints and you can wind up having loss of information because things get deleted.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> But, I think the "win" in permitting APNIC::named-object references<br>
> inside RIPE and vice-versa is very big.<br>
<br>
</span>Currently I prefer to just flatten the namespace for relevant<br>
cross-registry objects, like aut-num, inetnum, route, route6, inet6num,<br>
mntner. This will provide us with tons of benefits without need to<br>
upgrade any tools.<br></blockquote><div><br></div><div>How do you manage this? What enforces it?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Example: IANA handed down the block which contains AS15562 to RIPE, RIPE<br>
assigned it to me. It should not exist in the APNIC database (or any<br>
other IRR), not even as APNIC::AS15562. Same goes for IP space.<br></blockquote><div><br></div><div>Well I believe that to, but thats not what we currently have.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However I don't feel religious about this direction and look forward to<br>
discussion.<br>
<br>
Maybe we should organise a "cross-registry authentication" BOF at the<br>
next RIPE meeting where RIPE, APNIC & AFRINIC staff + stakeholders from<br>
db-wg & routing-wg?<br></blockquote><div><br></div><div>I think thats a very good suggestion which I would love the routing-WG and the BoF organizing people to consider on its merits. I think it would end a certain amount of 'problem bouncing' between the various WG and would permit people from the JP IRR community who often come to RIPE meetings to perhaps have a voice. </div><div><br></div><div>cheers</div><div><br></div><div>-George</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Kind regards,<br>
<br>
Job<br>
<br>
</blockquote></div><br></div></div>