[Gendispatch] Re: Archival Dysfunction

[Brian E Carpenter <[e-mail]>]

On 11-Jul-24 01:57, Brian Rosen wrote:
> I for one think this is a good idea, would work on it, and would volunteer to chair/shepherd/whatever it.

Thank you.

> 
> I won’t be at IETF120, but could join via Meetecho.  I do think a virtual meeting is a good idea, think of it as a virtual BoF.
> 
> I do think enough has changed that we could make it work this time.
> 
> I pose the following amusing question:
> 
> Suppose we did what you propose, and write an RFC that updates 2026 and friends.  Would we want to have that RFC be a self-executing end-of-using-RFCs-for-process RFC?  Or would we ever anticipate an RFC that updated the RFC-to-be that we produce from this effort :)

Seriously, I'd expect rfc2026bis to state which type of process documents would need to be BCPs and which would just be operational notes.

     Brian C

> 
> Brian
> 
> 
>> On Jul 10, 2024, at 8:44 AM, Rob Wilton (rwilton) <rwilton=[e-mail]> wrote:
>>
>> 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]
>> --
>> Gendispatch mailing list [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email [e-mail] <mailto:[e-mail]>
>