<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">All,<div></div><div><br></div><div>I would strongly like to recommend a two step process that should get buy-in from the community at large. This proposal is void of the technical specifics; however, many people are both familiar with these techniques and/or are the authors of those unmentioned techniques.</div><div><br></div><div>1) PeeringDB starts gathering IP allocations from IX organizations and populating en-mass an <b>"IX to IP to ASN/customer/member" </b>database. This is kept as nothing more than "hints" (even if I'd state they are "authoritative hints" as IX own the control of that data). In most cases this is very public data. In some cases it isn't. PeeringDB should on day-one only accept public data.</div><div><br></div><div>2) Records being added to an IX by an ASN/customer/member should be prompted from the hints; but without a requirement to use that data. Well that day one mindset. This is a basis to further refine later.</div><div><br></div><div>What does this achieve?</div><div><br></div><div>It allows users that automate their peering operations to reference the hints data if the PeeringDB IP data is empty or maybe different than hints (recall that IXs are authoritative in this arena). </div><div><br></div><div>It allows sanity checking when adding IP data; but with soft controls that don't force the user to accept the data. </div><div><br></div><div>It reinforces, that for the most part, this is already public data.</div><div><br></div><div>It still allows networks to be silently connected to IXs as it places the burden on non-publication back on the IX. This is already done today. </div><div><br></div><div>I propose this as a first step. I propose this as a way of moving forward and improving PeeringDB and helping operational use of the data.</div><div><br></div><div>Martin</div><div><br></div></body></html>