Hi Martin, I think we agree so let me try again :-) PDB should be definitive so the field IMO should not be empty, The information should be valid and as correct as possible and indeed people should be able to automate against it. That being said, I doubt we want people to just blindly have a script configure a session just because someone, somewhere has added an IP address on an exchange, there should be another step, right? I have the feeling that people are trying to work around this by keeping the field empty, rather than having some kind of workflow automation allowing people to signal in an automated way that it is okay to peer on a particular IP address. For instance people that have a passive BGP session open to the entire IX subnet could just have an automated workflow auto-responder saying OK. Today this automation is of course not there and not on the roadmap, but a necessary first step is that the information is correct. I believe the resolution to what we do is a vote on PDB product-com, since the tea-leaves are indeed whatever someone chooses to read into it ;-) I am fine either way, but when there is no consensus there should be a resolution process. > On 28 Dec 2016, at 19:01, Martin J. Levy <[email protected]> wrote: > > Eric, > >> So let’s close the discussion? :-) Empty field not allowed? > > I'm not in favor of an empty field; but I can read the tea leaves so (for > arguments sake) let's just allow it! > > I'm pretty sure that will cause issues down the road; but maybe there's a > mitigation process we can devise. > >> Furthermore, people that just blindly configure based on an address popping >> up in peeringdb should at least have consulted with their peer, I hope. What >> we then need is not a reference database which is what PDB is today, but a >> workflow component which would allow both peers to acknowledge that both are >> happy to peer on certain IXP’s between certain IP pairs. > > Which is where I gave to solidly disagree with you! Let me explain. > > Either PeeringDB is definitive or it's not. If we state "it's not" then you > will see a mass-defection from both its use along with its support. > > I can't accept the "it's not" option. It's the job of all associated with > PeeringDB to build the most comprehensive database that can (and should) be > relied upon fully. Period. > > Martin > > PS: I'll kick off a new thread about my "mitigation process". >
_______________________________________________ Pdb-tech mailing list [email protected] http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
