So here are my notes on the draft:
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
