Ability for IX Operators to modify participants via web interface

[mustangthz]

Please add the ability for IX Operators to remove participants from IX's and reclaim IP's from the web interface.

[as44980]

Rather than going against the user-submitted data model would it be worth considering process where an IX operator can flag that a network is no longer a participant of their IX, thus allowing it to be removed following a review by an admin to prevent misuse... accidental or otherwise?

[arnoldnipper]

automation, automation, automation ... why not use the import in IX-F JSON format???

[mustangthz]

Because not everyone has the ability to automate everything.

On Feb 21, 2018, at 11:58 AM, Arnold Nipper notifications@github.com wrote:

automation, automation, automation ... why not use the import in IX-F JSON format???

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[as44980]

Or may perhaps even be contractually inhibited from revealing that a particular network is connected, but crucially not prevented from confirming that a network is not connected or at least is not presently allocated the IP which is listed in their PeeringDB record?

[grizz]

@peeringdb/pc no votes on this

This might be better done as a separate tool that creates the IX-F schema.

[mustangthz]

So you’re saying you have a JSON way for IX’s to mod their space, but you can’t spend a few cycles for IX’s that are not that automated to have a web interface to mod their space?

I think that’s a horrible disservice to small IX’s that do not have devops groups to deal with that.

I really urge the PDB team to reconsider.

-Chris

On Oct 10, 2018, at 12:06 AM, Matt Griswold notifications@github.com wrote:

@peeringdb/pc no votes on this

This might be better done as a separate tool that creates the IX-F schema.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[grizz]

@mustangthz I'm not saying that at all, no. I'm bringing this issue to the attention of the PC, as well as offering possible implementation ideas. The separate tool could easily be done in PDB.

[bijals]

FYI Euro-IX is already developing a tool for IXPs to do this and it will be available in a few weeks.

[mustangthz]

Rejecting a pdb feature request based on an IXF add is disingenuous.

On Oct 10, 2018, at 2:39 AM, Bijal Sanghani notifications@github.com wrote:

FYI Euro-IX is already developing a tool for IXPs to do this and it will be available in a few weeks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bijals]

I'm not rejecting the idea for PDB to do it, just stating for the record that there is another association/community working on the same piece of work.

And while we're talking about the JSON, version 0.8 is being worked on and will be released shortly.

[arnoldnipper]

I would like to see proposal from 20C on how much it would cost to implement this feature. So far IXes email AC and the IP gets removed within hours typically

[grizz]

@arnoldnipper we will check it out.

[mustangthz]

Thank you both!

On Oct 11, 2018, at 10:15 PM, Matt Griswold notifications@github.com wrote:

@arnoldnipper we will check it out.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[grizz]

@peeringdb/pc 20C made a free 3rd party implementation (https://fullctl.com/app/ixctl/) for US Thanksgiving :) Took quite a bit longer than we thought it would, but it seems to work pretty well. I'm personally not sure it belongs in PDB, but if there's interest, we will open source it and then it wouldn't take much to integrate it to the main site.

[mustangthz]

Thank you Matt for knocking it out of the park!!!

On Nov 25, 2018, at 11:28 PM, Matt Griswold notifications@github.com wrote:

@peeringdb/pc 20C made a free 3rd party implementation (https://fullctl.com/app/ixctl/) for US Thanksgiving :) Took quite a bit longer than we thought it would, but it seems to work pretty well. I'm personally not sure it belongs in PDB, but if there's interest, we will open source it and then it wouldn't take much to integrate it to the main site.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[arnoldnipper]

awesome, @grizz ... personally I also would keep it separate from PDB. Maybe something like https://tools.peeringdb.com could work

[mcmanuss8]

@peeringdb/pc seems like something that should be part of peeringdb or at least hosted on our domain (tools.peeringdb.com is a good idea Arnold). Anyone want to shepherd this one?

[arnoldnipper]

@peeringdb/pc seems like something that should be part of peeringdb or at least hosted on our domain (tools.peeringdb.com is a good idea Arnold). Anyone want to shepherd this one?

In the light of DOTF what about that an ix is also able to populate the exchange table manually. Usually this table would be fed by the IX-F JSON import.

@vegu / @pc comments?

[arnoldnipper]

@pc, please have a closer look at it. It would definitely help those 675/822 exchanges (82.11%) which are not yet able to provide an IX-F JSON import.

[shane-kerr]

In the light of DOTF what about that an ix is also able to populate the exchange table manually. Usually this table would be fed by the IX-F JSON import.

@arnoldnipper I'm not exactly sure what you are proposing. Can you please clarify?

[arnoldnipper]

@shane-kerr, I'm proposing that exchanges are allowed to add/change/delete netixlan records as well. However, instead of committing the change directly, it goes to the same table where IX-F JSON import changes go and we follow the same procedure as if this change came from an IX-F JSON import.

Does that explain what I'm proposing?

[ynbrthr]

+1

[shane-kerr]

@shane-kerr, I'm proposing that exchanges are allowed to add/change/delete netixlan records as well. However, instead of committing the change directly, it goes to the same table where IX-F JSON import changes go and we follow the same procedure as if this change came from an IX-F JSON import.

Does that explain what I'm proposing?

Yes, it makes it clear, thanks.

[arnoldnipper]

Summary

Provide a tool to allow exchanges to add/change/delete netixlan records. However, instead of committing the change directly, it goes to the same table where IX-F JSON import changes go and we follow the same procedure as if this change came from an IX-F JSON import.

Probably an existing tool could be used as a basis.

[egfrank]

Proposal

It sounds like the core problem here is that if IX's don't have resources to maintain their own IX-F feed, they don't have a way to propose changes to the netixlan records.

We suggest creating an endpoint /export/ixlan/{id}/proposal that outputs an IX-F feed with both current and proposed netixlan records. If the ix-f import isnt set up with an external URL, the importer will use this endpoint for these manual proposals.

IX admins propose changes through the now editable panel of Netixlans on the IX view; the UI to edit / add / change netixlans will be similar to the one on the network view. When an IX admin changes a Netixlan in this way, that change is registered as a proposal, displayed on the IX page, and reflected in the /export/ixlan/{id}/proposal endpoint.

On the backend, proposals to add / edit / delete netixlans will still POST / PUT / DELETE to /api/netixlan, but Peeringdb will check for permissions on the reques. If the user is not a Network Admin but is a IX admin, then those changes will registered as proposals.

[egfrank]

@peeringdb/pc here^ is a proposed summary for the issue for you to review! Moving to 3a as we discuss implementation

[arnoldnipper]

If the user is not a Network Admin but is a IX admin, then those changes will registered as proposals.

A user may be both. So, being an IX admin for the IX in question should be sufficient.

[grizz]

Err, I didn't read this issue when moving from Reached to Finalized, I don't see any other +1s so I'm not sure why it got pushed to reached. At any rate -1 from me, and moving back to decide.

[arnoldnipper]

@grizz, I see +1's from @mcmanuss8. @ynbrthr, @shane-kerr and me. Which makes >=3. What's your reasoning to push this back?

[leovegoda]

The Product Committee has decided to close this issue. There was no agreement on the concept and the issue has not been discussed for six months or longer.