Modification of EIP process to account for security treatments

bumblefudge · January 4, 2024, 11:36pm

I opened an issue on EIPIP about one possible way of publishing documents that update finalized documents modeled on how IETF RFCs do it:

github.com/ethcatherders/EIPIP

Call for Input: RFC-like back-references?

opened 02:05AM - 04 Jan 24 UTC

bumblefudge

Sorry I missed today's meeting! At previous meetings, I brought up offhand the a…nalogy to IETF RFCs, which are about as "immutable" as EIPs are once they get finalized, and yet still manage to get updated and/or superceded routinely _without modifying the updated or superceded RFCs_. They achieve this not in the finalized documents themselves (which are, bit-for-bit, immutable in a txt format), but by the rendering of them in the IETF "Datatracker" (equivalent of our EIP static site-generator pipeline, perhaps?). ## Exhibit A: How IETF RFCs handle this: This is what it looks like when you search for a superceded and/or updated RFC in datatracker: ![image](https://github.com/ethcatherders/EIPIP/assets/37127325/26f65628-7236-4293-82e2-e55f6b31dbc3) ([Src](https://datatracker.ietf.org/doc/search?name=2223&sort=&rfcs=on&activedrafts=on&by=group&group=)) And this is how it displays at the canonical permalink for a given RFC that has been updated and/or superceded: ![image](https://github.com/ethcatherders/EIPIP/assets/37127325/37e1027b-b3a9-48ad-9007-7e4dc5919635) ([Src](https://datatracker.ietf.org/doc/rfc2223/)) Future RFCs that update or supercede ("obsolete") a finalized one simply mark themselves as such in frontmatter like so: ![image](https://github.com/ethcatherders/EIPIP/assets/37127325/e9d3e89d-cc3b-41d7-a21b-2856871bad85) ([Src](https://raw.githubusercontent.com/ietf-tools/rfcxml-templates-and-schemas/main/draft-rfcxml-general-template-standard-00.xml), linked from [here](https://authors.ietf.org/templates-and-schemas)) These back-references get picked up by the datatracker database and show up whenever the older RFC is displayed by it. ## Exhibit B: How might the EIP process handle "updates" and full-blown supercessions? I think we could introduce a frontmatter field going forward (before the WG processes diverge too much?) like IETF has for `updates` and/or `obsoletes`/`supercedes`. Since we are using a static site generator (or perhaps some day soon, various different ones!) to re-render the entire corpus of EIPs each time a PR is merged, this could allow the same functionality, where the HTML page you see when you hit a permanent link could contain "Updated by"/"Superceded by" links the minute an updating or a superceding EIP gets accepted. Would this help mitigate the various discussions about how to update normative or semi-normative/substantive sections of final EIPs? It feels like the people trying to update final EIPs are quite underwhelmed by the recommended path of "just open a new one" since there's no _forward link_ to these new docs from the old ones...

It’s not a perfect solution but I think it might be enough for everyone to get what they want