Call For Input: Remove Networking and Interface categories (ethereum/EIPs#7665)

[Pandapip1]

Decision	Get rid of the networking and interface categories
Method	Rough Consensus
Deadline	2023-10-05

[Pandapip1]

I vote yes.

[Pandapip1]

The markdown, for anyone else wanting to make CFIs:

<table>
    <tr>
        <th>Decision</th>
        <td>Merge ethereum/EIPs#7665</td>
    </tr>
    <tr>
        <th>Method</th>
        <td>Rough Consensus</td>
    </tr>
    <tr>
        <th>Deadline</th>
        <td>2023-10-05</td>
    </tr>
</table>

[SamWilsn]

I don't think we should make any changes to existing EIPs (except the already planned EIP/ERC split) until we have the working group situation sorted.

[Pandapip1]

I don't think we should make any changes to existing EIPs (except the already planned EIP/ERC split) until we have the working group situation sorted.

That's kinda what I'm trying to do with this. This is basically a transfer of all Networking EIPs to the Core working group to eliminate the need to create a Networking WG and speed this process up.

[timbeiko]

That's kinda what I'm trying to do with this. This is basically a transfer of all Networking EIPs to the Core working group to eliminate the need to create a Networking WG and speed this process up.

Agreed that for the purposes of the ERC/EIP split, everything that's currently in the Networking category should fall into the EIP bucket.

[g11tech]

+1

[g11tech]

as a policy we should anyway move away from categorization towards tagging (i.e. multiple tags can be associated with it)

[Pandapip1]

as a policy we should anyway move away from categorization towards tagging (i.e. multiple tags can be associated with it)

Agreed, but out of scope. This PR only helps this happen.

[poojaranjan]

To be clear, is the proposal to remove "Standard Track - Interface" and "Standard Track - Networking" and have them added to "Standard Track - Core"?

And we will be left with

Github Repo	Type	Category
EIPs	Meta	-
EIPs	Standard Track	Core
EIPs	Informational	-
ERCs	Standard Track	ERC

I think it will be so much easier to refer to when we dissolve "Standard Track" altogether. I wonder, what people think of having "Category" be added to "Type"?

eg.

Github Repo	Type
EIPs	Meta
EIPs	Core
EIPs	Informational
ERCs	ERC

[Pandapip1]

To be clear, is the proposal to remove "Standard Track - Interface" and "Standard Track - Networking" and have them added to "Standard Track - Core"?

No. Most Interface EIPs are moved to ERC, the rest to Core. I do support making Core and ERC their own types, but that requires modifying every EIP, which I don't want to do.

[poojaranjan]

Most Interface EIPs are moved to ERC, the rest to Core.

Sorry, if I missed this conversation earlier, when the repos will be split, out of Interface (49 EIPs) some will be going to be added to ERC and the rest to Core.

How is that being decided? Is there any list that people may follow?

I do support making Core and ERC their own types, but that requires modifying every EIP, which I don't want to do.

I understand. We can perhaps collect what other editors think. If there is a "rough consensus" and a volunteer to reflect the changes, it can be pursued. Glad to know the idea isn't too bad.

[Pandapip1]

How is that being decided? Is there any list that people may follow?

The definitions for Core and ERC are changed in the PR. If people object to the definitions or and any of my interpretations of my definitions (there are a few EIPs in a gray area), please let me know!

[poojaranjan]

After giving some thought, IMO, moving any Final EIP to "Core", may disrupt the understanding of "Core" EIPs.

Historically, Core EIPs have been deployed on a hard/softfork. IIRC, except EIP-2681: Limit account nonce to 2^64-1 and EIP-3607: Reject transactions from senders with deployed code rest all Final "Core" EIPs have been deployed on one of the network upgrades.

Adding non-core Final EIPs to the list of Core Final may create a bit of confusion.

Is there a possibility that we leave the Interface & Networking categories EIPs where they are and not add any further EIPs? This will not only kill the need of the respective working groups but also create a guideline for future EIPs to be added as "Core" and be deployed to a future network upgrade.

[Pandapip1]

Is there a possibility that we leave the Interface & Networking categories EIPs where they are and not add any further EIPs? This will not only kill the need of the respective working groups but also create a guideline for future EIPs to be added as "Core" and be deployed to a future network upgrade.

See my comment. We can't leave them where they are, and process-wise I would be okay with moving most of the Interface->Core EIPs to ERC (although the ones that change opcode names should remain Core, since they were included in hard forks).

[lightclient]

We can't leave them where they are We absolutely can and should. There is no need change anything about the existing EIPs. We can leave them and simply not allow new ones or further updates to existing ones.

I'm against this and I have said my reasoning clearly in https://github.com/ethereum/EIPs/pull/7665

[SamWilsn]

Roughly, from @gcolvin:

Leave networking as is. That's how they were categorized at the time, and there's no reason to change them.

[g11tech]

+1

as per discussion, we can delay this and figure it out later if relevant, i.e. let old stuff be there

[poojaranjan]

The proposal is being closed in favor of NOT removing - "let old stuff be there".