Peeringdb: Add "Tunnels" as a media type option for IXP's

[as44980]

While the summary of #515 seems to be a lack of consensus to "Remove Virtual IXPs", and #611 to "Require IXs to have at least one facility" is still open..

However there appear to be IX records in PeeringDB which claim to support the Media Type "Ethernet", yet the only means of connecting highlighted on their website are either via tunnels over the Internet or by purchasing a VPS.

The most obvious example of this is EVIX, which their website highlights they are a "Virtual Internet Exchange" which "simulates a real Internet Exchange Point using tunnels and virtulized switches".

So although it is suggested in #611 that "the physical location where the IX is does not have to be a facility according to PDB's criteria", should a clearly advertised ability to connect via the medium of Ethernet be required in order for an IX to indicate a "Media Type: Ethernet" on the IX's PeeringDB record?

And if so, should we add the option of "Tunnels" to the list of Media Types which an IX can indicate they support? :)

[as44980]

FYI there was some support for this in #515..

https://github.com/peeringdb/peeringdb/issues/515#issuecomment-567316386

That said maybe a compromise would be to identify Virtual IXPs as "Virtual" in PeeringDB.

https://github.com/peeringdb/peeringdb/issues/515#issuecomment-567323131

I think add "tunnel" or indeed the supported tunnelling types as a media type is sensible. Eg "Ethernet over IP" etc.
I note many, not all, of the tunneled/virtual IXPs are listing MTU below 1500, so that's one way to filter them for those that want to hide them.

https://github.com/peeringdb/peeringdb/issues/515#issuecomment-567357187

I agree with @andydavidson and @narxnet. I think tunnel over the Internet should not be categorized as an IXP. We should have a way to recognize the difference between IXP and "Virtual IXP".

But perhaps there is a better solution in the works towards what appears to be a common sentiment expressed in the third comment?

[as44980]

In addition to EVIX, there are a number of other IX records where this may be relevant:

IX42 LAS "_Currently we only accept peers via tunnels due to insufficient fund for switch colocation_"

ZXIX Shanghai links to a website which web based translation advises "_The currently supported access methods are GRE, VXLAN, OpenVPN, ZeroTier, etc._" with no mention of physical connection via Ethernet

OpenSwitch-IX links to a website which advises their platform "_simulates a real Internet Exchange Point using tunnels and virtulized switches_" and thatthey "_offer the following tunnels to peer: 1. VxLAN 2. GREtap 3. EoIP_", but no means to physically connect via Ethernet.

So although the first of these at least lists the media type as "Multiple", I am proposing the additional media type option of "Tunnels" to provide a means to correct the currently inaccurate suggestion that its possible to connect to these IX's via Ethernet :)

[job]

What problem are you actually solving? We have gone over this endlessly and going down this path will have significant consequences because of the wide spread use of remote peering (and there actually not being anything wrong with partially virtual IXPs).

You don't like an IX? Don't peer there! That's it. Just move on

[joelfreak]

What problem are you actually solving? We have gone over this endlessly and going down this path will have significant consequences because of the wide spread use of remote peering (and there actually not being anything wrong with partially virtual IXPs).

You don't like an IX? Don't peer there! That's it. Just move on

Does an IX actually 'exist' somewhere if it just accepts connections via tunnels? This pollutes the database, making it appear that there are physical exchanges in places where there actually aren't any. If we are trying to make the internet a better place, and better connected, we need to at MINIMUM allow for these 'virtual' or 'tunnel-only' exchanges to be removed from general searches for IX's. There is NOTHING WRONG with an IX being virtual, but there is something wrong with an IX coming up in searches for a city/state/country/etc and NOT seeing a flag that its virtual. I can flip the argument on its head...what's wrong with just specifying that an exchange is tunnel only? Obviously even the OWNERS of the exchanges wanted people to know this by putting it in their listings...

[job]

Don't connect to IXPs you don't want to connect to. It is not pollution of the database.

Really crazy how upset some people get about a few tunnels allegedly existing.

More than half of any large IXP is tunnels, what is the issue?

Latency to the remote next hop unacceptable? Don't set up peering.

Too much packetloss? Don't set up peering.

These are local operator decisions that should not bleed over into peeringdb database policy.

[job]

