Peeringdb: Additional self-selection fields for IX objects

[mcmanuss8]

If we end up with a lot of ideas, we can split the conversation into multiple issues to keep it sane. Let's try one ticket for now though.

Format here is the field and below a list of options for that field. All options are placeholders and are up for debate :)

Service Level:

• Best Effort (no SLA)
• Normal Business Hours
• 24/7 Support

OpenIX Certification:

• Not Certified
• Working Towards Certification
• Certified
  (For this value, would be excellent if we could hook into an openix api)

Commercial Terms:

• No Commercial Terms
• Bundled with other services
• Non-recurring fees only
• Recurring fees

[arnoldnipper]

+1

[shane-kerr]

+1

Seems like a reasonable start.

[job]

Might be good to rename "Commercial Terms:" to "Terms:"

[job]

Similar to what I commented in the MANRS issue, I think that if an IX is not OpenIX certified, the phrase OpenIX should not show in the Web UI for a given IX.

I imagine over time various "badges" and "self-selection" datafeeds can pop up, perhaps from competing standards / certification organisations.

Since humans have a strong tendency to 'check all the boxes', I feel we should only show boxes that actually have been checked, rather than blindly encourage people to join specific certification processes for no other than than checking the box on peeringdb.

Also from a visual perspective 'less is more'

[arnoldnipper]

Similar to what I commented in the MANRS issue, I think that if an IX is not OpenIX certified, the phrase OpenIX should not show in the Web UI for a given IX.

How would an IX then get OpenIX certified? The current idea is that the IX might tick the box but it will only be shown if we can verify at OpenIX.

Or did I misunderstand you?

[job]

Similar to what I commented in the MANRS issue, I think that if an IX is not OpenIX certified, the phrase OpenIX should not show in the Web UI for a given IX.

How would an IX then get OpenIX certified? The current idea is that the IX might tick the box but it will only be shown if we can verify at OpenIX.

Or did I misunderstand you?

That seems like duplicate work, I can see a few approaches:

1) periodically peeringdb fetches the latest data from $badge_provider, and offers those badges up to display on the ix record, the user selects which badges they want to display

2) periodically peeringdb fetches the latest data from $badge_provider and it is displayed automatically

3) the user indicates they have a badge, and then peeringdb fetches confirmation from the $badge_provider

I think option 2 is my current preference, as it is least work for all involved. Option 1 also seems user friendly

[arnoldnipper]

Option 2 clearly goes against our paradigm that data is user-provided. Hence I would go for option 3.

[johannesmoos]

I think it would be handy to have the info_traffic and info_ratio fields of the net object also to be present in the ix object. Options can be carried over. Background: IX Route servers are modelled as networks and specifying the IX traffic [ratio] there is technically not 100 % correct. IXPs can configure these values in the ix object. Does this make sense?

[arnoldnipper]

Thanks for suggesting. info_traffic does make perfect sense to me, @johannesmoos. But shouldn't info_rationot also be "Balanced"?

[johannesmoos]

Yes, this should almost always be the case. I think I overthought this one (interconnecting IXs, …). So let’s keep it simple and forget about the info_ratio part.

[martzuk]

Option 2 clearly goes against our paradigm that data is user-provided. Hence I would go for option 3.

IMHO a combination of 1 and 3, as with JSON import a user can select that they're happy for the IX to populate data on their record for them, which strictly goes against the paradigm of data being user provided.

[grizz]

@peeringdb/pc so, skipping OIX since I think that's handled in #801

What do we want for field names here?

service_level
terms

And the field types should be string, with a choice drop down?

Since this will be adding a field to the API, should we get a full vote on it?

[vegu]

summary

• add service_level field to InternetExchange object and api serializer, represented as a choice dropdown with the following string values:
  
  
  
  • Best Effort (no SLA)
  
  
  • Normal Business Hours
  
  
  • 24/7 Support
  
  
  • Not Disclosed default
  
  
• add terms field to InternetExchange object and api serializer, represented as a choice dropdown of the following string values:
  
  
  
  • No Commercial Terms
  
  
  • Bundled With Other Services
  
  
  • Non-recurring Fees Only
  
  
  • Recurring Fees
  
  
  • Not Disclosed default