<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:arial,sans-serif">On 5 November 2016 at 03:54, Rawdon, Ryan </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:rrawdon@conversantmedia.com" target="_blank">rrawdon@conversantmedia.com</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-6496122824962332800WordSection1">
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">+1 for turning this into something running on/inside of PDB, since it is already the hub of peering matchmaking today… just without the actual matchmaking (well,
Peering Coordinator Communication State Machine).</span></p></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">To be 100% clear on my intentions with this project: The "matchmaking" aspect is a cheap gimmick. The real purpose of Pinder is to provide a centralised method of contacting peers that doesn't rely on the crazy emails to and fro. Analysing who might peer with you should remain within the purview of the network itself, not PeeringDB.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Likewise, I've tried to encompass in the finite state machine the concept not only of "accept" and "reject", but also "let's talk". This signifies that the request has been seen by someone and they want to discuss things before making a decision. That could be an email chain, that could be a phone call, it could be a meeting at GPF/EPF/NANOG/RIPE/whatever, or it could simply be out of band validation that things such as MD5 passwords, commercial terms, requests to amend the PeeringDB record to show a valid IRR record... The list is endless. I imagine 90%+ of the peering requests through the system wouldn't enter this state, but I feel it's a valuable one to have.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-6496122824962332800WordSection1"><p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">The only downside is if those networks don’t want to trust PeeringDB (or any 3</span><sup style="color:rgb(31,73,125);font-family:Calibri,sans-serif">rd</sup><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> party) with a potential list of all of their peers, since this Pinder-esque
mechanism would benefit from maintaining state on who a given network already peers with. There are options that can probably help solve this, if it is a real concern – but could diminish the value for others. So this may not be an issue worth solving until
it is an actual problem/blocker for participants</span></p></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">Ok, so, I actually don't think the fact someone peers or not is a particularly secret thing -- you'll (hopefully) either be registering it in an IRR object, or given a looking glass in either network, visibility through traceroute that the path doesn't go via a third party transit provider!</div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">The potentially "secret" part of it in my view is the metadata around it -- if you integrate a messaging framework you could leak sensitive information (imagine if someone uses it to send confidential commercial terms or similar). Hence why the model is deliberately simple in the prototype. It says "accept", "reject", "contact", "I've configured", "you've configured", and "finished". The finished state would ideally then delete all previous evidence of previous states. Whether or not the record persists at all after the "finished" state (be it for a set number of days or forever) if up to the implementation.</div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">Of course, this is all up for discussion -- and the feedback I've received so far is that this idea is due to be discussed at the next PeeringDB board meeting.</div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">Certainly I'm excited to see where it can go. If it encourages more people to keep up to date PeeringDB records, including IRR filters, max prefixes, and points of presence, this can be a wonderful thing for the peering community.</div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">M</div><br></div></div></div></div>