On 5 November 2016 at 03:54, Rawdon, Ryan <[email protected]> wrote:
> +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). > 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. 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. The only downside is if those networks don’t want to trust PeeringDB (or > any 3rd 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 > 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! 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. 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. 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. M
_______________________________________________ Pdb-tech mailing list [email protected] http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