At what point in your workflow are you really getting in trouble because of an allegedly virtual ixp popping up in your search results after you searched for it? Why not ignore results you don't like?

[arnoldnipper]

Don't connect to IXPs you don't want to connect to. It is not pollution of the database.

+1 iow: PDB is not a place where we say: don't put your cat in a microwave

[joelfreak]

Don't connect to IXPs you don't want to connect to. It is not pollution of the database.

+1 iow: PDB is not a place where we say: don't put your cat in a microwave

But its a place where we tell people where that microwave is, and what wattage it is. So lets just label them.

[joelfreak]

At what point in your workflow are you really getting in trouble because of an allegedly virtual ixp popping up in your search results after you searched for it? Why not ignore results you don't like?

When researching places to build to, and existing IXPs in those cities, many networks use PDB. What used to be an uncommon occurrence is now getting much more common, where an exchange is listed in X, and further research shows that its not REALLY in X, its 'virtually' in X. Does it 'break' the internet? No. But it makes the platform less useful for what it does, which is categorize networks, facilities and exchanges. I am failing to understand why people are so violently opposed to this. There are MANY people who feel that its important to label exchanges that aren't avalible for physical connection, so what is the argument that SHOULDN'T have a flag?

[job]

Don't connect to IXPs you don't want to connect to. It is not pollution of the database.

+1 iow: PDB is not a place where we say: don't put your cat in a microwave

But its a place where we tell people where that microwave is, and what wattage it is. So lets just label them.

You (or me) will never be able to come up with a label mechanism that works satisfactorily for all stakeholders.

[joelfreak]

Don't connect to IXPs you don't want to connect to. It is not pollution of the database.

+1 iow: PDB is not a place where we say: don't put your cat in a microwave

But its a place where we tell people where that microwave is, and what wattage it is. So lets just label them.

You (or me) will never be able to come up with a label mechanism that works satisfactorily for all stakeholders.

How about a flag that just says "This exchange does not accept physical connections"?

[martzuk]

Don't connect to IXPs you don't want to connect to. It is not pollution of the database.

+1 iow: PDB is not a place where we say: don't put your cat in a microwave

But its a place where we tell people where that microwave is, and what wattage it is. So lets just label them.

You (or me) will never be able to come up with a label mechanism that works satisfactorily for all stakeholders.

This feels like a very defeatist attitude. There have been many suggestions on ways to label these virtual IXPs, surely we can find one that satisfies the majority?

[job]

Don't connect to IXPs you don't want to connect to. It is not pollution of the database.

+1 iow: PDB is not a place where we say: don't put your cat in a microwave

But its a place where we tell people where that microwave is, and what wattage it is. So lets just label them.

You (or me) will never be able to come up with a label mechanism that works satisfactorily for all stakeholders.

How about a flag that just says "This exchange does not accept physical connections"?

What happens if nobody presses the button? Or if an IXP is a mix?

[job]

When you talk about many people it seems to be the same group of 5 people complaining on twitter about this non-issue.

[joelfreak]

Don't connect to IXPs you don't want to connect to. It is not pollution of the database.

+1 iow: PDB is not a place where we say: don't put your cat in a microwave

But its a place where we tell people where that microwave is, and what wattage it is. So lets just label them.

You (or me) will never be able to come up with a label mechanism that works satisfactorily for all stakeholders.

How about a flag that just says "This exchange does not accept physical connections"?

What happens if nobody presses the button? Or if an IXP is a mix?

If its a mix, it accepts physical connections, and actually exists in the datacenter/city its listed in. Great, no argument. People NOW are putting this information in the information fields of PDB, thus I would think that people WANT to get that information out there.

[job]

This feels like a very defeatist attitude. There have been many suggestions on ways to label these virtual IXPs, surely we can find one that satisfies the majority?

What will you do with such labeled data, especially when such labels are user submitted? Your provisioning software will need to do measurements and checks anyway before setting anything up.

Can anyone explain why the mere existence of some table entries that have meaning to some people (but not to others) is such a big deal that it needs to be brought up every year?

[grizz]

Media types will be gone shortly, and I don't believe that's the best place to put this information.

I like #611's solution, obviously, as I made it. Could easily create a "Tunnel" facility as well and use that.

