Peeringdb: Add certifications/compliance to Network, Exchange and Facility objects

[mcmanuss8]

Add a field to Networks called "MANRS certified:" with a dropdown with the following values:

• Not certified
• Working to certification
• Certified

Ideally peeringdb would automatically update records based on an API - marking those that are certified as certified and pushing ones that are not that say they are back to Working to certification.

[job]

Small comment about the Web UI: I would skip "Not certified" and simply not mention MANRS at all if a network is not part of MANRS. I feel it is good to show a MANRS badge when it is relevant (e.g. the network knew about it and invested some time) but MANRS is not a 'monopolist' in the certification business, so I'd prefer a slightly softer approach.

I'm confident the MANRS people are happy to help automate this through an API or JSON file dump to make this a 100% no-humans-involved process.

[arnoldnipper]

How would the MANRS badge then make it into the net's object, @job?

[arnoldnipper]

@mcmanuss8, IXes also may be MANRS compliant.

[job]

How would the MANRS badge then make it into the net's object, @job?

We could make a small rectangle area where 'badges' can be collected. The moment OpenIX or MANRS indicate that a given ASN or IX is compliant with their requirements, a small icon appears there.

Or we take a tabular approach where rows are added (or removed) with the left column being a short identifier for the badge and the right column a yes/no/status indicator.

In the API JSON output it might be good to make a 'badges' object where as we add more badges over time, more keys appear (with a value of 'not defined', 'yes', 'something'.

[arnoldnipper]

Not sure that we need a badges object. Or would we then have additional objects like ixbadge and netbadge Something like

{
  "id": 1,
  "badge_id": 1,
  "name":  "MANRS",
  "compliance": "full",
  "ix_id": 31,
  "created": "2020-08-08T00:00:00Z",
  "updated": "2020-08-08T00:00:00Z"
  "status": "ok"
}

[job]

[shane-kerr]

Looking at the list of MANRS participants, this seems to me to not be a simple toggle.

Actions 1, 3, 4, and 5 see, binary, but action 2 has sub-actions.

Possibly this should be something like:

MANRS actions 1: [✓] 2: [⯀] 3: [✗] 4: [✓] 5: [✓]

This would indicate that actions 1, 4, and 5 are implemented, action 3 not, and action 2 partially-implemented. Tooltips could give more detail about what the action is.

[arnoldnipper]

Looking at the list of MANRS participants, this seems to me to not be a simple toggle.

It doesn't have to be. And I would not overload PDB. Why not provide the URL as well e.g. https://www.manrs.org/ixps/ixp-participants/entry/334/

[shane-kerr]

Looking at the list of MANRS participants, this seems to me to not be a simple toggle.

It doesn't have to be. And I would not overload PDB. Why not provide the URL as well e.g. https://www.manrs.org/ixps/ixp-participants/entry/334/

I'm a little confused though. So you don't think we need to limit to a simple toggle, but you don't want us to include details in PeeringDB about the MANRS actions? I guess your proposal is a URL instead of a checkbox, and no further details? (I like the URL idea, although if we limit the data to that it means that if anyone is interested in specific MANRS actions they basically have to go to the MANRS site instead of PeeringDB.)

[arnoldnipper]

Yes, a checkbox. In case of MANRS it means it is a MANRS participant. But we shouldn't try to explain what MANRS compliance levels are met. Hence the URL.

[vegu]

Here's our first revision of specifications - please review and discuss, will move to "Ready to implement" once we're happy

Abstract

Implement a way to track and determine certification badges on a per entity level,
with support for all entity types as needed. System should be designed to be open-ended
to allow other badge types easily.

Considerations

Badges would ideally be automatically updated by querying the provider (MANRS, OpenIX),
however this might be pending some implementation of the target provider to easily query
for an entity.

In the case of MANRS we have 5 different actions to keep track of. Need to determine
if those are to be grouped in any way, or have different badges for each, or perhaps
require all for a single MANRS badge.

Specifications

Database

A single table that keeps track of an entity’s badges by it’s reference tag and id.

• ref_tag (ix, net, fac etc)
• id (entity id)
• badge (MANRS, OIX1, OIX2, etc.)
• url (url to certification page, https://www.manrs.org/ixps/ixp-participants/entry/334/)
• created
• updated

UI

• Display badges on the right hand side below the other elements as described
  https://github.com/peeringdb/peeringdb/issues/801#issuecomment-670956810
• Clicking the badge will take you to the certification page

API

• Add a badge_set property to the entities that can have badges

“badge_set” : [
    {
    “url”: “https://www.manrs.org/ixps/ixp-participants/entry/334/”
    “badge”: “MANRS”,
    “created”: “2020-08-08T00:00:00Z”
    },
    ...
]

• Allow querying by providing a badge filter that follows existing api querying functionality
  
  
  
  • /api/ix?badge=MANRS
  
  
  • /api/ix?badge__in=MANRS,OIX1