<div dir="ltr"><div dir="ltr">Hoi Arnold!<div><br></div><div>Thanks for helping this along.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 30, 2021 at 1:57 AM Arnold Nipper <<a href="mailto:arnold@nipper.de">arnold@nipper.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
may I suggest to make the export configurable. E.g. like<br>
<br>
Status                  Export  Export Name<br>
Connected               yes     active<br>
Awaiting X-Connect      no<br>
Quarantine              yes     inactive<br></blockquote><div><br></div><div>From my experience, this may still trigger IX-F import alerts. From my sampleset of 4 (a few small IXPs, and SwissIX), the IXP will make an IP assignment and inform the member "hey welcome to IXP $x, your port is $P and your addresses are <$a>". Enthusiastic members then go update their peeringdb entry by themselves.</div><div><br></div><div>So as soon as the list of $a is given to the member, we risk the state of IXPManager not exporting IX-F, but the member having updated their entry.</div><div>This means, in practice, that as soon as the member exists in the IXPManager database, the IX-F export should reflect an export of 'inactive' or 'active', not not 'no-export', because that will trigger the peeringdb importer escalation.However, if the member doesn't exist at all at IXPManager, but they did claim an IP in peeringdb, that does sound like a legitimate escalation to me.</div><div><br></div><div>So I would rewrite your truth table as:</div><div>Connected, yes, active</div><div>*, yes, inactive</div><div><br></div><div>groet,</div><div>Pim</div><div><br></div><div>groet,</div><div>Pim</div><div> </div></div>-- <br><div dir="ltr" class="gmail_signature">Pim van Pelt <<a href="mailto:pim@ipng.nl" target="_blank">pim@ipng.nl</a>> <br>PBVP1-RIPE - <a href="http://www.ipng.nl/" target="_blank">http://www.ipng.nl/</a></div></div>