[PDB Data Ownership-TF] Fwd: [peeringdb/peeringdb] Add location of Physical IX-Port & Router Port (#607)
filiz at peeringdb.com
Wed Jan 22 07:11:40 PST 2020
There is some discussion on github relating to the recent discussions we had on the TF so I thought I would bring that to you attention too.
Following is only the latest message on the github issue of course. Full thread can be seen at:
> Begin forwarded message:
> From: Marty Strong <notifications at github.com>
> Subject: Re: [peeringdb/peeringdb] Add location of Physical IX-Port & Router Port (#607)
> Date: 21 January 2020 at 11:56:20 CET
> To: peeringdb/peeringdb <peeringdb at noreply.github.com>
> Cc: Subscribed <subscribed at noreply.github.com>
> Reply-To: peeringdb/peeringdb <reply+ALZZ7OYAB7PCDPZEIW2LEC54GQFVJEVBNHHCAANIKQ at reply.github.com>
> I think having both IXP port and Router port is important
> I agree, but I see a conflict in a few places. We're trying to show a physical attribute (well actually two), but we seem reluctant to enforce at minimum 1 facility, see #611 <https://github.com/peeringdb/peeringdb/issues/611>.
> IMHO the user should be able to select the port location as a drop down, populated by the facilities an IX lists on its entry. To cover the situation of it being an entirely (playground IX) we should have a "Virtual" facility in pdb (see #515 <https://github.com/peeringdb/peeringdb/issues/515>). To cover the situation of a facility not being listed the IX can either ask the site operator to add it, or it can be suggested to pdb (https://peeringdb.com/suggest/fac <https://peeringdb.com/suggest/fac>). The user should then be able to select the router location by either selecting "same as port" or "remote".
> This does the following:
> Makes it easy for a user to provide the information without copying/pasting lat/lon
> Keeps the data quality high
> Separates "real" (seems to be a subjective term) and "playground" IXPs without having to remove them
> To echo what Martin says:
> You either have facilities or you don't exist. Period.
> However we want to encourage use of PeeringDB in BGP experimentation and the like, so the above feels it can accomodate both the use case of improving PeeringDB functionality and data quality without excluding said use case of playground IXPs (which seem to have ballooned as of late).
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub <https://github.com/peeringdb/peeringdb/issues/607?email_source=notifications&email_token=ALZZ7O2TZ4RTCQSBOEP6C2DQ63IFJA5CNFSM4JZ6RYZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJPKRJY#issuecomment-576628903>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALZZ7O3IR3DTDQOOTYF65P3Q63IFJANCNFSM4JZ6RYZQ>.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the DataOwnership-TF