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

[David Schinazi <[e-mail]>]

I would also be happy to help write text for this effort. I would imagine
keeping some hard rules in the RFC, like for example what is the role of
each of the bodies in the standard process. But the day-to-day minutiae can
move to GitHub. Ideally we'd have living documents for all of this, but we
can tilt at that particular windmill separately :-)
David

On Wed, Jul 10, 2024 at 7:41 AM Ron Bonica <[e-mail]> wrote:

> Brian,
>
> Thank you for victimteering. Since I cause this debacle, I will offer
> whatever help I can.
>
>
>       Ron
>
>
> Juniper Business Use Only
> ------------------------------
> *From:* Brian Rosen <[e-mail]>
> *Sent:* Wednesday, July 10, 2024 9:57 AM
> *To:* Rob Wilton (rwilton) <rwilton=[e-mail]>
> *Cc:* Brian E Carpenter <[e-mail]>; Rich Salz <
> [e-mail]>; Ron Bonica <[e-mail]>; [e-mail]
> <[e-mail]>; David Schinazi <[e-mail]>
> *Subject:* Re: [Gendispatch] Archival Dysfunction (was: Re: New Version
> Notification for draft-bonica-gendispatch-exp-00.txt)
>
>
> [External Email. Be cautious of content]
>
> I for one think this is a good idea, would work on it, and would volunteer
> to chair/shepherd/whatever it.
>
> 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 :)
>
> 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]
> To unsubscribe send an email to [e-mail]
>
>
>