I don't think having these entries are polluting the database, but requiring facilities helps the "problem" and more importantly makes the database more accurate.

[joelfreak]

Will it allow exchanges that want to list themselves to eliminate themselves from any searches? Yes. And that clearly helps not only me, but others who do what we do. Surely most of what PDB does can be done via other methods, but the reason we like the platform so much is because of what it does all in one place.
Can someone please explain why something which is felt strongly enough by many members of the community every year isn't worthy of a simple field, but something like a youtube channel is?! I have no argument with either being listed, but surely something network related is relevant.

[job]

Because its not "many members", and you can easily ignore results you are not interested in?

How about a per-user customizable "ignore list", so that when you see an ixp or a facility you don't like, peeringdb will memorize that choice and not display results related to that entity anymore for the user?

[arnoldnipper]

I like #611's solution, obviously, as I made it. Could easily create a "Tunnel" facility as well and use that.

Which looks bbd from day zero ;-)

[joelfreak]

You are willing to make an ignore function, but NOT something that users (even if we are talking about 10 or so, but I have a feeling if people knew, many more would ask) are asking for, AND that IX's themselves are adding to their listings to inform those who search?
There is nothing that adding this function will do that HARMS PDB, it can only HELP it. Those of us fighting for it just can't understand why there is such a fight against it.

[as44980]

What problem are you actually solving? We have gone over this endlessly and going down this path will have significant consequences because of the wide spread use of remote peering (and there actually not being anything wrong with partially virtual IXPs).
You don't like an IX? Don't peer there! That's it. Just move on

Does an IX actually 'exist' somewhere if it just accepts connections via tunnels? This pollutes the database, making it appear that there are physical exchanges in places where there actually aren't any. If we are trying to make the internet a better place, and better connected, we need to at MINIMUM allow for these 'virtual' or 'tunnel-only' exchanges to be removed from general searches for IX's. There is NOTHING WRONG with an IX being virtual, but there is something wrong with an IX coming up in searches for a city/state/country/etc and NOT seeing a flag that its virtual. I can flip the argument on its head...what's wrong with just specifying that an exchange is tunnel only? Obviously even the OWNERS of the exchanges wanted people to know this by putting it in their listings...

+1 and it would be nice to see if there was any solutions to this problem, or even valid arguments against, other than what appears like a we-dont-want-to-do-this-and-we-have-made-our-minds-up apprach that I personally don't thing reflects the views of the community or what is expected of PeeringDB by the community... but I could well be wrong :)

[job]

What is the problem?

[joelfreak]

What is the problem?

Surely this is a trolling question? Many of us have explained the problem in the many posts we have had back and forth on this.

[as44980]

More than half of any large IXP is tunnels, what is the issue?

I suspect that in the context of this discussion, a reasonable proportion of the PeeringDB user base would understand "tunnels" to mean "tunnels (over the Internet)"..

But if it helps remove the somewhat pointless debates about MPLS being tunnels, or that the majority of an Internet packets life will be spent encapsulated in some way, then I would be happy to revise the request for the new media type to be added as "Tunnels (over the Internet)" ;)

[job]

What is the problem?

Surely this is a trolling question? Many of us have explained the problem in the many posts we have had back and forth on this.

You talk about "the problem" and "a simple field", while I can't wrap my head around why you and Marty only show up when its about virtual ixps and how they should be banned/deleted/hidden/flagged (again, all user submitted data) - while you could just as easily ignore what you don't like? Perhaps even use the API and discard information you are not interested in for local policy reasons?

[martzuk]

+1 a simple way to list the IXP as offering tunnels will suffice, perhaps this could even be expanded to be part of a "tags" feature where an IXP, member, data centre et al. can list tags related to them?

[as44980]

What problem are you actually solving?

Please see the original comment:

I am proposing the additional media type option of "Tunnels" to provide a means to correct the currently inaccurate suggestion that its possible to connect to these IX's via Ethernet

[job]

+1 a simple way to list the IXP as offering tunnels will suffice, perhaps this could even be expanded to be part of a "tags" feature where an IXP, member, data centre et al. can list tags related to them?

This will include all ixps that have any remote peering, which is roughly 95% of ixps.

It seems to me that a specific personal dislike for some element of the peeringdb UI is causing you issues. Can you provide screenshots and annotations on what your workflow is and what the problem exactly is? Perhaps demonstrate what steps you have taken to try to workaround it?

