On 18 Dec 2024, at 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.
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’d also add that we discussed that several groups have
“implementors” mailing lists, Slack channels, GitHub, etc., that are
clearly useful for people reading and implementing the RFCs, somewhat
separately to the forums people writing the RFCs use.
From my point of view, better surfacing the existing implementors
forums that WGs provide, encouraging similar activities in those groups
that don’t have them, and making it easier for implementers to engage
with the working groups, whether via the WG lists or via other means,
seems better than having the RFC Editor develop a system that would be
somewhat disconnected from the rest of the process.
Colin
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.
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 the process runs from Jean's list and not my I-D, but no harm
updating the draft too along these lines.)
S.
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.
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 deferring to the RPC for details.
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 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
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 errata thread are about operations of the
errata
process, not the policy for how errata apply to RFCs.
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 operations is in scope for this WG, I propose the WG
officially adopt draft-farrell-errata; otherwise, I propose that
Someone create a mailing list to discuss errata operations and
this
discussion move there.
--Paul Hoffman
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
<OpenPGP_signature.asc>
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
