Re: Limitations in RFC Errata mechanism
On 2011-08-31 06:05, Mykyta Yevstifeyev wrote: ... 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. ... Status of this Memo already has a link to http://www.rfc-editor.org/info/rfc. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Limitations in RFC Errata mechanism
31.08.2011 8:09, Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mykyta Yevstifeyev Sent: Tuesday, August 30, 2011 9:05 PM To: ietf@ietf.org Subject: Re: Limitations in RFC Errata mechanism 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). I'm sure the RFC Editor appreciates people in the IETF trying to make their work easier, but since so far they haven't complained about this in particular, I'm not sure it's something that actually needs fixing. Usually, when metadata erratum is reported, and some AD verifies it, this AD is to report this change to RFC Editor manually, despite the fact the verification notification is cc'ed to rfc-edi...@rfc-editor.org; also note that processing such errata may take additional time because the whole IESG may be necessary to be consulted, and so on. At least one step of this process may be simplified simply. 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. As a submitter, I didn't find typing Appendix A into that box and decoding the output to be at all inconvenient. It may not be perfect, but it's not terribly broken either. So this, as already mentioned, is an aesthetic question. However, Section TOC or Section Appendix A don't look nice. 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: [...] I still don't see this as evidence that we need to have a forum specifically for discussing errata. I would have to subscribe to that list just in case there's ever any erratum opened for an RFC that interests me, and deal with the (possibly huge) amount of traffic that is not of interest. It seems to me that ietf@ietf.org is just fine for this purpose, and most of us already are on that one. I didn't see, for instance, any errata report against apps-related RFCs coming to apps-discuss list. This would only happen if such RFC was produced is appsawg WG. I didn't notice errata reports on genarea RFCs coming on IETF Discussion list, which would be logical. There may be more examples. Else, errata system should be configured to copy all notifications to specific area lists, which exists in all areas, which it currently isn't. I also haven't seen any demand prior to this for a special forum where errata are discussed, separate from the list(s) we already have. 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. As far as I can tell, that's where this happens now, and I don't see it being much of a burden. Have we ever seen any errata coming on IETF Discussion? Mykyta Yevstifeyev I could be wrong, but I don't see much evidence that any of this stuff is broken enough to warrant a bunch of form changes, new mailing lists, or other new infrastructure. If it ain't broke, don't fix it. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Limitations in RFC Errata mechanism
31.08.2011 10:42, Julian Reschke wrote: On 2011-08-31 06:05, Mykyta Yevstifeyev wrote: ... 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. ... Status of this Memo already has a link to http://www.rfc-editor.org/info/rfc. Yes, this slipped my mind. Thanks. Mykyta Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Limitations in RFC Errata mechanism
Hello all, I've observed several problems with submission mechanism for RFC Errata. Here they are: 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. 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. 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. So, taking this into consideration, some specific proposals: 1) Additional Metedata erratum type. The fields which will be required to be filled in are: (a) metadata type: document source, RFC number, subseries*, obsoletes header*, updates header*, obsoleted-by header*, updated-by header*, category, (b) current value, and (c) correct value. Values marked under * in (a) may be available in the case when such metainfo is present in the RFC. 2) Replace the Section field with the drop-down list containing the following options: Section, Appendix, Abstract, Table of Contents, Note, Author information, Index. In the case of the first two an additional field for number is available; in the case with Note - type of Note (RFC Editor, IESG etc.). 3) Allow user to choose whether they will enter old_text-new_text erratum or single_text erratum. 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.; 2) Users might want to submit comments which could be displayable at erratum's page, similar to the mechanim employed by some IETF WGs in issue trackers. This also includes ability to add myself to cc list. 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. So, further discussion is welcome... Mykyta Yevstifeyev ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Limitations in RFC Errata mechanism
On 8/30/2011 11:19 AM, Mykyta Yevstifeyev wrote: Hello all, I've observed several problems with submission mechanism for RFC Errata. Here they are: 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 agree with this part of the proposal, at least. -- Wes Eddy MTI Systems ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Limitations in RFC Errata mechanism
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] 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. 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. 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. 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? 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. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Limitations in RFC Errata mechanism
30.08.2011 22:09, Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] 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
RE: Limitations in RFC Errata mechanism
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mykyta Yevstifeyev Sent: Tuesday, August 30, 2011 9:05 PM To: ietf@ietf.org Subject: Re: Limitations in RFC Errata mechanism 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). I'm sure the RFC Editor appreciates people in the IETF trying to make their work easier, but since so far they haven't complained about this in particular, I'm not sure it's something that actually needs fixing. 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. As a submitter, I didn't find typing Appendix A into that box and decoding the output to be at all inconvenient. It may not be perfect, but it's not terribly broken either. 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: [...] I still don't see this as evidence that we need to have a forum specifically for discussing errata. I would have to subscribe to that list just in case there's ever any erratum opened for an RFC that interests me, and deal with the (possibly huge) amount of traffic that is not of interest. It seems to me that ietf@ietf.org is just fine for this purpose, and most of us already are on that one. I also haven't seen any demand prior to this for a special forum where errata are discussed, separate from the list(s) we already have. 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. As far as I can tell, that's where this happens now, and I don't see it being much of a burden. I could be wrong, but I don't see much evidence that any of this stuff is broken enough to warrant a bunch of form changes, new mailing lists, or other new infrastructure. If it ain't broke, don't fix it. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