[job]

What problem are you actually solving?

Please see the original comment:

I am proposing the additional media type option of "Tunnels" to provide a means to correct the currently inaccurate suggestion that its possible to connect to these IX's via Ethernet

Ethernet in a tunnel is still ethernet

[joelfreak]

How does this help someone?
https://www.peeringdb.com/ix/3232
This IXP, according to their OWN page, will soon open in the US as well. They have no physical presence "OpenSwitch IX is a virtual Internet Exchange Point" but yet are listed in India. This is a PERFECT example for the field we are speaking of. This exchange isn't physical, and is hobbyist (which is fine, but its NOT for internet infrastructure).
Surely you understand how 100's of exchanges like this will cause using PDB to become difficult.

[martzuk]

+1 a simple way to list the IXP as offering tunnels will suffice, perhaps this could even be expanded to be part of a "tags" feature where an IXP, member, data centre et al. can list tags related to them?

This will include all ixps that have any remote peering, which is roughly 95% ixps.

It seems to me that a specific personal dislike for some element of the peeringdb UI is causing you issues. Can you provide screenshots and annotations on what your workflow is and what the problem exactly is? Perhaps demonstrate what steps you have taken to try to workaround it?

Without debating semantics endlessly there seems to be an ideological objection to enhancing the data quality by adding what boils down to a tag/field/media type/however you would implement it.

Let's not debate the difference between a GRE/OpenVPN/whatever tunnel and remote IX port, there's clearly a practical, real world difference.

Ethernet in a tunnel is still ethernet

Perhaps, but in the same way that a car on a cargo ship drives across an ocean.

[job]

How does this help someone?
https://www.peeringdb.com/ix/3232
This IXP, according to their OWN page, will soon open in the US as well. They have no physical presence "OpenSwitch IX is a virtual Internet Exchange Point" but yet are listed in India. This is a PERFECT example for the field we are speaking of. This exchange isn't physical, and is hobbyist (which is fine, but its NOT for internet infrastructure).
Surely you understand how 100's of exchanges like this will cause using PDB to become difficult.

Maybe it helps the participants who submitted this information to peeringdb? Who knows - if you don't like it stop clicking the link?

[joelfreak]

How does this help someone?
https://www.peeringdb.com/ix/3232
This IXP, according to their OWN page, will soon open in the US as well. They have no physical presence "OpenSwitch IX is a virtual Internet Exchange Point" but yet are listed in India. This is a PERFECT example for the field we are speaking of. This exchange isn't physical, and is hobbyist (which is fine, but its NOT for internet infrastructure).
Surely you understand how 100's of exchanges like this will cause using PDB to become difficult.

Maybe it helps the participants who submitted this information to peeringdb? Who knows - if you don't like it stop clicking the link?

I clicked the link because I needed to research the exchange.
I clicked the link because its the only way I was able to find out its a virtual exchange.
I wouldn't have clicked the link if there was a field to tell me such.

[job]

+1 a simple way to list the IXP as offering tunnels will suffice, perhaps this could even be expanded to be part of a "tags" feature where an IXP, member, data centre et al. can list tags related to them?

This will include all ixps that have any remote peering, which is roughly 95% ixps.
It seems to me that a specific personal dislike for some element of the peeringdb UI is causing you issues. Can you provide screenshots and annotations on what your workflow is and what the problem exactly is? Perhaps demonstrate what steps you have taken to try to workaround it?

Without debating semantics endlessly there seems to be an ideological objection to enhancing the data quality by adding what boils down to a tag/field/media type/however you would implement it.

Let's not debate the difference between a GRE/OpenVPN/whatever tunnel and remote IX port, there's clearly a practical, real world difference.

As is evident from this discussion, there is resistance to adding a new field/flag/tag without being extremely precise about the semantic meaning of that field.

[joelfreak]

As is evident from this discussion, there is resistance to adding a new field/flag/tag without being extremely precise about the semantic meaning of that field.

The only resistance to this seems to be from PDB staff.

[job]

