Hi Matthew, <no hats>
I recommend you remove the 'cheap gimmick' parts and make it look more like a boring business tool with appropiate domain name and documentation style. That will help bring the actual novel and intriguing parts of the engine into focal point. I know some people are working on YANG modeling for peering interactions on the layer-8 level, I can see a the pinder approach as viable too. I do not know where these things belong yet and what PeeringDB's role in it will be. For now I view this as a social experiment, fair? :-) Kind regards, Job On Sat, Nov 05, 2016 at 10:32:09AM +0000, Matthew Walster wrote: > 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 _______________________________________________ Pdb-tech mailing list [email protected] http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
