[Gendispatch] Re: Archival Dysfunction (was: Re: New Version Notification for draft-bonica-gendispatch-exp-00.txt)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi,

I think that there are a few useful gen area documents that could do with being updated.  I think that we should be considering trying to consider how to improve the IETF’s documentation for folks in general and particularly for newcomers and to make it easier to update and maintain.  The LLC is, I think, already doing lots of this, e.g., the pages to help with authoring.

I would like to see RFC 2026 updated, with all the various updates over time folded into it, and then if possible, pared down to the really core parts of the IETF standardization process.  All other more detailed documentation related to IETF processes, that is changed by the community or the IESG over time, should, IMO, be documented on github backed webpages with identified ownership (e.g., IESG owned, LLC owned, community owned) with an appropriate review/approval process for community owned changes.  E.g., if on github, along the lines of doing a 4 (or 2 weeks if backed by a WG) IETF LC on the github pull request, and then IESG ballots like any other document.  If the IESG approves, then the PR gets merged and published.

The IESG statements should just be an update to the IESG managed parts of the standards process, with the webpages updated, when the IESG statement is sent out.  Presumably the iESG statement would just summarize what has changed and point at the webpages describing the current process.

If others are interested in pursuing this broader goal (even if they don’t agree with the rough process that I’ve outlined above), then perhaps we should try and have a side meeting at IETF 120 (or we could do a virtual meeting after IETF 120, if that was likely to work better), perhaps with an idea of seeing if we could a BOF at IETF 121, or float a proposal to the IESG or some ADs sympathetic to the idea, probably with the goal of setting up a WG.

I appreciate that some of this has been tried before (and presumably didn’t completely succeed), and I also appreciate the madness of repeatedly trying the same thing and expecting a different outcome.  But at the same time, just because something didn’t succeed previously, doesn’t mean that we wouldn’t be able to reach a successful outcome this time.  Lots of things have moved on over the last X years, opinions change, different folks are involved in the process, etc.

Regards,
Rob



From: Brian E Carpenter <[e-mail]>
Date: Tuesday, 9 July 2024 at 22:50
To: Salz, Rich <[e-mail]>, Ron Bonica <[e-mail]>, [e-mail] <[e-mail]>
Subject: [Gendispatch] Re: Archival Dysfunction (was: Re: New Version Notification for draft-bonica-gendispatch-exp-00.txt)
Rich,

On 10-Jul-24 02:09, Salz, Rich wrote:
> So we are left with the following options:
>
> ·Publish non-foundational information in the RFC series (a suboptimal solution)
>
> ·Discard non-foundational information (a worse solution)
>
> Other options:
>
>                  IETF blog post
>
>                  IESG statement
>
>                  IETF web page, managed by the staff

Yes, but only IESG Statements seem to be treated as archived material that can be found for ever. Again, that's exactly why the ION experiment was proposed in RFC4693, and exactly why it's ironic that the IESG's explanation of the outcome of that experiment was lost from the IETF web site sometime after April 22, 2023 (which was the last date when archive.org found it).

I think the idea behind RFC4693 was fundamentally sound: if we don't treat this class of material as a formal series with archival properties, there will be information loss.

    Brian


--
Gendispatch mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]