How does this help someone?
https://www.peeringdb.com/ix/3232
This IXP, according to their OWN page, will soon open in the US as well. They have no physical presence "OpenSwitch IX is a virtual Internet Exchange Point" but yet are listed in India. This is a PERFECT example for the field we are speaking of. This exchange isn't physical, and is hobbyist (which is fine, but its NOT for internet infrastructure).
Surely you understand how 100's of exchanges like this will cause using PDB to become difficult.

Maybe it helps the participants who submitted this information to peeringdb? Who knows - if you don't like it stop clicking the link?

I clicked the link because I needed to research the exchange.
I clicked the link because its the only way I was able to find out its a virtual exchange.
I wouldn't have clicked the link if there was a field to tell me such.

You researched the ixp, made a decision, and now can move on, right?

Btw another way of finding out about the ixp is to use the peeringdb api

[joelfreak]

You researched the ixp, made a decision, and now can move on, right?

Btw another way of finding out about the ixp is to use the peeringdb api

Others in my org can't filter out this link as well, they have to do the same research as I did. One simple check mark allows for a TON of less work for many organizations and people, but for some reason that doesn't seem to be appreciated.

[martzuk]

+1 a simple way to list the IXP as offering tunnels will suffice, perhaps this could even be expanded to be part of a "tags" feature where an IXP, member, data centre et al. can list tags related to them?

This will include all ixps that have any remote peering, which is roughly 95% ixps.
It seems to me that a specific personal dislike for some element of the peeringdb UI is causing you issues. Can you provide screenshots and annotations on what your workflow is and what the problem exactly is? Perhaps demonstrate what steps you have taken to try to workaround it?

Without debating semantics endlessly there seems to be an ideological objection to enhancing the data quality by adding what boils down to a tag/field/media type/however you would implement it.
Let's not debate the difference between a GRE/OpenVPN/whatever tunnel and remote IX port, there's clearly a practical, real world difference.

As is evident from this discussion, there is resistance to adding a new field/flag/tag without being extremely precise about the semantic meaning of that field.

I disagree, I think the majority of people can agree on what "Tunnel" would mean in this context, I think I've only see you argue that a significant percentage of IX members are connected with tunnels.

[as44980]

Ethernet in a tunnel is still ethernet

IMHO this is not true in the context of connecting to an IX, if your not able to exchange Ethernet frames with other participants without your "tunnel (over the internet)" then you are connected via that tunnel, over the internet..

Similarly I don't think an IX service which a reseller delivers to a network who is not directly connected to the IX would be what is typically envisaged by the use of "tunnel (over the internet)", at least not if the service which the IX itself provides is delivered as a physical Ethernet hand-off to the reseller..

I do not see the value in conflating means which third parties can provide access to an IX, such as using their MPLS network, with how the IX itself makes access to its fabric..

Which from what I can see of the IX records in PeeringDB includes many who only provide access to their fabric via physical "Ethernet" connections, a small number with a "Mix" of Ethernet and "Tunnels (over the Internet)" plus an even smaller number which are verifiably only accessible using "Tunnels (over the Internet)".

Hence with the proposal to add an additional media type, and perhaps clarify that "Mixed" can mean any combination of the individually listed media types, it would appear to solve the problem described above.

[job]

You researched the ixp, made a decision, and now can move on, right?
Btw another way of finding out about the ixp is to use the peeringdb api

Others in my org can't filter out this link as well, they have to do the same research as I did. One simple check mark allows for a TON of less work for many organizations and people, but for some reason that doesn't seem to be appreciated.

Can you tell your coworkers "do not click this link"?

Again, seems you are superimposing a narrow local workflow issue on all of peeringdb. Strongly recommend you check out the API to optimize the workflow for your environment

[joelfreak]

Can you tell your coworkers "do not click this link"?

You are suggesting that I keep a list of 'exchanges not to click on' internally? Instead of just having this as a PDB feature?

Again, seems you are superimposing a narrow local workflow issue on all of peeringdb. Strongly recommend you check out the API to optimize the workflow for your environment

It's not just me, its 10 or so networks who are speaking up about this to you now. Again, as of right now I have not heard ANY argument AGAINST what we are asking for, only we are being told we are 'using it wrong'.

[job]

Can you tell your coworkers "do not click this link"?

You are suggesting that I keep a list of 'exchanges not to click on' internally? Instead of just having this as a PDB feature?

