-
Notifications
You must be signed in to change notification settings - Fork 24
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
Update ixp-member-list.schema.json #30
base: master
Are you sure you want to change the base?
Conversation
A poc (email address is sufficient) to send error reports to is needed if we want to make efficient use of the IX-F JSON schema
We are thinking about scoping fields. While support is public and up to the IX to provide, errors with the schema might be IXPDB internal only and MUST be mandatory. Hence it doesn't matter if in 95% these addresses might be the same. Does that make sense? |
I understand why this seems like a useful data point of have but I don't see it as necessary or wise. First of all, this will be static data jammed into whatever implementation of the JSON export schema and - like most aliases - will go stale quickly. I.e. it's usefulness will degrade (quite quickly I imagine) over time. Because it's mandatory (and I guess it should be if it's in there), it's going to add an extra step for all users of IXP Manager for example. They'll now need to add a static email address to the configuration file for the PoC. Every previous schema update has required no manual interventions. I certainly wouldn't put my own direct email in there for INEX and I imagine most people would be the same. Hence it will fall back to the support details already in the schema or already publicly available on the IX's website. 99% of IX's are small enough that contacting the general technical support email will be someone who can help or have a first degree relationship with the right person. For the larger ones, IX-F associations will already have suitable contacts to get around the larger front line support teams. |
What do you propose that we have a mechanism to automate import of IX-F JSONs to IXPDB? |
I'm not sure that adding a point of contact to the json data file where its purpose is to be notified if the import of that same file fails is useful. On the proof of concept we at INEX did for the export directory some time ago, our add your export form required two pieces of information: the json export URL and a point of contact. |
Of course, it is useful. However, you don't have to believe it. |
A poc (email address is sufficient) to send error reports to is needed if we want to make efficient use of the IX-F JSON schema