Re: RFC Errata: when to file, and when not to
- Original Message - From: Alessandro Vesely ves...@tana.it To: ietf@ietf.org Sent: Wednesday, August 08, 2012 6:09 PM On Tue 07/Aug/2012 15:20:35 +0200 t.p. wrote: From: Yoav Nir y...@checkpoint.com Would it make it easier to find if they were called notes or corrections instead of errata? Yes, corrections is what I see published in a newspaper to correct errata in previous editions. So far, it is the best word I can think of (but there might be a better one:-). Errata is an abbreviation of errata corrige, the Latin for error correction. Switching to the English translation would seem to be consistent with English being the official publication language for RFCs. In the html version of an RFC, it would be easy to provide old and new in an easy to compare format (as some editors do for I-D), not perhaps on permanent display but shown when 'errata' (or whatever name we choose) is toggled. Although easy, doing that would require a noticeable amount of editorial work. In addition, notes, reasons, and explanations don't have an obvious graphical rendition. IMHO, knowing when and why an errata was proposed and verified is an integral part of it. Well, start simple and build on it, something the tools team have a history of doing:-) First, have only the one highlighted 'corrections made' field on the html page. Second, add a new link to a 'corrections help' page telling the viewer that once issued, a RFC is never changed, that any changes require a fresh RFC that updates or supersedes the original one (pointing to the highlighted fields in the top right hand example, perhaps with a worked example - but not SMTP:-( but that there is an 'erratum' mechanism for correcting editorial errors or places where the text is or may not be clear about the intentions of the editors; and that such errata can be viewed by clicking on the 'corrections made' field. Finally, change the 'corrections made' to a 'hide corrections/view corrections' toggle, default the first setting, the second setting showing OLD/NEW text, old recognisably different eg struck through, with a link to the RFC Editor page for the erratum; this is only done for errata that are accepted. Yes, there would be some intricate errata that this would not cover, but the screens you get currently by following the link to the RFC Editor page are so arcane as to switch off all but those intimately involved in this standards process. Tom Petch
Re: RFC Errata: when to file, and when not to
Does anyone other than historians honestly care what the original was? I mean, really? Dave.
Re: RFC Errata: when to file, and when not to
--On Thursday, August 09, 2012 09:27 +0100 Dave Cridland d...@cridland.net wrote: Does anyone other than historians honestly care what the original was? I mean, really? Dave, RFCs are often incorporated by reference in procurement documents and conformity requirements. If one were trying to interpret or enforce such a requirement, it would almost certainly be useful to know _exactly_ what version of an RFC and its interpretations was agreed to. john
Re: RFC Errata: when to file, and when not to
It seems entirely reasonable that there needs to be a version available that's precisely as-published, for legal (and quasi-legal) reasons, as you say - however, that's the version produced by the RFC Editor, and not the tools version (which is already non-normative, technically, due to the markup). What I'm driving at is whether the right way to handle errata is by changing the document on tools (perhaps by diff submission). This should reduce the mechanical workload of errata handling to near-zero, and leave the judgement calls of whether to accept them as the cost.
Re: RFC Errata: when to file, and when not to
On Aug 9, 2012, at 2:35 PM, Dave Cridland wrote: It seems entirely reasonable that there needs to be a version available that's precisely as-published, for legal (and quasi-legal) reasons, as you say - however, that's the version produced by the RFC Editor, and not the tools version (which is already non-normative, technically, due to the markup). What I'm driving at is whether the right way to handle errata is by changing the document on tools (perhaps by diff submission). This should reduce the mechanical workload of errata handling to near-zero, and leave the judgement calls of whether to accept them as the cost. This means that there would be two documents with the same RFC number. The quasi-leagal as published one, and the one of the tools site. Which should I follow when I go to implement? If the errors amount to something that would really make a difference in implementation, you really need a new RFC, and can't handle this in an erratum. See for example RFC 4753. The erratum changed bits on the wire, so a replacement RFC (5903) had to be published. RFC 5903 also has two errata, which were rejected. But they are editorial, so even had they been accepted, they would not require a new RFC.
Re: RFC Errata: when to file, and when not to
--On Thursday, August 09, 2012 14:53 +0300 Yoav Nir y...@checkpoint.com wrote: This means that there would be two documents with the same RFC number. The quasi-leagal as published one, and the one of the tools site. Which should I follow when I go to implement? Exactly If the errors amount to something that would really make a difference in implementation, you really need a new RFC, and can't handle this in an erratum. See for example RFC 4753. The erratum changed bits on the wire, so a replacement RFC (5903) had to be published. And, if I correctly understood it at the time, that is exactly why the RFC Editor opposed the idea of formal errata for years. If there were real, substantive, errors, a replacement RFC should be published as soon as practical. For anything else, the most that was desirable would be a collected list of comments and suggestions that could be considered if/when the document was revised. john
Re: RFC Errata: when to file, and when not to
On Aug 9, 2012, at 3:34 PM, John C Klensin wrote: --On Thursday, August 09, 2012 14:53 +0300 Yoav Nir y...@checkpoint.com wrote: This means that there would be two documents with the same RFC number. The quasi-leagal as published one, and the one of the tools site. Which should I follow when I go to implement? Exactly If the errors amount to something that would really make a difference in implementation, you really need a new RFC, and can't handle this in an erratum. See for example RFC 4753. The erratum changed bits on the wire, so a replacement RFC (5903) had to be published. And, if I correctly understood it at the time, that is exactly why the RFC Editor opposed the idea of formal errata for years. If there were real, substantive, errors, a replacement RFC should be published as soon as practical. For anything else, the most that was desirable would be a collected list of comments and suggestions that could be considered if/when the document was revised. There are still the spelling mistakes and obvious errors. Take for example this one from RFC 5296: The EMSKname is in the username part of the NAI and is encoded in hexadecimal values. The EMSKname is 64 bits in length and so the username portion takes up 128 octets. Encoding 64 bits in hex requires 16 octets, not 128. I think anyone implementing this would figure this out, but it is substantive. The RFC was being revised anyway, but do you think a replacement RFC would need to be published if that were not the case? Yoav
Re: RFC Errata: when to file, and when not to
--On Thursday, August 09, 2012 17:11 +0300 Yoav Nir y...@checkpoint.com wrote: And, if I correctly understood it at the time, that is exactly why the RFC Editor opposed the idea of formal errata for years. If there were real, substantive, errors, a replacement RFC should be published as soon as practical. For anything else, the most that was desirable would be a collected list of comments and suggestions that could be considered if/when the document was revised. There are still the spelling mistakes and obvious errors. Take for example this one from RFC 5296: The EMSKname is in the username part of the NAI and is encoded inhexadecimal values. The EMSKname is 64 bits in length and so the username portion takes up 128 octets. Encoding 64 bits in hex requires 16 octets, not 128. I think anyone implementing this would figure this out, but it is substantive. The RFC was being revised anyway, but do you think a replacement RFC would need to be published if that were not the case? Personal opinion: I don't know about need to be, but replacing an RFC with an error of that type would be desirable to avoid any possible misunderstanding, however unlikely. IMO, it would also be desirable to have some self-examination in the community about why that error slipped past IETF Last Call, AD reviews, and AUTH48). john
RE: RFC Errata: when to file, and when not to
From: Dave Cridland [d...@cridland.net] Does anyone other than historians honestly care what the original was? Does anyone honestly care what last month's version of the source code was? Dale
Re: RFC Errata: when to file, and when not to
Lawyers may, in both cases. Stephan On 8.9.2012 09:45 , Worley, Dale R (Dale) dwor...@avaya.com wrote: From: Dave Cridland [d...@cridland.net] Does anyone other than historians honestly care what the original was? Does anyone honestly care what last month's version of the source code was? Dale
Re: RFC Errata: when to file, and when not to
On Tue 07/Aug/2012 15:20:35 +0200 t.p. wrote: From: Yoav Nir y...@checkpoint.com Would it make it easier to find if they were called notes or corrections instead of errata? Yes, corrections is what I see published in a newspaper to correct errata in previous editions. So far, it is the best word I can think of (but there might be a better one:-). Errata is an abbreviation of errata corrige, the Latin for error correction. Switching to the English translation would seem to be consistent with English being the official publication language for RFCs. In the html version of an RFC, it would be easy to provide old and new in an easy to compare format (as some editors do for I-D), not perhaps on permanent display but shown when 'errata' (or whatever name we choose) is toggled. Although easy, doing that would require a noticeable amount of editorial work. In addition, notes, reasons, and explanations don't have an obvious graphical rendition. IMHO, knowing when and why an errata was proposed and verified is an integral part of it.
Re: RFC Errata: when to file, and when not to
Original Message - From: Alessandro Vesely ves...@tana.it To: ietf@ietf.org Sent: Friday, August 03, 2012 4:19 PM On Thu 02/Aug/2012 03:28:38 -0700 Martin J. Dürst wrote: In particular, the errata system is NOT meant to be used as an issue tracker; Of course we have mailing lists, issue trackers, and wikis, but the problem is that none of them are for RFCs. In addition, those tools seem to be intended rather for IETF internal use than for general public. The question then comes up on whether we can do better. And my guess is that in this day and age of linked information, we should be able to do better. With the tools version of an RFC, which is quickly becoming the preferred version of many, it's already easy to find errata. It is /not difficult/ to find errata. Easy would mean that people usually find them even if they're not purposely looking for them. For example, the existence of an approved errata could be signaled by coloring the margin near the relevant text. tp When I Google RFC, I am sometimes directed to www.ietf.org, which is not much help here. Other times, I am directed to tools.ietf.org, whose format I find less friendly but which does have 'errata exist' in the top right hand corner. However, I cannot click on that, unlike the Obsoletes and Updates fields; but, more importantly, would your average not-involved-in-standards audience know what errata are? For me, the word comes from a classical education, before ever I got involved with standards, and so is a commonplace, but is it used in the world at large? I suspect not. Tom Petch /tp
Re: RFC Errata: when to file, and when not to
On Aug 7, 2012, at 11:29 AM, t.p. wrote: When I Google RFC, I am sometimes directed to www.ietf.org, which is not much help here. Other times, I am directed to tools.ietf.org, whose format I find less friendly but which does have 'errata exist' in the top right hand corner. However, I cannot click on that, No, but two lines above it, there's an Errata link, which you can click. unlike the Obsoletes and Updates fields; but, more importantly, would your average not-involved-in-standards audience know what errata are? For me, the word comes from a classical education, before ever I got involved with standards, and so is a commonplace, but is it used in the world at large? I suspect not. Probably not, and neither is bis. But what can you do about this? It's either allow updating of RFCs after publication, or have a list or corrections. Would it make it easier to find if they were called notes or corrections instead of errata? Yoav
Re: RFC Errata: when to file, and when not to
On Fri 03/Aug/2012 08:38:44 -0700 Barry Leiba wrote: Easy would mean that people usually find them even if they're not purposely looking for them. For example, the existence of an approved errata could be signaled by coloring the margin near the relevant text. I like this idea. Not colour, maybe -- despite the errata tool's format, not all errata nicely fit into OLD/NEW text, and one often needs the explanation even for those that do -- but perhaps an errata icon in the margin next to the relevant text. One could click the icon and be sent straight to that erratum. The trouble is that I can't see how we could do that automatically, so it would require significant extra manual processing. Yes, it would be part of a verifier's job. E.g. an additional field in the verification form. Empty field, no icon. Otherwise, the field contains an anchor, a section number, or whatever pointer the form handler may accept.
Re: RFC Errata: when to file, and when not to
- Original Message - From: Yoav Nir y...@checkpoint.com To: t.p. daedu...@btconnect.com Cc: Alessandro Vesely ves...@tana.it; ietf@ietf.org Sent: Tuesday, August 07, 2012 11:58 AM On Aug 7, 2012, at 11:29 AM, t.p. wrote: When I Google RFC, I am sometimes directed to www.ietf.org, which is not much help here. Other times, I am directed to tools.ietf.org, whose format I find less friendly but which does have 'errata exist' in the top right hand corner. However, I cannot click on that, No, but two lines above it, there's an Errata link, which you can click. unlike the Obsoletes and Updates fields; but, more importantly, would your average not-involved-in-standards audience know what errata are? For me, the word comes from a classical education, before ever I got involved with standards, and so is a commonplace, but is it used in the world at large? I suspect not. Probably not, and neither is bis. But what can you do about this? It's either allow updating of RFCs after publication, or have a list or corrections. Would it make it easier to find if they were called notes or corrections instead of errata? tp Yes, corrections is what I see published in a newspaper to correct errata in previous editions. So far, it is the best word I can think of (but there might be a better one:-). In the html version of an RFC, it would be easy to provide old and new in an easy to compare format (as some editors do for I-D), not perhaps on permanent display but shown when 'errata' (or whatever name we choose) is toggled. Tom Petch /tp Yoav
Re: RFC Errata: when to file, and when not to
On Thu 02/Aug/2012 03:28:38 -0700 Martin J. Dürst wrote: In particular, the errata system is NOT meant to be used as an issue tracker; Of course we have mailing lists, issue trackers, and wikis, but the problem is that none of them are for RFCs. In addition, those tools seem to be intended rather for IETF internal use than for general public. The question then comes up on whether we can do better. And my guess is that in this day and age of linked information, we should be able to do better. With the tools version of an RFC, which is quickly becoming the preferred version of many, it's already easy to find errata. It is /not difficult/ to find errata. Easy would mean that people usually find them even if they're not purposely looking for them. For example, the existence of an approved errata could be signaled by coloring the margin near the relevant text.
Re: RFC Errata: when to file, and when not to
Of course we have mailing lists, issue trackers, and wikis, but the problem is that none of them are for RFCs. In addition, those tools seem to be intended rather for IETF internal use than for general public. I would say that IETF internal use would refer to chairs, ADs, the RFC Editor (which is not a function that's part of the IETF, by the way), and so on. It's very easy for anyone, including my mother, should she want to, to get a login to the IETF tools system. We could perhaps make it more obvious that one is needed, and how to do it, but I don't know that it's any more of a hurdle than any of the 17,000 other web things that require a free one-time signup. Anyway, as I said, we haven't sorted out how we would do this, and it might be that something even easier than what we have now would be in order. It is /not difficult/ to find errata. Easy would mean that people usually find them even if they're not purposely looking for them. For example, the existence of an approved errata could be signaled by coloring the margin near the relevant text. I like this idea. Not colour, maybe -- despite the errata tool's format, not all errata nicely fit into OLD/NEW text, and one often needs the explanation even for those that do -- but perhaps an errata icon in the margin next to the relevant text. One could click the icon and be sent straight to that erratum. The trouble is that I can't see how we could do that automatically, so it would require significant extra manual processing. I don't have stats on how many errata are Verified (and we'd only do this sort of thing for those, I imagine), nor any real idea of how much extra work it would be for someone to add the erratum links. But no argument at all about how useful it would likely be. Barry
Re: RFC Errata: when to file, and when not to
Hi Barry, Could you refer to a RFC that states your below information or procedure, if there is not, I recommend some one doing procedure drafts to take it over. Please note that ALL reports from any participant should be useful for IETF community and system. Even if he/she misunderstood, this does not mean that he/she is not useful, that means the IETF system/community needs to adjust to help participants to understand and follow. For me I will note your procedure so that I will not report wrongly, but I will continue reporting my comments/views, and hope if some thing is wrong I get a reply like your, thanking you, AB IETF Particpant == The mission of the Internet Engineering Task Force is to make the Internet work better by producing high-quality and relevant technical documents that influence the way people design, use, and manage the Internet. == We've been seeing a lot of inappropriate errata reports, made by well-meaning people who, surely, think their reports are useful, even important. These aren't free: they take time to process, and they form clutter in the errata system, obscuring the ones that do fit into what errata are meant to be. So I wanted to clarify what's meant to be reported, and what's not. A valid erratum, one that the IESG will mark as Verified, mets two criteria: 1. It is truly an *error* in the original document. That is, it would have been considered an error *at the time the document was published*, had it been noticed at the time. 2. It is important, an error that would cause someone to misread the document in a significant way, causing implementation or deployment problems, or other serious issues. Criterion 1 means that anything that is wrong because of situations or discussions that have come up since publication are not appropriate errata. Consider the differences among these: - (a) Someone realizes that the document forgot to specify the valid range of a value. - (b) Someone realizes that the range specified did not correctly reflect the result of the discussion at the time (the change got missed and no one noticed). - (c) Someone realizes that the range specified causes problems in practice, but we didn't know that would happen when we published the document. (a) and (b) are valid errata, and should get marked as Verified. (c) is NOT valid for the errata system, and really ought to be marked as Rejected. Criterion 2 means that minor typos are NOT appropriate errata. The IESG will mark these as Held for Document Update, but, really, there is no need to say that an should be and, that a comma is missing (unless it seriously affects the meaning and is likely to be mis-read), or that concensus is misspelled (as here). Again, consider the differences: - (a) The server will now respond with an error code, where now should have been not. - (b) The server will not repond with an error code, where repond should have been respond. - (c) The server will not respond with and error code, where and should have been an. (a) is the only valid one here. There's no real value in recording the others as errata. In particular, the errata system is NOT meant to be used as an issue tracker; please do not submit errata reports with the *intent* that they be marked as Held for Document Update, to be used as an issue list later. We have mailing lists, issue trackers, and wikis for this purpose. Barry, Applications AD
Re: RFC Errata: when to file, and when not to
Hello Barry, Thanks for explanation about errata, which must have been caused at least in part by an erratum that I submitted recently. Just for the record, I want to mention that the errata report form at http://www.rfc-editor.org/errata_report.php has a type field with two categories, Technical and Editorial, where Editorial is defined in the help popup as: spelling, grammar, punctuation, or syntax error that does not affect the technical meaning. This would directly contradict your Criterion 2 means that minor typos are NOT appropriate errata. However, my main point is a different one. At the end of your mail, you wrote: In particular, the errata system is NOT meant to be used as an issue tracker; please do not submit errata reports with the *intent* that they be marked as Held for Document Update, to be used as an issue list later. We have mailing lists, issue trackers, and wikis for this purpose. Of course we have mailing lists, issue trackers, and wikis, but the problem is that none of them are for RFCs. And if there's a tracker for a bis version, it's not necessarily easy to find from the RFC. Actually, even if somebody finds the -bis draft, in many (if not most) cases, these drafts don't contain pointers to issue trackers, wikis, or the like (a pointer to a mailing list, at least indirectly via the mention of a WG, should be there in most cases, I guess). The question then comes up on whether we can do better. And my guess is that in this day and age of linked information, we should be able to do better. With the tools version of an RFC, which is quickly becoming the preferred version of many, it's already easy to find errata. There are certainly many open questions when moving to better linking of the relevant information, such as who approves it, what's 'official' (wiki, issue tracker,...) and what not, and so on. On 2012/08/01 8:27, Barry Leiba wrote: We've been seeing a lot of inappropriate errata reports, made by well-meaning people who, surely, think their reports are useful, even important. These aren't free: they take time to process, and they form clutter in the errata system, obscuring the ones that do fit into what errata are meant to be. These are certainly problems, and we have to work on improving the situation. Sending all the errata to the IESG without triage (which seems to be done for the Technical ones; not sure it's also true for the Editorial ones) definitely may not be the best for the busy people on the IESG to spend their time. Regards, Martin.
Re: RFC Errata: when to file, and when not to
Thanks for explanation about errata, which must have been caused at least in part by an erratum that I submitted recently. Yours was one of many. Yours was actually one that I'd like to find a way to fix -- a URL that needs to be updated. In particular, the errata system is NOT meant to be used as an issue tracker; please do not submit errata reports with the *intent* that they be marked as Held for Document Update, to be used as an issue list later. We have mailing lists, issue trackers, and wikis for this purpose. Of course we have mailing lists, issue trackers, and wikis, but the problem is that none of them are for RFCs. And if there's a tracker for a bis version, it's not necessarily easy to find from the RFC. Yes, and we're working on that. We're looking into ways of handling this, to provide some sort of issue tracking for RFCs. Not sure yet what the right way to do it is. Barry