Yes, the list of things in peeringdb you don't like is specific to you, and not to all of peeringdb. Any number of local policy decisions could lead to ignore listing an ixp, city, org, whatnot.

[joelfreak]

Can you tell your coworkers "do not click this link"?

You are suggesting that I keep a list of 'exchanges not to click on' internally? Instead of just having this as a PDB feature?

Yes, the list of things in peeringdb you don't like is specific to you, and not to all of peeringdb. Any number of local policy decisions could lead to ignore listing an ixp, city, org, whatnot.

Are you suggesting that people 'like' virtual IX's being listed along with regular IX's? Not that it doesn't bother people because of their work flow, but that somehow this is FAVORABLE to someone?

[job]

It's not just me, its 10 or so networks who are speaking up about this to you now. Again, as of right now I have not heard ANY argument AGAINST what we are asking for, only we are being told we are 'using it wrong'.

Ten networks? Give me a break.

How come this is the only topic I ever hear you guys about? Where is the homework you did yourself? The screenshots, annotations and user story to make a compelling case for a clearly articulated issue and unambiguous definitions?

Waving your hands around "everyone knows what a tunnel is" or "clearly this is virtual" doesn't bring me any closer to the light.

[as44980]

One more to add to the list, seems somebody has submitted Sandwich-IX... :p

[joelfreak]

It's not just me, its 10 or so networks who are speaking up about this to you now. Again, as of right now I have not heard ANY argument AGAINST what we are asking for, only we are being told we are 'using it wrong'.

Ten networks? Give me a break.

How come this is the only topic I ever hear you guys about? Where is the homework you did yourself? The screenshots, annotations and user story to make a compelling case for a clearly articulated issue and unambiguous definitions?

Waving your hands around "everyone knows what a tunnel is" or "clearly this is virtual" doesn't bring me any closer to the light.

Obviously there is something you want here in order to get to the level where you think it's an issue, as there still hasn't been an argument why ADDING this is bad. I think many of us have made it clear why this is an issue that we care about. Nothing in the world is every black and white, so we NEVER are all going to agree on what is an exchange and whats not, etc, but PDB exists to try to clear things up for those of us who need such a system. The very mission statement of PDB states:

“PeeringDB, a nonprofit member-based
organization, facilitates the exchange of user maintained
interconnection related information, primarily for Peering Coordinators
and Internet Exchange, Facility, and Network Operators."

How is it not possible that adding a virtual IX flag doesn't fit this mission statement?!

[arnoldnipper]

One more to add to the list, seems somebody has submitted Sandwich-IX... :p

And it got approved?

[as44980]

One more to add to the list, seems somebody has submitted Sandwich-IX... :p

And it got approved?

Despite not being mentioned in the criteria, the lofy barrier to entry of creating a "website" shouldnt take too long... ;)

[as44980]

How come this is the only topic I ever hear you guys about?

Im not sure what sort of band of rebel outlaws you seem to have grouped me in with, who perhaps dare to upset the status quo!

But I can confirm this issue was raised purely based on my own frustrations at the inaccuracies described in my original comments, which I tried my best to "clearly articulate"..

And to be honest, given this has been discussed in various shapes and forms over the years I dont think there is a lack of understanding of what is being asked here..

