RE: RFC Editor Function SOW Review
I spent the first many years of my professional life overseas working as a Linguist writing and speaking other people's languages. Even though my own proficiency was inadequate by their standards, I relied upon talented native speakers to enhance my publications so that they became well written in the target language. This is what the IETF also needs to do. The IETF authors needn't be very proficient in English, but they need to be proficient enough to coherently explain their technical points so that others can understand them. What is needed is to ensure that somebody, with the authors' oversight, is enlisted to improve the drafts so that the ultimate IETF documents themselves are in very good English. Because the IETF is now International, all the IETF documents must be in well-written English because we now come from so many languages and cultures. It is hard enough dealing in foreign languages without exacerbating the problem for the non-native English speaker by asking them to understand garbled versions of English. If it is difficult for the native English speaker to understand, it is much worse for the non-Native speakers (unless they happen to speak the same language as the garbler). BTW, some native English speakers also produce horrid documents because they are poor writers. These individuals also need to leverage editors who can translate their thoughts into coherent English. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC Editor Function SOW Review
Exactly. Where Dave and I disagree, I think, is that I consider getting from technically correct and coherent but not in English that is acceptable to non-native speakers who primary language also differs from that of the author/editor to be a community responsibility, while Dave considers it a WG (or other advocacy group) one... At least I hope I have that right. That work is arguably best done by professionals because it requires considerable skill; skill that improves with experience. There are several reasons I want to see it handled as a community responsibility rather than as a WG one, but the most important is that, if people have to be hired to do the work, I don't want to see our working groups turn into mini-consortia with their own budgets, funding sources, hired editors, etc. It seems to me, based on both thought experiments and experience with other standards bodies, that would lead to side effects we just do not want. john --On Monday, 24 July, 2006 09:07 -0700 Fleischman, Eric [EMAIL PROTECTED] wrote: I spent the first many years of my professional life overseas working as a Linguist writing and speaking other people's languages. Even though my own proficiency was inadequate by their standards, I relied upon talented native speakers to enhance my publications so that they became well written in the target language. This is what the IETF also needs to do. The IETF authors needn't be very proficient in English, but they need to be proficient enough to coherently explain their technical points so that others can understand them. What is needed is to ensure that somebody, with the authors' oversight, is enlisted to improve the drafts so that the ultimate IETF documents themselves are in very good English. Because the IETF is now International, all the IETF documents must be in well-written English because we now come from so many languages and cultures. It is hard enough dealing in foreign languages without exacerbating the problem for the non-native English speaker by asking them to understand garbled versions of English. If it is difficult for the native English speaker to understand, it is much worse for the non-Native speakers (unless they happen to speak the same language as the garbler). BTW, some native English speakers also produce horrid documents because they are poor writers. These individuals also need to leverage editors who can translate their thoughts into coherent English. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
John C Klensin wrote: Exactly. Where Dave and I disagree, I think, is that I consider getting from technically correct and coherent but not in English that is acceptable to non-native speakers who primary language also differs from that of the author/editor to be a community responsibility, while Dave considers it a WG (or other advocacy group) one... At least I hope I have that right. Sounds correct to me. That work is arguably best done by professionals because it requires considerable skill; skill that improves with experience. It certainly requires skill. However it does not require some sort of formal certification and job title. The skill is available from many sources. There are several reasons I want to see it handled as a community responsibility rather than as a WG one, but the most important is that, if people have to be hired to do the work, I don't want to see our working groups turn into mini-consortia with their own budgets, funding sources, hired editors, etc. You are vastly too late for that, from a practical standpoint. The reality is that virtually all IETF efforts that succeed, these days, come from some sort of organized industry effort. Whether that organization is formal is irrelevant. In any event, industry is already spending quite a bit to get the technical work done, for any given specification. In that context, the incremental cost of the editing work is negligibility -- within the context of that single effort. Meta-point: The resistance to pushing meaningful responsibility to the groups supposed to do the work -- and enforcing that they do it well -- continues to strike me as quite dissonant with the community's claimed goals, both long-standing and recent. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
John C Klensin wrote: If an effort is worthy of adoption by the Internet, surely it is reasonable to demand that it have enough support to be able to obtain its own means of ensuring that the writing is adequate. We may find that there is more market for some protocols --and, over time, for the Internet itself-- in areas where a very significant fraction of the user and Engineering populations are not good writers of English (even if they are able to read and speak it well enough to participate effectively in the work of the IETF). Should the IETF do niche standards, for small markets? I think our history has been that we have felt we generally should not and that our work is primarily intended for Internet scaling, not just can operate using Internet technical infrastructure. Hence, an IETF effort needs to be able to demonstrate a broad base of support. Perhaps more to the point, does the IETF have a crystal ball capable of assessing the long term impact of a particular piece of technical work? I've heard plenty of claims of such insight, but often as not the markets then moved in ways that utterly refute those claims. I can cite plenty of exmaples where there was a room full of people calling for something to be standardized, only to later find nobody out in the real world cared one whit for the result. And there have also been cases where one lone person was pushing something that subsequently become ubiquitous. I think the best we can do is try and make sure the work we do appears to have some semblance of relevance, is technically competent, is capable of being properly specified, and is at least mostly harmless. For all this to happpen there has to be some evidence of core competence behind the proposal. But trying to figure out whether or not there's a broad base of support doesn't exactly play to our strengths IMO. I think getting the writing quality of those documents up to a standard where they can be broadly understood is a community responsibility: if we take the position that authors who cannot write clearly in English, or WGs where such people dominate the technical work, are not welcome or able to play, then we hurt the IETF and the Internet but pushing those ideas and contributions somewhere else... perhaps even into islands. I agree, so it is a good thing that I did not say anything to suggest otherwise. Yes, but... There have to be people willing to assume the responsibility. The cold hard fact is that we're all very busy people, and it is often the case that volunteers willing and able to provide such help are lacking. When, not if, that happens, I'm afraid the answer to the group in question needs to be no. No purpose is served by stringing people along in hopes that a situation will change and previoussly unavailable help will magically appear. What I HAVE said is that the process of getting and demonstrating sufficient community support should include requiring acceptable writing of the specifications. If an effort is not able to recruit sufficient resources for that task, then I frankly question whether it has sufficient market pull to succeed. Exactly! While it would be nice to be able to offer support to all efforts of merit, I see no indication we're in a position to do so. Given the aggregate costs of producing even the most modest Internet standard, the incremental cost of ensuring writing quality is quite small. However concentrating all that expense for all RFCs into the RFC Editor is really just a way of relieving proponents from doing the work needed to create competent work and demonstrate support for it. There's a reason the RFC Editor only gets inolved after standards documents are approved. It is not the RFC Editor's job to turn editorially incompetent specifications into competent ones, if for no other reason than such work requires in-depth technical understanding of the subject area, something the RFC Editor is simply not staffed for. (And I doubt we'be be willing to foot the resulting bill if they were.) Rather, the RFC Editor's job is to meld technically and editorially competent specifications into a consistent series of editorially exceptional documents. Having sufficient community support is an essential requirement, if an effort it going to be successful. Requiring that the effort demonstrate that support, in various pragmatic ways, is merely reasonable. Sure. But that is consistent with expecting design quality but not necessarily the capability to easily write clear English. I have tried to learn enough different languages -- and done badly with each -- to appreciate the barrier that writing in English represents for non-native English writers. That is why I am being careful not to claim that a particular author must be skilled, but rather that the *community* seeking IETF standardization has the responsibility. Agreed. it would be nice if it were
Re: RFC Editor Function SOW Review
Given the number of different working groups that have produced diffiult to read documents for RFC publication, the indications are that we are missing some necessary ingredient for achieving this within the working group process. I do not know if we lack the skills, incentives, or resources, but history indicates that we frequently have produced documents that still need significant editing. While having a goal of improving this makes good sense, I think we need to work from the WG end, not the editor end. Until we are producing better results, we can not cut down on the editing process. Yours, Joel M. Halpern At 08:04 PM 7/22/2006, Dave Crocker wrote: What I HAVE said is that the process of getting and demonstrating sufficient community support should include requiring acceptable writing of the specifications. If an effort is not able to recruit sufficient resources for that task, then I frankly question whether it has sufficient market pull to succeed. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
A web based submission model would be better - it could actually step the submitter through the template sections and give them guidance on the text. Hell readability tools are available from any of the online library tool sources so this is not an issue either. The millstone here is that the IETF refuses to get out of its own way and in mandating paper-text only filings. This is the problem and not the solution and the sooner the IETF gets past that and moves on to the world of on-line collaborative systems as the basis of its vetting pools, well gee... Todd - Original Message - From: Joel M. Halpern [EMAIL PROTECTED] To: Dave Crocker [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Sunday, July 23, 2006 9:58 AM Subject: Re: RFC Editor Function SOW Review Given the number of different working groups that have produced diffiult to read documents for RFC publication, the indications are that we are missing some necessary ingredient for achieving this within the working group process. I do not know if we lack the skills, incentives, or resources, but history indicates that we frequently have produced documents that still need significant editing. While having a goal of improving this makes good sense, I think we need to work from the WG end, not the editor end. Until we are producing better results, we can not cut down on the editing process. Yours, Joel M. Halpern At 08:04 PM 7/22/2006, Dave Crocker wrote: What I HAVE said is that the process of getting and demonstrating sufficient community support should include requiring acceptable writing of the specifications. If an effort is not able to recruit sufficient resources for that task, then I frankly question whether it has sufficient market pull to succeed. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
John C Klensin wrote: If an effort is worthy of adoption by the Internet, surely it is reasonable to demand that it have enough support to be able to obtain its own means of ensuring that the writing is adequate. We may find that there is more market for some protocols --and, over time, for the Internet itself-- in areas where a very significant fraction of the user and Engineering populations are not good writers of English (even if they are able to read and speak it well enough to participate effectively in the work of the IETF). Should the IETF do niche standards, for small markets? I think our history has been that we have felt we generally should not and that our work is primarily intended for Internet scaling, not just can operate using Internet technical infrastructure. Hence, an IETF effort needs to be able to demonstrate a broad base of support. I think getting the writing quality of those documents up to a standard where they can be broadly understood is a community responsibility: if we take the position that authors who cannot write clearly in English, or WGs where such people dominate the technical work, are not welcome or able to play, then we hurt the IETF and the Internet but pushing those ideas and contributions somewhere else... perhaps even into islands. I agree, so it is a good thing that I did not say anything to suggest otherwise. What I HAVE said is that the process of getting and demonstrating sufficient community support should include requiring acceptable writing of the specifications. If an effort is not able to recruit sufficient resources for that task, then I frankly question whether it has sufficient market pull to succeed. Given the aggregate costs of producing even the most modest Internet standard, the incremental cost of ensuring writing quality is quite small. However concentrating all that expense for all RFCs into the RFC Editor is really just a way of relieving proponents from doing the work needed to create competent work and demonstrate support for it. Having sufficient community support is an essential requirement, if an effort it going to be successful. Requiring that the effort demonstrate that support, in various pragmatic ways, is merely reasonable. Sure. But that is consistent with expecting design quality but not necessarily the capability to easily write clear English. I have tried to learn enough different languages -- and done badly with each -- to appreciate the barrier that writing in English represents for non-native English writers. That is why I am being careful not to claim that a particular author must be skilled, but rather that the *community* seeking IETF standardization has the responsibility. What is NOT reasonabel is a model that has the IETF formal infrastructure -- management, editors, etc. -- do the grunt work of making design and writing decisions. We have amply demonstrated that this latter model does not scale or is, at the least, too expensive. (Well, I guess that's a form of not scaling?) Actually, I am not sure that we have demonstrated that at all, amply or not. But, if you say so... Apologies. I thought we had some problems with covering IETF-related expenses. So I thought it worth looking for expenses that could be eliminated from the overhead category and moved back to the individual groups doing individual work. This should all be part of moving the burden of work back to authors and working groups... where it belongs. Up to a point. But the point that I think you are positing will tend to drive some work --work for which there is good community support and commitment-- out of the IETF. And that is not in anyone's interest, IMO. I would be interested in hearing your basis for this fear. Organizations and individuals that are proponents for a piece of work can spend massive numbers of staff-hours, as well as travel and development expenses, but they cannot afford to do the English-based technical editing on their own? This somehow represents an unsurmountable barrier? How is that, John? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
Marcus Leech wrote: Todd Glassey wrote: H... The SOW MUST define all the elements of the Editor's responsibility and all the specific tasks they perform as well as the SLA's for those Tasks. It also MUST address the SOD (Separation of Duties) within the Editor's work since they are altering the IP submitted. Without that ther is no comprehensive model for evaluating how well the IETF met its standards and whether it caused damage to others in the process. Todd Glassey as an Auditor. Methinks you've drunk too deeply of the SOX Kool-Aid, Todd.Along what lines would you suggest that the RFC Editor separate its duties? Perhaps you would also reccommend that the guy who replaces the air freshener blocks in the mens bathroom not also be the same guy who fixes the plumbing? It isn't; one is typically a janitor, the other a plumber. Or maybe the guy who diagnoses your automotive problems be different from the guy who actually fixes it? Perhaps in the RFC-Editor function, the person who fixes missing commas and semi-colons, should be different from the person who addresses clarity and normative reference issues? Clarity and normative reference issues are often content specific. They require knowledge of Internet protocols and their interrelationships (even if the IESG approves the doc doesn't mean the doc is written clearly in that regard). General text editing is not content specific. If you think you can find someone knowledgable enough in the Internet who wants to burn their time fixing typos, please do. I suspect a separation of duties will be necessary otherwise. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
Dave Crocker wrote: ... And that leads to the basic question of professional editing. As I've noted before, my recent experience with the RFC Editor's editors was quite good. They definitely improved the writing in the document. However, such an editorial effort it expensive and I do not understand why this additional expense is needed. It was not needed for 25 or so years. And now we are more sensitive to expenses. The set of people writing docs has increased substantially. The writing skills of that set have diversified, and the pool of potential support has increased. It seems like the two mutually support the use of professional editing. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
Joe thanks for the plumber and janitor response. My response to the same statement would be: The IETF's Editor's have a responsibility to NOT alter IP that is submitted to the IETF - that can by the Standards process ONLY happen through the IETF's Vetting process and is not the perogative of the Editors. But there is more - If a Submitter has their IP modified by the IETF Editors outside of the Vetting Process it constitues an adversarial action in creating another derivative by the Editors since they were given a specific set of properties for the particular reason of vetting those IP's - not those IP's as modified by the Editors... that's why the Editors need an arms length from the process. Todd -Original Message- From: Joe Touch [EMAIL PROTECTED] Sent: Jul 21, 2006 9:03 AM To: Marcus Leech [EMAIL PROTECTED] Cc: Todd Glassey [EMAIL PROTECTED], Pete Resnick [EMAIL PROTECTED], IETF Administrative Director [EMAIL PROTECTED], IETF Announcement list ietf@ietf.org Subject: Re: RFC Editor Function SOW Review Marcus Leech wrote: Todd Glassey wrote: H... The SOW MUST define all the elements of the Editor's responsibility and all the specific tasks they perform as well as the SLA's for those Tasks. It also MUST address the SOD (Separation of Duties) within the Editor's work since they are altering the IP submitted. Without that ther is no comprehensive model for evaluating how well the IETF met its standards and whether it caused damage to others in the process. Todd Glassey as an Auditor. Methinks you've drunk too deeply of the SOX Kool-Aid, Todd.Along what lines would you suggest that the RFC Editor separate its duties? Perhaps you would also reccommend that the guy who replaces the air freshener blocks in the mens bathroom not also be the same guy who fixes the plumbing? It isn't; one is typically a janitor, the other a plumber. Or maybe the guy who diagnoses your automotive problems be different from the guy who actually fixes it? Perhaps in the RFC-Editor function, the person who fixes missing commas and semi-colons, should be different from the person who addresses clarity and normative reference issues? Clarity and normative reference issues are often content specific. They require knowledge of Internet protocols and their interrelationships (even if the IESG approves the doc doesn't mean the doc is written clearly in that regard). General text editing is not content specific. If you think you can find someone knowledgable enough in the Internet who wants to burn their time fixing typos, please do. I suspect a separation of duties will be necessary otherwise. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
Todd Glassey wrote: Joe thanks for the plumber and janitor response. My response to the same statement would be: The IETF's Editor's have a responsibility to NOT alter IP that is submitted to the IETF - that can by the Standards process ONLY happen through the IETF's Vetting process and is not the perogative of the Editors. TThere are changes that do not affect IP - notably most corrections to tense, spelling, punctuation, etc. There are changes that might affect IP - those that involve unclear specification (a field with 8 values, only 5 of which are described), etc. It's useful to catch these - though the author determines how best to handle them. I.e., the Editors don't change things, they raise questions or suggest changes. The author and/or IESG (depending on suggested change) would obviously have last say. And the 'standards process' issue applies only to standards-track; there are other docs (Informational, BCP, Experimental) that are handled as well. Joe -Original Message- From: Joe Touch [EMAIL PROTECTED] Sent: Jul 21, 2006 9:03 AM To: Marcus Leech [EMAIL PROTECTED] Cc: Todd Glassey [EMAIL PROTECTED], Pete Resnick [EMAIL PROTECTED], IETF Administrative Director [EMAIL PROTECTED], IETF Announcement list ietf@ietf.org Subject: Re: RFC Editor Function SOW Review Marcus Leech wrote: Todd Glassey wrote: H... The SOW MUST define all the elements of the Editor's responsibility and all the specific tasks they perform as well as the SLA's for those Tasks. It also MUST address the SOD (Separation of Duties) within the Editor's work since they are altering the IP submitted. Without that ther is no comprehensive model for evaluating how well the IETF met its standards and whether it caused damage to others in the process. Todd Glassey as an Auditor. Methinks you've drunk too deeply of the SOX Kool-Aid, Todd.Along what lines would you suggest that the RFC Editor separate its duties? Perhaps you would also reccommend that the guy who replaces the air freshener blocks in the mens bathroom not also be the same guy who fixes the plumbing? It isn't; one is typically a janitor, the other a plumber. Or maybe the guy who diagnoses your automotive problems be different from the guy who actually fixes it? Perhaps in the RFC-Editor function, the person who fixes missing commas and semi-colons, should be different from the person who addresses clarity and normative reference issues? Clarity and normative reference issues are often content specific. They require knowledge of Internet protocols and their interrelationships (even if the IESG approves the doc doesn't mean the doc is written clearly in that regard). General text editing is not content specific. If you think you can find someone knowledgable enough in the Internet who wants to burn their time fixing typos, please do. I suspect a separation of duties will be necessary otherwise. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
Joe Touch wrote: However, such an editorial effort it expensive and I do not understand why this additional expense is needed. It was not needed for 25 or so years. And now we are more sensitive to expenses. The set of people writing docs has increased substantially. The writing skills of that set have diversified, and the pool of potential support has increased. It seems like the two mutually support the use of professional editing. We have always had some authors who were truly awful writers. Whether we have more of them today is, I believe, really not relevant. If an effort is worthy of adoption by the Internet, surely it is reasonable to demand that it have enough support to be able to obtain its own means of ensuring that the writing is adequate. Having sufficient community support is an essential requirement, if an effort it going to be successful. Requiring that the effort demonstrate that support, in various pragmatic ways, is merely reasonable. What is NOT reasonabel is a model that has the IETF formal infrastructure -- management, editors, etc. -- do the grunt work of making design and writing decisions. We have amply demonstrated that this latter model does not scale or is, at the least, too expensive. (Well, I guess that's a form of not scaling?) This should all be part of moving the burden of work back to authors and working groups... where it belongs. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
--On Friday, 21 July, 2006 15:12 -0700 Dave Crocker [EMAIL PROTECTED] wrote: Joe Touch wrote: However, such an editorial effort it expensive and I do not understand why this additional expense is needed. It was not needed for 25 or so years. And now we are more sensitive to expenses. The set of people writing docs has increased substantially. The writing skills of that set have diversified, and the pool of potential support has increased. It seems like the two mutually support the use of professional editing. We have always had some authors who were truly awful writers. Whether we have more of them today is, I believe, really not relevant. If an effort is worthy of adoption by the Internet, surely it is reasonable to demand that it have enough support to be able to obtain its own means of ensuring that the writing is adequate. Dave, I am very sympathetic to this argument but think it can easily be carried too far. The IETF is becoming more International. We may find that there is more market for some protocols --and, over time, for the Internet itself-- in areas where a very significant fraction of the user and Engineering populations are not good writers of English (even if they are able to read and speak it well enough to participate effectively in the work of the IETF). I think getting the writing quality of those documents up to a standard where they can be broadly understood is a community responsibility: if we take the position that authors who cannot write clearly in English, or WGs where such people dominate the technical work, are not welcome or able to play, then we hurt the IETF and the Internet but pushing those ideas and contributions somewhere else... perhaps even into islands. Having sufficient community support is an essential requirement, if an effort it going to be successful. Requiring that the effort demonstrate that support, in various pragmatic ways, is merely reasonable. Sure. But that is consistent with expecting design quality but not necessarily the capability to easily write clear English. What is NOT reasonabel is a model that has the IETF formal infrastructure -- management, editors, etc. -- do the grunt work of making design and writing decisions. We have amply demonstrated that this latter model does not scale or is, at the least, too expensive. (Well, I guess that's a form of not scaling?) Actually, I am not sure that we have demonstrated that at all, amply or not. But, if you say so... This should all be part of moving the burden of work back to authors and working groups... where it belongs. Up to a point. But the point that I think you are positing will tend to drive some work --work for which there is good community support and commitment-- out of the IETF. And that is not in anyone's interest, IMO. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
Pete, Pete Resnick wrote: On 7/10/06 at 8:34 AM -0400, IETF Administrative Director wrote: we seek comments on the Statement of Work located at: http://koi.uoregon.edu/~iaoc/ - The SOW has nothing about performance expectations (i.e., what is noted in section 4 of draft-mankin-pub-req-10). Though I don't think the SOW should have hard requirements in this regard (draft-mankin-pub-req-10 doesn't), I do think we need to give some estimate of how many documents they're going to see and their expected throughput. A bid is going to have to be based on how fast they think they need to do the editing. Indeed, and that has to be part of the SLA component of final contract. But the numbers in the final SLA may also be part of a price negotiation. I agree we need to put SLA numbers in the RFP, for comparison purposes. - The SOW mentions the Editorial Board for Independent submissions, but doesn't say where it comes from. I take it from the slides at the Thursday plenary that this is still in flux, but at least there should be a note indicating that this is going to be filled in later. Correct. Brian I've already written privately about some nits. Here are couple more: - Strike A-1-g-3. It's redundant with A-1-g-1. - Change category to stream in A-4-b. Category doesn't make any sense there (or if it does, it's undefined.) pr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
H... The SOW MUST define all the elements of the Editor's responsibility and all the specific tasks they perform as well as the SLA's for those Tasks. It also MUST address the SOD (Separation of Duties) within the Editor's work since they are altering the IP submitted. Without that ther is no comprehensive model for evaluating how well the IETF met its standards and whether it caused damage to others in the process. Todd Glassey as an Auditor. -Original Message- From: Brian E Carpenter [EMAIL PROTECTED] Sent: Jul 18, 2006 5:18 AM To: Pete Resnick [EMAIL PROTECTED] Cc: IETF Administrative Director [EMAIL PROTECTED], IETF Announcement list ietf@ietf.org Subject: Re: RFC Editor Function SOW Review Pete, Pete Resnick wrote: On 7/10/06 at 8:34 AM -0400, IETF Administrative Director wrote: we seek comments on the Statement of Work located at: http://koi.uoregon.edu/~iaoc/ - The SOW has nothing about performance expectations (i.e., what is noted in section 4 of draft-mankin-pub-req-10). Though I don't think the SOW should have hard requirements in this regard (draft-mankin-pub-req-10 doesn't), I do think we need to give some estimate of how many documents they're going to see and their expected throughput. A bid is going to have to be based on how fast they think they need to do the editing. Indeed, and that has to be part of the SLA component of final contract. But the numbers in the final SLA may also be part of a price negotiation. I agree we need to put SLA numbers in the RFP, for comparison purposes. - The SOW mentions the Editorial Board for Independent submissions, but doesn't say where it comes from. I take it from the slides at the Thursday plenary that this is still in flux, but at least there should be a note indicating that this is going to be filled in later. Correct. Brian I've already written privately about some nits. Here are couple more: - Strike A-1-g-3. It's redundant with A-1-g-1. - Change category to stream in A-4-b. Category doesn't make any sense there (or if it does, it's undefined.) pr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
Todd Glassey wrote: H... The SOW MUST define all the elements of the Editor's responsibility and all the specific tasks they perform as well as the SLA's for those Tasks. It also MUST address the SOD (Separation of Duties) within the Editor's work since they are altering the IP submitted. Without that ther is no comprehensive model for evaluating how well the IETF met its standards and whether it caused damage to others in the process. Todd Glassey as an Auditor. Methinks you've drunk too deeply of the SOX Kool-Aid, Todd.Along what lines would you suggest that the RFC Editor separate its duties? Perhaps you would also reccommend that the guy who replaces the air freshener blocks in the mens bathroom not also be the same guy who fixes the plumbing? Or maybe the guy who diagnoses your automotive problems be different from the guy who actually fixes it? Perhaps in the RFC-Editor function, the person who fixes missing commas and semi-colons, should be different from the person who addresses clarity and normative reference issues? Yup, that's an efficient use of everyone's time and money. SOD was designed to prevent certain types of financial faud in *financial software development and deployment processes*, and other similar processes where separation of duty is essential to maintain certain properties of the overall process. SOX-mania has become a toxin that has clouded most peoples thinking in this area, and I'm loathe to accept that IETF processes must be held hostage to an ill-conceived set of guidelines promulgated by the utterly-irrelevant-to-the-IETF Public Companies Accounting Oversight Board. The IETF isn't a publically-traded company, last time I checked, and even if it were, the SOD provisions of SOX (and Audit Standard 2, which clearly you've consumed wholesale) clearly wouldn't apply. I suggest, Todd, that you switch to another beverage, because the SOX Kool-Aid is clearly doing neither you nor anybody else any good. -- Marcus LeechMail: Dept 1A12, M/S: 04352P16 Security Standards AdvisorPhone: (ESN) 393-9145 +1 613 763 9145 Strategic Standards Nortel Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
On 7/10/06 at 8:34 AM -0400, IETF Administrative Director wrote: we seek comments on the Statement of Work located at: http://koi.uoregon.edu/~iaoc/ - The SOW has nothing about performance expectations (i.e., what is noted in section 4 of draft-mankin-pub-req-10). Though I don't think the SOW should have hard requirements in this regard (draft-mankin-pub-req-10 doesn't), I do think we need to give some estimate of how many documents they're going to see and their expected throughput. A bid is going to have to be based on how fast they think they need to do the editing. - The SOW mentions the Editorial Board for Independent submissions, but doesn't say where it comes from. I take it from the slides at the Thursday plenary that this is still in flux, but at least there should be a note indicating that this is going to be filled in later. I've already written privately about some nits. Here are couple more: - Strike A-1-g-3. It's redundant with A-1-g-1. - Change category to stream in A-4-b. Category doesn't make any sense there (or if it does, it's undefined.) pr -- Pete Resnick http://www.qualcomm.com/~presnick/ QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor Function SOW Review
Pete Resnick wrote: On 7/10/06 at 8:34 AM -0400, IETF Administrative Director wrote: we seek comments on the Statement of Work located at: http://koi.uoregon.edu/~iaoc/ - The SOW has nothing about performance expectations (i.e., what is noted in section 4 of draft-mankin-pub-req-10). Though I don't think the SOW should have hard requirements in this regard (draft-mankin-pub-req-10 doesn't), I do think we need to give some estimate of how many documents they're going to see and their expected throughput. A bid is going to have to be based on how fast they think they need to do the editing. Right. Some sort of measure, along the lines of person-hours/document. The problem is that different documents take different amounts of effort, unless we change the basic nature of how documents are currently handled. And that leads to the basic question of professional editing. As I've noted before, my recent experience with the RFC Editor's editors was quite good. They definitely improved the writing in the document. However, such an editorial effort it expensive and I do not understand why this additional expense is needed. It was not needed for 25 or so years. And now we are more sensitive to expenses. So while I understand the desire to improve the writing quality and I definitely believe the RFC Editor's editors do that, I think we need to ask whether we need to have the RFC Editor budget expend those monies. My own conclusion is that we do not. d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
