Re: Limitations in RFC Errata mechanism

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



30.08.2011 22:09, Murray S. Kucherawy wrote:
-----Original Message-----
From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Mykyta Yevstifeyev
Sent: Tuesday, August 30, 2011 8:19 AM
To: IETF Discussion
Subject: Limitations in RFC Errata mechanism

First, we have only two types of errata - Technical or Editorial.  In presence of
<http://www.ietf.org/iesg/statement/rfc-metadata-errata.html>, "IESG
Statement on IESG Processing of RFC Errata concerning RFC Metadata", I
think the third type is necessary - Metadata.
I think given the current mechanism I would just submit such things under "Editorial".

This is an option; but doing so makes work of RFC Editor when incorporating metadata errata harder. If we have such thing as Metadata erratum type, and if such erratum gets verified, RFC Editor will be capable of noticing and acting quickly (I doubt RFC Editor pays much attention to Editorial errata when submitted/verified).


Second, the "Section" field at
<http://www.rfc-editor.org/errata_report.php>  implies that only
numerical sections will contain something an erratum can be reported
against (overlooking the GLOBAL option).  However, Appendices, Abstract,
Index, Author Info, different Notes exist, that aren't covered here.
I was able to type "Appendix A" just now into that section without difficulty.  The preview page shows "Section Appendix A says:", but that hardly seems a difficulty.

This limitation makes submitters find the way to put what they want in this field whose entity, I think, should be limited to digits and ".". This issue is probably of aesthetic importance.


Third, Original text and Corrected text fields imply that only
before-and-after errata may be submitted.  However, there might be
errata like Erratum # 6
(http://www.rfc-editor.org/errata_search.php?eid=6), with an only Report
text field.  I understand this feature was present in previous versions
of errata mechanism but removed from the current.
I don't understand the problem here.  That report seems pretty clear to me.

There used to be a "Text Report" option for submitting errata. This implied filling in the only field, not "Current Text" and "Corrected Text". Now it is unavailable, and this makes submitters write smth like this:

"Scope: GLOBAL"; "Current text: N/A"; "Corrected text: <what they want to say>"

and this results in a report saying that

"Throughout the document, when it says N/A, it should say <what submitter wanted to say>".

If the one-field errata existed, this would be:

"Scope: <not filled in>"; "Report Text: <what they want to say>"

and the erratum will look like:

"[For this document] the following erratum was reported: <what submitter wanted to say>".

(The scope-indicating field when submitting such errata should be made optional, BTW.)


Also, several issues not related to submission mechanism.

1) Specific mailing lists devoted to discussion of errata against RFCs
from different areas.  I've proposed this on rfc-interest list; see rationale at
<http://www.rfc-editor.org/pipermail/rfc-interest/2011-
August/002672.html>.;
Typically a working group discusses an erratum when it is raised, and then it sits in limbo until a document update occurs.  Isn't the right place for discussion about a particular one the mailing list of that working group or, if it's disbanded, the main IETF list?

Well, there are AD-sponsored Individual Submissions, which have no associated WG, and IAB, IRTF and Independent docs which IETF community might have a limited interest in. If we had the lists where errata for:

1. IETF Stream:
a. Apps Area;
b. Int Area;
c. Gen Area;
d. Ops Area;
e. RAI Area;
f. Rtg area;
g. Sec Area;
h. Tsv-Area
i. Legacy (published bu concluded areas);
j. Individual Submissions;
2. IAB Stream;
3. IRTF Stream;
4. Independent Submissions

folks who don't have ability or willing to join corresponding groups' lists will be capable of joining these lists.

Discussing errata on IETF Discussion list will increase our traffic and will soon bore many people who aren't particularly interested in a variety of topics errata are submitted on.


3) Verified technical errata may be incorporated in the references. Eg.
4 technical errata were reported against RFC 793 and verified; so the
reference may be:

Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.  Ammended by RFC Errata Reports 573, 1562, 1564, 1572.
I don't think verified errata have any force or effect until the document is actually updated, so this really just becomes clutter in the references.  Moreover, if I'm implementing some RFC that references another which itself has errata, I will want to know about all of them, not the ones that were present and verified at the time of publication.

Well, a reasonable argument. At Appendix A of draft-rfc-editor-errata-process-02 (http://tools.ietf.org/html/draft-rfc-editor-errata-process-02#appendix-A) I found a proposal from Brian Carpenter to point to errata list in the RFC itself, probably in Status of this Memo section. So this may be a solution.

Mykyta


-MSK
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]