Perhaps the only thing which is unclear is if the concerns highlighted here are shared beyond those who have the patience to attempt to raise them in (what appears to me to be) an increasingly hostile environment :(

[job]

Closing this thread as it has devolved into ridicule of peeringdb volunteers and submission of rogue information.

[andydavidson]

Closing this thread as it has devolved into ridicule of peeringdb volunteers and submission of rogue information.

If an IXP has been described of as rogue because it doesn't have a switch, doesn't have a specific geography, and only supports tunnel connectivity, then I think you have found an ideal name for these vpn providers that you have accidentally listed as IXPs. Please therefore remove these 'rogue IXPs' from the database.

[job]

If an IXP has been described of as rogue because it doesn't have a switch, doesn't have a specific geography, and only supports tunnel connectivity, then I think you have found an ideal name for these vpn providers that you have accidentally listed as IXPs. Please therefore remove these 'rogue IXPs' from the database.

The IXP submission did not meet PeeringDB's requirements, so indeed, it is not approved and not part of the data-set available to peeringdb users?

[as44980]

One more to add to the list, seems somebody has submitted Sandwich-IX... :p

And it got approved?

I am pleased to see this has spawned #784, further helping to improve PeeringDB.. ;)

[martzuk]

Closing this thread as it has devolved into ridicule of peeringdb volunteers and submission of rogue information.

This is not a personal attack on you, from all that has been said on the thread it's all related to the suggested enhancement, which IMO no way negatively impacts any member or IX on PeeringDB, it's a simple enhancement to ease searching.

What I find disappointing is a number of people, which you say 10, so for argument's sake we'll go with that, have shown support for a tiny feature enhancement, yet since you disagree with it the thread is closed and that's the end of it. IMO it shouldn't just be up to you to decide what gets implemented and what doesn't. There should be a more democratic way of voting for feature requests, perhaps something similar to the way the UK government must debate a petition if it gets enough support (https://petition.parliament.uk/). Can we please at least consider the suggest with the wider audience, without further descending into arguments?

[job]

0) the attack is where Joel expressed negative sentiment about the efforts of another peeringdb volunteer who is trying to produce code (in addition to their time investment in other peeringdb volunteer duties). It is a bit rich to talk people down who actually are doing the work. Then a second incident occurred where someone proclaiming to want to 'improve data quality' submittted information which arguably does not improve data quality and in fact squats on Internet Number Resources which do not belong to them.

1) Your github account only has focussed on banning/downgrading/deleting "Virtual" IXPs, (source: https://github.com/peeringdb/peeringdb/issues?q=is%3Aissue+martzuk) - this leads me to suspect you might not be considering peeringdb's whole stack and role in the ecosystem, as you appear to be a single-issue commenter. It is fine you want to focus on a single issue, but the moment you proceed to discard feedback from volunteers who have been working daily/weekly on this for years... it becomes a bit strange. There are more users, perspectives and workflows than you might think!

2) I never said it was 10 people, Joel said that. I actually think it is less: it seems to be Andy D, you, Joel, Paul, and perhaps 1 or 2 more (some of who are famous for anonymous twitter trolling). This group has not grown over the last 3 years which leads me to believe there is a local workflow issue rather than an issue with PDB itself.

3) using the phrases "no way negatively impact" or "improving data quality" doesn't actually make it so. For example me stating that the sky is green doesn't actually make the sky green.

4) The PeeringDB productcommittee is tasked with overseeeing PeeringDB's feature development, its process is described here https://docs.peeringdb.com/committee/product/ - this is by design not a "direct democracy", but it is a transparent bottom-up process (as is evident from these conversations being public). You can reach out to the PeeringDB Product Committee Chairs if you want.

If you are a PDB pro user, use the API and add things you dont want to consider to some kind of local ignore list. If you won't use the API, just apply a mental ignore filter. Don't peer at IXPs you don't want to peer at!

[martzuk]

0 - I didn't see this as a personal attack, but I accept your point

1 - I'm not an overly active Github user indeed, however I did spend 1 year helping out with PeeringDB on the admin committee, but was kicked off after a year as not being able to dedicate a large amount of time every day wasn't possible. Perhaps consider there are other issues that I have opinions on, but there hasn't been quite the level of pushback that me commenting on them was necessary or warranted. I'm also somewhat disheartened about #515 turning into a holy war that I try to refrain from commenting. Whether it would be believed or not, I'm not trying to argue here for the fun of arguing, but rather feel somewhat strongly about the suggestion.

2 - On #515 there were several more people than the ones in the list above, I don't think my participation in this has been trolly at all, but refrain from judgment on the others

1. Fair enough, please explain why the request will negatively impact PeeringDB

2. I don't see that doing anything to help, but maybe.

