[Rswg] Re: Is this a policy matter? (Was: Scope of new errata system)

[Stephen Farrell]

Hiya,

On 18/12/2024 11:11, "Mirja Kühlewind (IETF)" wrote:

Replying to this mail in this already quite long discussion as
Stephen noted more input from the stream managers would be good. I
think there was high level agreement between the stream managers but
of course details may differ, so here is my take.

For me there were two points of input I wanted to provide to the RPC
based on their initial proposal for a new errata system that they
shared with the stream managers as a starting point for discussion:

1) the proposal seemed to focus more on the general problem of how
to better support RFC readers. While this is something we could
potentially improve, I think we should a) not merge this together
with errata processing or at least focus on improving errata
handling first and maybe consider further improvement later, and b)
I think that is mostly a question for the IETF in the first place or
at least each streams directly and maybe less so for the whole RFC
series. What I mean is that yes it would be good to have one unified
way to support RFC readers however this is most important for
protocol standards and the technical expertise of the IETF is
clearly needed here, so it will interact in some way with other ietf
processes. For errata the problem is that we sometimes get reports
that go beyond just clear errata and require discussion or reaching
back. I think these are also often the cases that don’t get
processed because it’s not necessarily an errata in the sense of an
oversight when the doc was published but still there is something
clearly wrong. It is impossible to fully ensure that the reporter
will always get this right but I think we could improve the
situation by better tooling and we probably need a different process
to do something with these kind of reports that are basically not
errata. I think those things need to go back to the wg in some form
or if not present need some kind of consensus process to move beyond
the reported state. However telling these things apart from actually
straight forward errata is often the challenge.

IMO it is not sensible to focus on "improving errata first" - the
current system is so broken that setting that as a goal would only
lead to wasted effort and an outcome that cannot be significantly
better than the currently awful situation.

2) the second piece of feedback we/I gave was on tooling. I think we
all thought it might not be a good idea to get yet another own stand-
alone tool where we can have get another side discussion. The ietf
doesn’t have a lot of process requirement but we actually require
every wg to have mailing list. So that’s the smallest common
denominator that we could define process on that works for all
working groups. I don’t think requiring GitHub for all wg to process
errata will fly (yet). However I wouldn’t  want to stop any wg to
create a GitHub based errata process for their group. As an
organization I would also not want to bind our formal processes to
GitHub. Actually in this case of tooling I would encourage people
actually to think small and evolve over time. We know what we don’t
like about the current system (and having an entirely separate tool
I think it one if the points). I think we should start integrating
this into the datatracker both for the verifiers (ADs and stream
manager) as well as the reporters. And as this came up, I don’t
think this would require a datatracker login for the reporters but
we could e.g. at a manual inspection step if reported without login
or other difference in treating and handling the reported errata.

I'm not sure where the "requiring github" thing above comes from. I
didn't understand that to be part of anything proposed (and would be
against us getting that dependent on github).

The above also seems to ignore the fact that most RFCs do not map
to an active WG (or RG) and that that'll likely always be the case.
(That's also my main reaction to Colin's mail.)

Where there is an active WG/RG, of course their mailing list needs
to be involved at some point before an erratum is approved, but
that's the wrong thing on which to focus.

I hope that helps. I think I agree with a lot of things that have
been said in this discussion but again my main points are: let’s not
design another big stand-alone tool from scratch and let’s
concentrate on the things we know already needs changing (both
process and tooling wise) first rather then redesign everything at
once.

Based on how broken our current errata handing is, I reach the opposite
conclusion: we really need to throw it out and start from scratch.

Cheers,
S.

Mirja

Am 18.12.2024 um 00:39 schrieb Stephen Farrell
<stephen.farr...@cs.tcd.ie>:



On 17/12/2024 23:23, Brian E Carpenter wrote: So here are my
notes on the draft:

