Open martinhannigan opened 2 years ago
I don't think that a webpage should be required for a FAC.
@peeringdb/pc ping tks
Website has historical precedence. Not sure what that reasoning was. Would be good to know the initial context.
I don't recall what the initial reasoning was behind requiring the URL, perhaps to get information of the facility?
Is there actually a facility that doesn't have a website?
Yes. :) Well. It didn't. A website transition was taking place and rather than waste 2K on an update, it was decided by the party that it can wait for the new site. From what I understand it was to make sure that the facility "was real". That's not working out too well at the moment. Its also prescriptive.
I want to do this exclusively and not pay for web at all for example: https://www.nc-ix.org/
On Mon, May 30, 2022 at 5:56 PM Matt Griswold @.***> wrote:
I don't recall what the initial reasoning was behind requiring the URL, perhaps to get information of the facility?
Is there actually a facility that doesn't have a website?
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1156#issuecomment-1141498791, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQXL7WLU77PWYZX2LCLVMU2PLANCNFSM5UFK5Y3Q . You are receiving this because you were assigned.Message ID: @.***>
Tons of facilities do not have actual webpages.
Leasing agencies may have a “website” for the building.
As we make the transition to the edge and Tier2 and Tier3 markets, we’re going to have more and more FACs popping up without webpages.
-Chris
On May 30, 2022, at 10:14 PM, Martin Hannigan @.***> wrote:
Yes. :) Well. It didn't. A website transition was taking place and rather than waste 2K on an update, it was decided by the party that it can wait for the new site. From what I understand it was to make sure that the facility "was real". That's not working out too well at the moment. Its also prescriptive.
I want to do this exclusively and not pay for web at all for example: https://www.nc-ix.org/
On Mon, May 30, 2022 at 5:56 PM Matt Griswold @.***> wrote:
I don't recall what the initial reasoning was behind requiring the URL, perhaps to get information of the facility?
Is there actually a facility that doesn't have a website?
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1156#issuecomment-1141498791, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQXL7WLU77PWYZX2LCLVMU2PLANCNFSM5UFK5Y3Q . You are receiving this because you were assigned.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1156#issuecomment-1141597631, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIV5MPRXQUUWKRR7GJQKPCLVMVYW7ANCNFSM5UFK5Y3Q. You are receiving this because you commented.
PDB V3 +1
On Mon, May 30, 2022 at 23:22 mustangthz @.***> wrote:
Tons of facilities do not have actual webpages.
Leasing agencies may have a “website” for the building.
As we make the transition to the edge and Tier2 and Tier3 markets, we’re going to have more and more FACs popping up without webpages.
-Chris
On May 30, 2022, at 10:14 PM, Martin Hannigan @.***> wrote:
Yes. :) Well. It didn't. A website transition was taking place and rather than waste 2K on an update, it was decided by the party that it can wait for the new site. From what I understand it was to make sure that the facility "was real". That's not working out too well at the moment. Its also prescriptive.
I want to do this exclusively and not pay for web at all for example: https://www.nc-ix.org/
On Mon, May 30, 2022 at 5:56 PM Matt Griswold @.***> wrote:
I don't recall what the initial reasoning was behind requiring the URL, perhaps to get information of the facility?
Is there actually a facility that doesn't have a website?
— Reply to this email directly, view it on GitHub < https://github.com/peeringdb/peeringdb/issues/1156#issuecomment-1141498791 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AFA2YQXL7WLU77PWYZX2LCLVMU2PLANCNFSM5UFK5Y3Q
. You are receiving this because you were assigned.Message ID: @.***>
— Reply to this email directly, view it on GitHub < https://github.com/peeringdb/peeringdb/issues/1156#issuecomment-1141597631>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AIV5MPRXQUUWKRR7GJQKPCLVMVYW7ANCNFSM5UFK5Y3Q . You are receiving this because you commented.
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1156#issuecomment-1141628695, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQVJY4ILQOOFMEFCOMLVMWAXFANCNFSM5UFK5Y3Q . You are receiving this because you were assigned.Message ID: @.***>
Oh right, I think it was to help the AC deduce if a facility was real.
I find it hard to believe that a company owning a data center doesn't have a website, even if not facility specific. :)
So I would be good with removing website as a required field once the new process for approving facilities is put into place, @leovegoda can we link this issue to that project please?
Making the website entry optional would not require a v3 bump.
You’re thinking like someone that’s operated a real datacenter before :)
Think Wells building in MKE or Network 222 in Madison but with owners that know nothing about telecom.
It’s really common for these legacy carrier hotels to not have a “real” website, but have a page on the leasing agent’s site.
-Chris
On May 31, 2022, at 10:01 PM, Matt Griswold @.***> wrote:
Oh right, I think it was to help the AC deduce if a facility was real.
I find it hard to believe that a company owning a data center doesn't have a website, even if not facility specific. :)
So I would be good with removing website as a required field once the new process for approving facilities is put into place, @leovegoda https://github.com/leovegoda can we link this issue to that project please?
Making the website entry optional would not require a v3 bump.
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1156#issuecomment-1143034343, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIV5MPXBUSBK3AICM3LEDVLVM276BANCNFSM5UFK5Y3Q. You are receiving this because you commented.
Yeah, absolutely, I'm just saying there probably is a page describing the company somewhere.
Let's get the new facility approval rules in place and we can make website optional.
Agenda for next PC meeting to determine. Open a long time.
+1 Agreed that a website isn't necessary. I think we agreed a facility simply needed two or more networks to peer. That's it.
For reference, we already have other owners who may support this issue. https://github.com/peeringdb/peeringdb/issues/1407 @amartins
We already do this to some extent, but it's confusing from the schema perspective.
See https://www.peeringdb.com/fac/1517
The owner of 60 Hudson has a FAC object. They don't run facilities. Their tenants who have entered into long term leases with the owner of this FAC do operate facilities. The owner of this building also rents office space. They're neutral as to use on some of the floors. Listing NET objects on this object is confusing. Using the API to try and build a map of where I may be able to interconnect in NYC doesn't get me far. However, and what a shocker! it's hows me an IXP. But let's dig a little further.
Digital Realty appears to be a tenant at 60 Hudson. If you clock on their listing under this FAC they're actually a network and you get where DLR is connected. Not who's reachable in DLR's space. If you want to connect to them at 60 Hudson, then you can back into their FAC object at 60 Hudson: https://www.peeringdb.com/fac/10
So the schema here is:
--FAC (the address 60 Hudson) -----NET (Networks allegedly in the building) -------FAC (Digitals leased space) ---------NET (Digitals tenant networks)
Let's look at it from the IXP perspective:
--FAC (the address 60 Hudson) -----IXP (Only one)
Let's look at it if the schema worked for provisioning and ease of finding your way around:
---FAC (the address 60 Hudson) ----FAC (Digital Realty JFK12) -----IX (Big Ape) -----IX (Digital Realty IX) -----IX (GPE IX) -----IX (NetIX) -----IX (NYYIX)
and if we accept the stub:
---ADDR (the address 60 Hudson) ---FAC (Digital Realty JFK12) -----IX (Big Ape) -----IX (Digital Realty IX) -----IX (GPE IX) -----IX (NetIX) -----IX (NYYIX) ---FAC (Epsilon) -----IX (DECIX) -----IX (MASS-IX) -----IX (NetIX)
At least the immediate benefits I can see in a cleaner structure. And clearer location of everyone in the building "easier to find" Like IXPs and ability to move between suites in the buildings (and force them to compete better) as local net. I could go to an IXPs object and back into this, but hierarchically its not the first instinct and doesn't easily provide all of the available options on an automation basis.
Now let's try to focus:
The only thing this issue "adding an addr object" suggests is allowing owners to have their own object so that its clearer what's going on and the benefit a building provides. Currently the AC subjectively rejects building owners getting control of the FAC that they should have even though its common in PDB now:
Here are examples of others:
https://www.peeringdb.com/fac/1517 (Institutional investor owner) https://www.peeringdb.com/fac/525 (Institutional investor owner) https://www.peeringdb.com/fac/1671 (Coresite owned) https://github.com/peeringdb/peeringdb/issues/1407 (Equinix owned)
I can list many more.
Thanks! and hope that helps!
My last thought on if we should add an ADDR object (or come up with some other fix)
Here's a small sample of FAC objects that understand you also improve findability with the address inserted into FAC name. That seems like a strong indicator that we should put further work into the issue.
Digital Realty SFO (200 Paul) Digital Realty NYC (60 Hudson) Digital Realty NYC (111 8th Ave) Digital Realty SFO (365 Main) Equinix NY9 - New York, 111 8th Avenue Digital Realty NYC (32 AofA) Digital Realty ATL (56 Marietta) Digital Realty PHX (120 E Van Buren) Printer's Square Chicago (600 S Federal) Netrality - Indy Telcom Center - 733 W. Henry FiberNet Telecom Group - 60 Hudson St FiberNet Telecom Group New York (111 Eighth Ave) Markley Group One Summer Street Boston 165 Halsey Meet-Me Room Crown Castle Brentwood (1650 Islip) Digital Realty DFW (2323 Bryan St) Digital Realty LAX (600 W 7th) Digital Realty IAD (44480 Hastings) Netrality Houston - 1301 Fannin
HTH
I put addresses in our facility names to enhance the search results however entries now show up in the beta search when you search by address so not sure it's needed when out of beta.
I was just going to start removing addresses from my facility names due to this search feature update.
Glad we're getting it all sorted out, like search.
From an information organization perspective, I'm not sure search is a substitute for hierarchy or how we would map FAC's to addresses without a key like address. Search doesn't replace all the twisting people have done (as an example, that list) to get noticed. It's also less equitable. Some companies have people who do this full time and you can see that in the entire list. Others, don't really have the resources to figure it out or they're not marketing keen - which is also what address is helpful for.
Creating an effective content hierarchy can help search (and search engines) better understand and index the site which, in turn, leads to more accuracy. Been awhile since I had to write any serious code, but also strikes me a less resource and code intensive. YMMV.
HTH
On Mon, Dec 4, 2023 at 7:02 PM Peter Helmenstine @.***> wrote:
I put addresses in our facility names to enhance the search results however entries now show up in the beta search when you search by address so not sure it's needed when out of beta.
I was just going to start removing addresses from my facility names due to this search feature update.
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1156#issuecomment-1839770041, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQRQGYNSNSX4UJK5A23YHZP7VAVCNFSM5UFK5Y32U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBTHE3TOMBQGQYQ . You are receiving this because you were assigned.Message ID: @.***>
Still a strong -1 as it doesn't make sense for PeeringDB.
I removed the Digital Realty address hacks and grabbed another sampling.
1025Connect 1101 Stewart Ave, Garden City The Pittock 1623 Farnam 740 Notre-Dame West Montreal 55 Marietta 801 Tenth Street Modesto (Ayera) 500 Green (AKA VOLICO 2.0) Oak Tower Cincinnatti Bell - West 7th Street Citynet Columbus Citynet Pittsburgh Citynet Indianapolis Associated Engineering Plaza (10909 Jasper Avenue) CoreSite - Los Angeles (LA1) One Crown Castle Brentwood (1650 Islip) 801 Main Street - Lenoir Epsilon Global Hubs New York (60 Hudson) Equinix NY8 - New York, 60 Hudson FiberNet Telecom Group - 60 Hudson St FiberNet Telecom Group New York (111 Eighth Ave) FiberNet Telecom Group Newark - 165 Halsey 180 E Broad St. 710 Tucker St Louis INOC Albany (80 State St) 210 Sheppard Avenue East 3500 Garrott 151 Front Street West Toronto 321 S Boston Ave 360 Spear Quonix Datacenter (2401 Locust St) 274 Brannan Street The Franklin Exchange Tampa 800 south hope 165 Halsey Meet-Me Room 501 Franklin Ave 324 E Wisconsin 232 20th St NW, East Grand Forks 230 Congress
The data model requires a website entry for a fac object on creation. When a facility is suggested and when not created by its actual owner a stub page should be placed in the www field which could point at and provide an explanation as to why there is a stub page to begin with The benefit is avoiding confusion on who is responsible for the record once its suggested. And to avoid inputting inaccurate data. Typically, someone suggesting a FAC other than one of their own may inadvertently put their own or bogus data in the record creating a major inaccuracy. Ideally, when such a record as suggested FAC is claimed by its owner accurate information would then be entered.