I guess this is a pretty lost cause now :(

[joelfreak]

There was no personal attack at all on anyone. I did not name anyone (In
fact I don't even know who made that change), I looked at a recent change
that was NOT criticized, and was accepted, vs the response we receive to
this every time we bring it up. The fact that you took it as a personal
attack is something that was not meant as one, and if you can discuss how
things are not 'needed' in PDB, its not fair that others can't bring up
that other things are not needed either.

This is CLEARLY something that is security related for the internet, and
for some reason you don't wish to apply it. I don't understand why you
think we have some ulterior motive to get this done, when we point out the
security implications of it.

I find the answers to this thread STUNNING, and worrisome, to say the least.

Reid

On Tue, Jul 28, 2020 at 8:11 AM Job Snijders [e-mail]
wrote:

>

1.

the attack is where Joel expressed negative sentiment about the
efforts of another peeringdb volunteer who is trying to produce code
(in addition to their time investment in other peeringdb volunteer duties).
It is a bit rich to talk people down who actually are doing the work. Then
a second incident occurred where someone proclaiming to want to 'improve
data quality' submittted information which arguably does not improve data
quality and in fact squats on Internet Number Resources which do not belong
to them.
2.

Your github account only has focussed on banning/downgrading/deleting
"Virtual" IXPs, (source:
https://github.com/peeringdb/peeringdb/issues?q=is%3Aissue+martzuk) -
this leads me to suspect you might not be considering peeringdb's whole
stack and role in the ecosystem, as you appear to be a single-issue
commenter. It is fine you want to focus on a single issue, but the moment
you proceed to discard feedback from volunteers who have been working
daily/weekly on this for years... it becomes a bit strange. There are more
users, perspectives and workflows than you might think!
3.

I never said it was 10 people, Joel said that. I actually think it is
less: it seems to be Andy D, you, Joel, Paul, and perhaps 1 or 2 more (some
of who are famous for anonymous twitter trolling). This group has not grown
over the last 3 years which leads me to believe there is a local workflow
issue rather than an issue with PDB itself.
4.

using the phrases "no way negatively impact" or "improving data
quality" doesn't actually make it so. For example me stating that the sky
is green doesn't actually make the sky green.
5.

The PeeringDB productcommittee is tasked with overseeeing PeeringDB's
feature development, its process is described here
https://docs.peeringdb.com/committee/product/ - this is by design not
a "direct democracy", but it is a transparent bottom-up process (as is
evident from these conversations being public). You can reach out to the
PeeringDB Product Committee Chairs if you want.

If you are a PDB pro user, use the API and add things you dont want to
consider to some kind of local ignore list. If you won't use the API, just
apply a mental ignore filter. Don't peer at IXPs you don't want to peer at!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/peeringdb/peeringdb/issues/782#issuecomment-665003060,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEVBGSJKTDOHKIUE3M77JGDR5257RANCNFSM4PJJRREQ
.

--
Reid Fishler
Director
Hurricane Electric
[phone]

[jranma]

Do IXPs, including virtual ones, allow route exchange between peers ? yes, the do.
Do IXPs, including virtual ones, use standard and recognized routing protocols ? Yes, the do
Are IXPs, including virtual ones, a basic infrastructure of the Internet? Yes, they are.

The decision to treat IXPs differently (or simply remove them) on the basis of the technology used is notbased on technical arguments, but on ideological choices.
Ideology and politics have no place in peerindb.

Everyone has the right to have their preferences. If you don't like an IXP, don't use it. Period. But you have no reason to forbid others to do so by denying them access to information.

This kind of half-worded paternalism about virtual IXPs is quite appalling.
Let's solve problems, let's not create them artificially.

[as44980]

The decision to treat IXPs differently (or simply remove them)..

I see you posted the exact same comment in another issue, and that you appear to be mistakenly conflating two very different requests..

Everyone has the right to have their preferences. If you don't like an IXP, don't use it. Period. But you have no reason to forbid others to do so by denying them access to information.

I am unsure how suggesting the addition of another Media Type is in anyway "denying" anyone with "access to information", but perhaps you can enlighten us?

Let's solve problems, let's not create them artificially.

Personally I raised this issue with the hope it would provide a solution to what (at the time) had been seemingly more contentious suggestions such as Remove Virtual IXPs, and is very specifically aimed at clarifying what I feel is misleading for an IXP to list support for "Media Type" of Ethernet while stating in the notes that physical connections are not possible.

This view is clearly not universal; however it does not appear logical to suggest that "Everyone has the right to have their preferences" yet disagree that information on the means with which it is possible to connect to an IXP may be relevant enough that some proportion of the PeeringDB user-base would find it usefully to determine this programmatically..

ie without requiring a human to parse the notes section to see if an "IXP" has raised funds to purchase a switch and/or found somewhere to colocate it :)