Thanks! Will incorporate tomorrow my time. (Note, I'm also fine if


S.

the process runs from Jean's list and not my I-D, but no harm updating the draft too along these lines.)

Rewrite the Abstract and the Introduction to say "this is the
new errata policy".

2. Policy versus Implementation

Some of the details below are provided via indirection, using
the [RPCTBD], reference.

I'd simply say that all technical details will be defined and
documented by the RPC.

The RPC are expected to consult with the community as changes
are considered.

Yes.

3. The New System

Once an RFC is published, then, on the datatracker web page
for viewing that RFC, there will be a "comment/discuss" button

Saying that it's on the datatracker is a technical detail - and
in any case, the button must also be on the RFC Editor's info
page (where the errata button is today). Altogether there are
too many details here (and no mention of moderation apart from
the spam comment in Section 2). Requiring a DT login is a big
move. I think we need to discuss that.

Discussion threads are expected to be re-directed to an IETF
mailing list as warranted.

That needs to be streamized. Something like Each RFC stream must
define its own procedure; for example, discussion threads on
IETF stream documents are expected to be redirected to an IETF
mailing list as warranted, but that decision would be made by
the IETF, not by the RFC Editor. By default, old documents not
assigned to a particular stream will be treated as if they were
IETF stream, unless another stream manager claims them.
[Comment: a lot of legacy Informationals would naturally be
Independent Stream today.]

Comments labelled as errata can be upvoted or downvoted.
Voting power...

I don't like this bit. It looks like an end-run around rough
consensus. I tend to think this whole part should be delegated
to the streams anyway. Certainly there are too many details.

The default HTML view of RFCs will be that with errata
applied.

But what does that mean? What about everyone who's downloaded
the original RFC? What about the copy that ChatGTP holds? I
fully agree that a rendering with errata applied should be
available, with and without diffs displayed. But saying it's the
default doesn't seem like a well- defined concept to me.

4. Handing existing errata

...

No action is required with respect to current, posted but
unprocessed, errata.

I disagree. The current load of unprocessed errata is the
biggest issue that we have, and I think they need to be force-
fed to the new system. Regards Brian

On 18-Dec-24 10:27, Stephen Farrell wrote:

Hiya,

On 17/12/2024 20:44, Brian E Carpenter wrote:

Eliot, I would love some technical team to work out the
details of an improved errata system this afternoon, but
there are policy questions and I think they need to be
distilled out of the draft and made into a two page document
that we could rapidly send to the RSAB.

deferring to the RPC for details.


an implementation. Or that could be done after it was adopted
somewhere.

Cheers, S.

[1] https://www.ietf.org/archive/id/draft-farrell-
errata-00.html

If you'd like to suggest changes to [1] to go more in that direction, that'd be fine. From my POV, [1] already almost does that already, by only setting high level direction and I'd be happy to refresh the draft with such changes, e.g. to cast the more descriptive stuff as an example of what could be

Regards Brian

On 18-Dec-24 06:37, Eliot Lear wrote:

I certainly don't want *any* draft sequenced or held up or
anything. And so a *big fat plus 1* for adopting draft-
farrell-errata.

Onward!

Eliot

On 17.12.2024 18:16, Paul Hoffman wrote:

Yep, we like talking about things that can be improved
with the RFC series. The (thankfully short) WG charter
says:

The RFC Series Working Group (RSWG) is the primary venue
in which members of the community collaborate regarding
the policies that govern the RFC Series.

There was a thread started by the WG chairs on
2024-10-30, but never concluded, about what is policy
and what is operations. Most of the comments on this


I propose that the WG chairs definitively close out the
"Operational vs. policy" thread so that the WG can move
forward on the many drafts we already have. If the
conclusion of that thread makes it clear that errata

propose that Someone create a mailing list to discuss
errata operations and this discussion move there.

--Paul Hoffman

errata thread are about operations of the errata process, not the policy for how errata apply to RFCs. operations is in scope for this WG, I propose the WG officially adopt draft-farrell-errata; otherwise, I

-- rswg mailing list -- rswg@rfc-editor.org To unsubscribe send an
email to rswg-le...@rfc-editor.org <OpenPGP_signature.asc>

OpenPGP_signature.asc
Description: OpenPGP digital signature

-- 
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org