Deprecate Network Type Field

[martinhannigan]

Is your feature request related to a problem? Please describe.

In multiple discussions (see 1357 for example [https://github.com//issues/1357] ) it's difficult to agree on just what should be in the Network Type field. We do seem to agree it's out of date. We don't seem to agree what the update is.

Note: I volunteered to shepherd the overall issue and proposing an additional option which I separated from the initial issue in 1357 for clarity sake.

Who is affected by the problem?

Users of PDB

What is the impact?

Negligible. The out of date descriptions have been in place for quite some time.

Are there security concerns?

No

Are there privacy concerns?

No

Describe the solution you'd like

Deprecate Network Type.

Do you think this feature will require a formal design?

No.

Describe alternatives you've considered

Updating the types. Unlikely consensus on a solution. Supports being out of date.

Doing nothing. This is bad for PDB. Being modern and relevant is good.

Deprecating the field. Eliminates stale and less-useful data from the database. Improves clarity.

Could this feature request need support from the Admin Committee?

No.

What is the proposed priority?

Not urgent.

Provide a rationale for any/all of the above

It's old. Users have complained about it. Many have proposed solutions, so much so it indicates a lack of clarity of why it's needed. I suggest we close 1357 and deprecate the field entirely.

Additional context

Nothing to add.

[arnoldnipper]

-1 as we only recently introduced additional network types (Route Server, Network Services, Government, ...). Network types help to single out peers. If there are types which are irrelevant nowadays, we should find new categories and migrate existing types.

[martinhannigan]

+1

[martinhannigan]

@peeringdb/pc FYI

[peterhelmenstine]

-1 If 98% of users are using it then I think we should keep the field

[martinhannigan]

I would venture an educated guess that 98% of users are “using” it because it’s number 5 on the entry list of fields for new networks and “use” is mostly just filling it in – because it’s there. If that field were gone, what would happen? To help those who didn’t go look at the drop downs: * NSP * Content * Cable/DSL/ISP * Education/Research * Non-Profit * Route Server * Network Services * Route Collector * Government Can’t quite put my finger on how to improve documentation for a “Government” network versus a “non-profit” network or why they matter any more or less than a “Cable/DSL/ISP”. All seem to easily fall into the bucket of “network operator” which for most seems to be understood. I didn’t know a route server had it’s own network, I thought they were just hosts on the fabric. Same for collector. Hope that helps. Warm regards,

…

-M< From: Peter Helmenstine ***@***.***> Date: Tuesday, April 25, 2023 at 2:21 AM To: peeringdb/peeringdb ***@***.***> Cc: Martin Hannigan ***@***.***>, Assign ***@***.***> Subject: Re: [peeringdb/peeringdb] Deprecate Network Type Field (Issue #1379)

-1 If 98% of users are using it then I think we should keep the field — Reply to this email directly, view it on GitHub<#1379 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFA2YQR2IIGA25SMDOQM3OTXC5UNTANCNFSM6AAAAAAXIUEVWM>. You are receiving this because you were assigned.Message ID: ***@***.***>

[mcmanuss8]

I think we could benefit from talking to the community more about this field. Recently at $day_job I found someone keying off of this field to make decisions about what kind of network the ASN was, but given how we've seen confusion about which value to pick, I'm not confident that's ideal.

What I'd like to hear from folks out there is:

• Who is consuming this field and for what purposes? Do they find it helpful/valuable or no? Do they find it's mostly accurate?
• When setting this field, are people happy with the options presented to them? Do they want more nuance or a coarser definition?

[martinhannigan]

On Tue, Apr 25, 2023 at 10:41 AM mcmanuss8 ***@***.***> wrote: I think we could benefit from talking to the community more about this field. Recently at $day_job I found someone keying off of this field to make decisions about what kind of network the ASN was, but given how we've seen confusion about which value to pick, I'm not confident that's ideal.

I can only add my personal experience: What I'd like to hear from folks out there is:

- Who is consuming this field and for what purposes? Do they find it helpful/valuable or no? Do they find it's mostly accurate?

I never used it for anything across three extremely deeply interconnected ASN’s I was employed by. I don’t recall ever looking at it. I used the advanced search tool to search on some of the types. It seems clear to me that there are pros and cons for a lot of ASN’s to have made their choice, but the lack of a clear definition has made it a little “smirky” in interpretation.

- - When setting this field, are people happy with the options presented to them? Do they want more nuance or a coarser definition?

I can’t think of a scenario where I would be concerned. If we didn’t deprecate, which I would prefer for simplicity sake and regaining the screen real estate, I could see us generalizing (reducing) the buckets, but not expanding. Can’t think of any automation use case that would make sense valuing this field in an interconnection decision. The value is the traffic and from my perches I always knew where/what/who and ascertained value from flows and value to determine if an ASN was a suitable peer or not. Seems like that’s underscored with most SFI questions (and ratios - 1 left? Probably more. Who cares?) being solved these days - at least for the ASN’s who should be. Hope that helps,

…

-M<

[peterhelmenstine]

Until we know what others are using it for I think it needs to stay because all we know is they're using it now for something or they wouldn't have used it in the first place.

[martinhannigan]

I'm +1 here. @peeringdb/pc please vote so we can get it off the docket at our next call. Thanks!

[arnoldnipper]

Still -1 ... which still totals to a -1

[peterhelmenstine]

Suggest table until the survey results come in.

[martinhannigan]

We should decide if thats needed on our next call. Doesn't look like it. Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Peter Helmenstine ***@***.***> Sent: Sunday, June 18, 2023 4:15:27 PM To: peeringdb/peeringdb ***@***.***> Cc: Martin Hannigan ***@***.***>; Assign ***@***.***> Subject: Re: [peeringdb/peeringdb] Deprecate Network Type Field (Issue #1379) Suggest table until the survey results come in. — Reply to this email directly, view it on GitHub<#1379 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFA2YQSAMLCTYPE6WDDXOYTXL5OV7ANCNFSM6AAAAAAXIUEVWM>. You are receiving this because you were assigned.Message ID: ***@***.***>

[arnoldnipper]

We should decide if thats needed on our next call. Doesn't look like it.

Exactly, this issue isn't needed. I can only come to teh conclusion that the Network Type Field should stay. Look at the survey results (140 by now)

• a majority is using the Network Type field when making decisions
• 2/3 belief the values are accurate
• 3/4 belief that the currently available options are useful

Users have spoken. We should follow. If we like or not,

[martinhannigan]

At the PC meeting of 7/6/2023 the PC agreed to close this issue. A survey was completed which indicated interest in keeping the field. Shift over to Issue #1357 if you want to participate in it's journey forward.