Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve IX-F JSON importer #518

Closed
arnoldnipper opened this issue Jun 27, 2019 · 53 comments
Closed

Improve IX-F JSON importer #518

arnoldnipper opened this issue Jun 27, 2019 · 53 comments

Comments

@arnoldnipper
Copy link
Contributor

@arnoldnipper arnoldnipper commented Jun 27, 2019

Currently, the importer silently removes networks from netixlan if there is a mismatch ( allow_ixp_update set to no) or if the network does not have an entry in the IX member list. However, data from IXes also may contain errors. To protect networks from being removed erroneously the importer will be modified.

  • if a netixlan record is going to be deleted, send a notification to the NOC role account. Increment notifier_counter by one.

  • if notifier_counter == threshold, remove netixlan record.

  • threshold should be chosen to cover at least 48h

This complements #505

@robwwd

This comment has been minimized.

Copy link

@robwwd robwwd commented Jun 27, 2019

From my point of view it would better to go to policy contacts as I think they would maintain the record not a noc (at least our NOC is there for fixing network issues and can't update our peeringdb record).

I think more than 48 hours would be needed for policy contacts as most would not work weekends. I'd prefer a much longer period than 48 hours.

@Shawna

This comment has been minimized.

Copy link

@Shawna Shawna commented Jul 22, 2019

How should this change be shown in the preview - does the preview need to be aware whether an entry is marked for deletion versus actually going to be deleted?

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Jul 22, 2019

@Shawna , making the distinction between "marked for deletion" and "will be deleted" would be super cool.

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Jul 31, 2019

@Shawna and @robwdwd, what about

  • notifying noc, technical and policy role account

  • notify as often as to cover 120 hours

Please note that currently the importer only runs once per day. However, it is planned to run the importer once per hour. @ccaputo and @job, would that still make sense given that stale entries may only be removed after 120 hours.

Maybe it's also worth to add a switch to disable notifications as you may not want to be swamped by them.

If we look at the distribution of roles we find

2729 "NOC"
1079 "NOC","Policy"
1263 "NOC","Policy","Technical"
1843 "NOC","Technical"
417 "Policy"
1068 "Policy","Technical"
2468 "Technical"

@ccaputo

This comment has been minimized.

Copy link
Contributor

@ccaputo ccaputo commented Jul 31, 2019

Seems to me that once per hour would still make sense for those that have allow_ixp_update set to yes, so they don't have to wait up to a day to see it auto-populate. (I confirm as of today the importer is only running once per day.)

@fkorsback

This comment has been minimized.

Copy link

@fkorsback fkorsback commented Aug 2, 2019

Heya

I think we are being hit by this as well. AS16509 is trying to add our new port to INEX2 in PDB, it adds just fine but it gets deleted every night, and we do NOT allow IX-F to update our data. Further troubleshooting shows that we are not being listed in the IXPDB as of yet

(https://ixpdb.euro-ix.net/en/ixpdb/ixp/645/asns/)

Which leads me to think that we are getting hit by the same bug here.

16509 has no interest whatsoever in having IXPDB data update our data.

The secondary problem we get with this is that we rely on PeeringDB for public peering sessions, so if our record is not there, we are not peering on that exchange.

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 2, 2019

@fkorsback jfyi: IXPDB != PDB ... and did you talk to INEX? And I would not really call it a bug. We want the IXes to be the authoritative source.

@fkorsback

This comment has been minimized.

Copy link

@fkorsback fkorsback commented Aug 2, 2019

@fkorsback jfyi: IXPDB != PDB ... and did you talk to INEX? And I would not really call it a bug. We want the IXes to be the authoritative source.

Im aware that IXPDB != PDB :)

Sure. I talked to INEX. The problem most likely is that our port is currently in state "Provisioning" and therefore is not pushed to IXPDB by the IXP . This is all fine. However we have actively NOT enabled that IXP is allowed to update our entries in PDB. And therefor we were under the assumption that we could add a IXP entry into our account regardless what IXPDB says or not.

But now it gets deleted after 24hrs.

That cant be working as intended?

@job

This comment has been minimized.

Copy link
Contributor

@job job commented Aug 2, 2019

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 2, 2019

@fkorsback and @job , regardless of the status of allow_ixp_updates, if net and ix disagree on the netixlan record, ix wins as it is deemed authoritative.

However, if I now query INEX I see that the 2nd entry should make it.

@fkorsback

This comment has been minimized.

Copy link

@fkorsback fkorsback commented Aug 2, 2019

Yeah to fix the immediate problem so we had INEX fake our presence on the exchange to not have the IX-F importer delete OUR entries. So for this specific incident we are all good.

I certainly don't like silent deletes, i don't even like loud deletes. I don't like deletes at all actually. I think its in everyones best interest to not have data deleted by third-parties at all. Friendly suggestions and nudges sure, thats good, im not opposed to having PDB mail me every 24th hour to fix conflicting entries, cause that will of course be a problem for me to and definately in my companies best interest to fix. And having conflict with "null" as in this case or actual typos in IP-adresses should probably be handled differently.

Im very afraid of what would happen if error leaks into IX-F for some reason, and then starts to wipe away data. I know in our network that would definitely make new peerings on that exchange impossible, and quite possibly also automatic decommissions would happen. until the data is back. We use PeeringDB as authoritative data and take very seriously on keeping the record straight in there.

A solution i would be happy with is to make the button Actually work, no external updates whatsoever in any field. And if i have pending conflicts spam away, the database exists for you, me, and everyone else. And if that doesent fix the problem, in lets say a month. It becomes a PeeringDB Admin question to perform an executive delete.

@job

This comment has been minimized.

Copy link
Contributor

@job job commented Aug 2, 2019

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 2, 2019

@fkorsback, I fully understand your point. However, there was a consensus on how to handle data. The network is the authoritative source when it comes to the decision whether it wants to be listed or not. Esp. no ix is allowed to add entries w/o permission of the network. but as soon as there is an entry, the ix is the authoritative source.

@job, there is no need for a "deleted" attribute as PDB is not checking the status field anymore

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 2, 2019

@job, there is no need for a "deleted" attribute as PDB is not checking the status field anymore

I have to stand corrected. It still checks and accepts active, connected and operational. There was also a lengthy discussion on whether to import records in status provisioning and consensus was to not do so as this may cause operational issues. @ccaputo may tell more about that.

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 2, 2019

Maybe a solution to that all would be to enhance netixlan with an ops_status attribute.

@nickhilliard

This comment has been minimized.

Copy link

@nickhilliard nickhilliard commented Aug 2, 2019

If allow_ixp_updates is disabled, then probably the data shouldn't be deleted from pdb. There could be circumstances where pdb might consider deleting the data, for example, if the IXP has assigned that IP address to someone else or in other situations which involved a clear conflict.

Regarding the comments above, IXP Manager will only export data if the participant connection is in state connected. If the link is in e.g. awaiting-xconnect or in-quarantine, then IXP-M won't export because that would be inappropriate. This is probably the least bad approach to take.

It's very brave of any organisation to depend on a third party database for a fully automated internal provisioning decision. I'm trying to resist the idea of opening up a new ISP called Internet Widgets Ltd'); DROP TABLE Peers; --, but it's hard.

@nbakker

This comment has been minimized.

Copy link

@nbakker nbakker commented Aug 2, 2019

@arnoldnipper:

@fkorsback, I fully understand your point. However, there was a consensus on how to handle data.

This consensus as you saw it is clearly not applicable anymore. From #513 and this, it's clear that network operators feel that we own the data we put into PeeringDB.

The network is the authoritative source when it comes to the decision whether it wants to be listed or not. Esp. no ix is allowed to add entries w/o permission of the network. but as soon as there is an entry, the ix is the authoritative source.

That's not how it should work. If I put in data, I am responsible for that data. If I choose to allow an IXP to put in data, the IXP takes responsibility.

In case of errors with operational impact, flagging entries with notification and perhaps eventual deactivation (i.e., show up for the owner - as deactivated, and allowing for reactivation with the click of a button - but not for others or in API requests), as @job proposed, may be an avenue worth exploring.

We now have multiple documented cases where unwanted results were achieved, either as unintended side effect (port not yet live) or by error (empty export), that caused loss of data, with no upside.

@arnoldnipper, are you wearing your PDB support hat or your DE-CIX management hat in these discussions?

@ccaputo

This comment has been minimized.

Copy link
Contributor

@ccaputo ccaputo commented Aug 2, 2019

In the past, part of the idea with the IX-F JSON importer is that once a network departs an IXP, the IXP can cause PeeringDB to be automatically updated so that the network is no longer listed.

BUT, this is a problem if the IXPs exporter is buggy or not current, since BGP provisioning is happening more and more based on PeeringDB data.

Thus, regardless of allow_ixp_update setting, I suggest the most PeeringDB should do is have a visible indicator which indicates whether the currently populated data is not valid-per-ixp. Could be as simple as coloring the IP addresses red and/or making them italic if they don't match the IX-F JSON data. This flag could also be in the PeeringDB database & REST API so that provisioning software can examine it and decide whether to consider the IXP IX-F JSON data authoritative or not. Choice in the user's hands.

Thus I suggest the following course of action:

  1. PeeringDB immediately stop removing data when allow_ixp_update == no. We can disable the cron job on the production site with ease.

  2. Revise the IX-F JSON importer to no longer remove data when allow_ixp_update == no.

  3. Have the Product Committee scope out a new flag, possibly named "valid-per-ixp" and drive it to implementation both in the GUI and database/REST API. Off the top of my head, the flag settings could be {true|false|undetermined}.

If the above is adopted, https://docs.peeringdb.com/ix-f-json-import-rules/ could be revised as follows:

Remove: "Generally, if a network does not have an entry in the IX member list, the network IX entry is removed."

Change: "allow_ixp_update: no - If a network has an IX entry with differing (asn, ipaddr4, ipaddr6), the network IX entry is removed"

to be: "allow_ixp_update: no - If a network has an IX entry with differing (asn, ipaddr4, ipaddr6), the conflict will be indicated on the website and in the API."

Question for all: Would setting to red and/or italic those IP addresses which are in conflict with IX-F JSON data, on both ix and net pages, be considered overstepping into the realm of user-controlled data?

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 2, 2019

@ccaputo with the improvements proposed there is no need to stop IX-F JSON imports as it will only delete data after several notifications and after having waited for at least 120h (5 days).

As per default allow_ixp_updates is set to "FALSE", we are in the same situation again that stale entries don't get removed from PDB and customers which have been re-assigned this address get crazy adding their address.

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 2, 2019

@arnoldnipper, are you wearing your PDB support hat or your DE-CIX management hat in these discussions?

@nbakker, I'm wearing my Arnold Nipper hat

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 2, 2019

It's very brave of any organisation to depend on a third party database for a fully automated internal provisioning decision.

@nickhilliard, replicating data definitely is not the way to go. Trusting PDB means trusting 3rd party

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 2, 2019

Regarding the comments above, IXP Manager will only export data if the participant connection is in state connected. If the link is in e.g. awaiting-xconnect or in-quarantine, then IXP-M won't export because that would be inappropriate. This is probably the least bad approach to take.

@nickhilliard, is this settable by the IXP-M user? That would imho be a better approach.

@Shawna

This comment has been minimized.

Copy link

@Shawna Shawna commented Aug 2, 2019

@arnoldnipper

  • notifying noc, technical and policy role account

Sure.

  • notify as often as to cover 120 hours

What do you mean by this?

@ccaputo

This comment has been minimized.

Copy link
Contributor

@ccaputo ccaputo commented Aug 2, 2019

@ccaputo with the improvements proposed there is no need to stop IX-F JSON imports as it will only delete data after several notifications and after having waited for at least 120h (5 days).

As per default allow_ixp_updates is set to "FALSE", we are in the same situation again that stale entries don't get removed from PDB and customers which have been re-assigned this address get crazy adding their address.

The imports aren't the problem - it's the deletes. Regardless of the length of delay, if not mitigated, the operational impact will still happen. Thus I don't see how this honors the feedback being received.

@nickhilliard

This comment has been minimized.

Copy link

@nickhilliard nickhilliard commented Aug 2, 2019

@nickhilliard, is this settable by the IXP-M user? That would imho be a better approach.

IXP-M publishes information about connected ports, not ports stuck in varying states of provisioning. Exposing more complication and miscellaneous internal IXP state information creates more situations to deal with on the data consumption side with almost no benefit.

I'd prefer to see the meaning of allow_ixp_updates to be clarified. If it means no IXP updates, then this situation would be resolved. If it means that IXP updates are accepted in some situations, it might be better to call it something else in order to cut down on confusion.

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 2, 2019

  • notify as often as to cover 120 hours

What do you mean by this?

As you may be only count number of notifications before deleting, you would have to adjust the threshold by how often the importer runs. Currently, the importer runs once per day. Hence after five notifications, the entry may be deleted. When running once per hour this threshold has to be raised to 120.

Does that make sense?

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 2, 2019

Exposing more complication and miscellaneous internal IXP state information creates more situations to deal with on the data consumption side with almost no benefit.

That probably should be best left to the user. And as we have seen, announcing information in an earlier state does make sense. However, I completely agree that there should be a clear semantic behind te state of a connection.

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 2, 2019

The imports aren't the problem - it's the deletes. Regardless of the length of delay, if not mitigated, the operational impact will still happen. Thus I don't see how this honors the feedback being received.

With import, I meant the IX-F JSON import. And of course, the deletes cause problems. That's the reason we want to introduce notifications. 120 hours should be sufficient to resolve any issues. In case this still seems too short, make it longer. Only a few IX may re-issue old addresses that fast. But still, everything would be automated.

@nbakker

This comment has been minimized.

Copy link

@nbakker nbakker commented Aug 2, 2019

@ccaputo I like it.

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 2, 2019

I think my idea (#518 (comment)) is appropriate for this issue and would love to know how others feel about it.

@ccaputo, I still think it makes more sense to have it as a separate issue. Simply makes it easier to know what we are talking about

@fkorsback

This comment has been minimized.

Copy link

@fkorsback fkorsback commented Aug 2, 2019

In the past, part of the idea with the IX-F JSON importer is that once a network departs an IXP, the IXP can cause PeeringDB to be automatically updated so that the network is no longer listed.

BUT, this is a problem if the IXPs exporter is buggy or not current, since BGP provisioning is happening more and more based on PeeringDB data.

Thus, regardless of allow_ixp_update setting, I suggest the most PeeringDB should do is have a visible indicator which indicates whether the currently populated data is not valid-per-ixp. Could be as simple as coloring the IP addresses red and/or making them italic if they don't match the IX-F JSON data. This flag could also be in the PeeringDB database & REST API so that provisioning software can examine it and decide whether to consider the IXP IX-F JSON data authoritative or not. Choice in the user's hands.

Thus I suggest the following course of action:

  1. PeeringDB immediately stop removing data when allow_ixp_update == no. We can disable the cron job on the production site with ease.
  2. Revise the IX-F JSON importer to no longer remove data when allow_ixp_update == no.
  3. Have the Product Committee scope out a new flag, possibly named "valid-per-ixp" and drive it to implementation both in the GUI and database/REST API. Off the top of my head, the flag settings could be {true|false|undetermined}.

If the above is adopted, https://docs.peeringdb.com/ix-f-json-import-rules/ could be revised as follows:

Remove: "Generally, if a network does not have an entry in the IX member list, the network IX entry is removed."

Change: "allow_ixp_update: no - If a network has an IX entry with differing (asn, ipaddr4, ipaddr6), the network IX entry is removed"

to be: "allow_ixp_update: no - If a network has an IX entry with differing (asn, ipaddr4, ipaddr6), the conflict will be indicated on the website and in the API."

Question for all: Would setting to red and/or italic those IP addresses which are in conflict with IX-F JSON data, on both ix and net pages, be considered overstepping into the realm of user-controlled data?

Im aligned with @ccaputo here. Flagging the data in a feasible way is definately a good approach to this, make it red, make it italic, make a tickbox next to it. Im cool with either option really. I dont want any auto-deletion of data, even after 120 hours or 120 days. If people don't delete their own wrong data after several reminders and constant api+ui flagging id say its up to a human in the admin-group to determine if the entry should be deleted.

And for those that do accept IX-F updates, then keep the operations as it is today.

As a user of "do not allow IXPDB updates" i fully expect that the only ones that can modify ourrecord is approved admins from our organisation, and perhaps someone from the committee if a resolution cant be self-serviced within appropriate time.

This should solve both problems at once really?

@ccaputo

This comment has been minimized.

Copy link
Contributor

@ccaputo ccaputo commented Aug 2, 2019

I think my idea (#518 (comment)) is appropriate for this issue and would love to know how others feel about it.

@ccaputo, I still think it makes more sense to have it as a separate issue. Simply makes it easier to know what we are talking about

Hi @arnoldnipper: Sorry for the confusion. This thread became more generic than your proposal, so I tossed my idea in here, but I am happy to move my idea off to new issue. The "indicator" issue is now at: #540

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 2, 2019

i fully expect that the only ones that can modify ourrecord is approved admins from our organisation, and perhaps someone from the committee if a resolution cant be self-serviced within appropriate time.

That definitely needs a definition what your data is. Following all discussions, data ownership of netixlan would be at the ix, not the net. The same way as data ownership of netfac is at fac and not at net.

I guess it would make sense to have a policy document on this

@nbakker

This comment has been minimized.

Copy link

@nbakker nbakker commented Aug 3, 2019

The same way as data ownership of netfac is at fac and not at net.

Networks declare themselves present at facilities; facilities don't get to reject networks. Or did this change?

@jzp-github

This comment has been minimized.

Copy link

@jzp-github jzp-github commented Aug 3, 2019

My $0.02:

  • data I enter is "my data"
  • autodeletion on conflict is bad
  • #540 good
@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 3, 2019

Networks declare themselves present at facilities; facilities don't get to reject networks. Or did this change?

If a facility owner tells us that a network is not in their facility AC removes the entry.

@nbakker

This comment has been minimized.

Copy link

@nbakker nbakker commented Aug 3, 2019

If a facility owner tells us that a network is not in their facility AC removes the entry.

I think many will be fine with going back to manual review instead of automated (and proven broken) deletions of peering data.

What does AC stand for in this context?

@job

This comment has been minimized.

Copy link
Contributor

@job job commented Aug 4, 2019

Networks declare themselves present at facilities; facilities don't get to reject networks. Or did this change?

If a facility owner tells us that a network is not in their facility AC removes the entry.

I'm not sure this is a sensible practice... in the day and age of cloud and virtualisation facilities simply don't have the capability to confirm whether a network is present or not. Do we really want to give InterXion the ability to delete all non-DE-CIX IXPs from the Frankfurt facilities? What is the process to revise this policy?

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 4, 2019

What does AC stand for in this context?

AC == Admin Committee

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Aug 4, 2019

@job, a facility owner already today can delete a whole facility. And I have sparked a discussion on the Product Committee List on ownership of records.

@koalafil koalafil added Quote In a Quote and removed Quote labels Aug 14, 2019
@durkovic

This comment has been minimized.

Copy link

@durkovic durkovic commented Oct 9, 2019

More than a month ago, IX-F importer was disabled and currently there's no replacement. Networks which configured 'Allow IXP Updates' = YES expect that they don't have to update their entries manually, but this is not happening. Also no new entries are being created and the only solution is to enter everything by hand.

IMHO this is a huge step backwards. I fully understand the problems with unwanted/unexpected deletions of valid entries, but completely disabling the IX-F importer created no smaller problem for all that relied on its functionality.

Therefore I'd like to suggest re-enabling IX-F importer with one modification - it should not perform deletions when 'Allow IXP Updates' = NO. If modified this way, no unwanted deletions will happen, and networks which set YES will get back all the automation they need & rely on. Currently all automation is gone and noone knows if/when it's ever coming back :-(

@nbakker

This comment has been minimized.

Copy link

@nbakker nbakker commented Oct 9, 2019

@durkovic There is broad consensus that "Allow IXP Updates = NO" should indeed not allow automatic updates including deletions. For now you can check a preview of IX-F Import on the PeeringDB website.

@durkovic

This comment has been minimized.

Copy link

@durkovic durkovic commented Oct 9, 2019

@nbakker OK, if there's consensus on this, could someone please modify the importer and re-enable it back? This is probably one-line fix and the current situation is really annoying.

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Oct 9, 2019

@durkovic There is broad consensus that "Allow IXP Updates = NO" should indeed not allow automatic updates including deletions. For now, you can check a preview of IX-F Import on the PeeringDB website.

@nbakker, my reading is a bit different. "Allow IXP Updates" is a bit misleading. What is needed is a policy regarding records like netixlan and netfac. We created a task-force to create one. Please join https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf to have your say.

@ccaputo

This comment has been minimized.

Copy link
Contributor

@ccaputo ccaputo commented Oct 9, 2019

Therefore I'd like to suggest re-enabling IX-F importer with one modification - it should not perform deletions when 'Allow IXP Updates' = NO. If modified this way, no unwanted deletions will happen, and networks which set YES will get back all the automation they need & rely on. Currently all automation is gone and noone knows if/when it's ever coming back :-(

@durkovic's suggestion may be a good compromise for the time being. It would seem to make the "Allow IXP Updates" toggle mean what it says. I bring up my #540 suggestion, which is that when there is a conflict, it is indicated/flagged rather than resulting in a data change. I'd add that conflicted data NOT be shown on an /ix/ page, but be shown on a /net/ page with indication of an issue. That way the IXP's ownership of their /ix/ page is respected while the network's ownership of their /net/ page is respected (albeit with conflict indication when one exists).

In this suggestion, API users that query the ix assignments (ex. https://www.peeringdb.com/api/ixlan/13), would only receive non-conflicted results. Either that, or the API is evolved to include a flag which indicates conflict status, but that would not help existing users that are pre-configuring peering based on the API, if any.

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Oct 9, 2019

@ccaputo , wouldn't it make more sense to wait for the dtf to come up with a policy? If we want to change something I would propose that instead of deleting a record on mismatch when Allow IXP Updates' = NO to generate a ticket to AC.

@ccaputo

This comment has been minimized.

Copy link
Contributor

@ccaputo ccaputo commented Oct 9, 2019

@ccaputo , wouldn't it make more sense to wait for the dtf to come up with a policy? If we want to change something I would propose that instead of deleting a record on mismatch when Allow IXP Updates' = NO to generate a ticket to AC.

Hey @arnoldnipper, just tossing around ideas here. I expect dtf to consider what is written on various issues including this one. Your idea to generate a ticket upon conflict when Allow IXP Updates' = NO is also a possible good one, iff AC wouldn't consider that to be creating an overload of additional work.

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Oct 9, 2019

@ccaputo, sooner or later it will pop up at AC anyway as in most cases a new customer wants to add an address and can't. Or the more pro-active ixes send an email because they did garbage collection. And in the rare cases where the ix made an error, it also helps the ix to improve. We also have all the data to get all parties involved when generating the ticket. Imho it's worth giving it a try given the fact that the dtf perhaps will not come up with a policy within the next 4-6 months.

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Dec 27, 2019

Covered by #585

@ccaputo

This comment has been minimized.

Copy link
Contributor

@ccaputo ccaputo commented Jan 9, 2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.