Re: Last Call: RFC Editor Services Draft RFI
Hi John, As an individual who happens to find herself on the RFP subcommittee, I'd like to follow up a few points, below. I have added rfc-editor-...@ietf.org to the cc line (having seen your follow up note) as it is my understanding that the intention was for that list to be publicly archived, and this gets to the attention of all of the members of the subcommittee. John C Klensin wrote: This document is hard to comment on because it raises, and mixes, a number of separate issues. A large number of those involve questions that the RFI responses might reasonably address; I have omitted those from these comments unless they are directly related to more immediate issues. The document is repetitive internally and duplicates material from other materials. In particularly, Appendix B duplicates much of the material on pages 3 - 5. I have not made these comments longer by pointing out each place a particular problem occurs. Major issues: (1) This document is heavily dependent on the IAB's RFC Editor model document. It is unfortunate that the comment cutoff on this document occurs while that one is still being tuned. In RFC Editor process language, there is a clear normative dependency between this one and the IAB document and final decisions cannot be made on this one before that one has solidified. IMO, closing the comment period on this one before the IAB signs off on that one is not consistent with the spirit of the comments and commitment made during and after the Minneapolis Plenary. (2) That dependency is particularly important for two reasons. First, the RFC Editor Model document leaves a number of loose ends which the community has been assured will be straightened out by the IAOC and the RPI, RFP, and ongoing management processes without the community having to be involved. That is fine as long as the issues involved are administrative details. But there is nothing in BCP 101 and its relationship to RFC 4846 that permits the IAB to delegate fundamental policy decisions to the IAOC. Personally, I rather hope it's clear that the IAB doesn't make such delegations, but will leave the discussion of the RFC Model document for elsewhere. The RFC Editor Model document is still not clear on where the IAB believes the boundary lies. For the record, any decision on that subject presumably creates an appealable event, with an appeal timer that does not start until at least the date on which the IAB hands the document off to the RFC Editor. To the extent to which RFC3932bis is relevant (I suggest in (10), below, that it is not), almost the same comments about normative dependencies would apply to it. (3) The second reason is, in some respects, almost the opposite. The RFI goes well beyond either the draft RFC Editor Model document or RFC 4844/ 4846 in assigning critical-path responsibilities to the IAB. The two RFCs carefully avoid getting the IAB into a position in which it much respond to a particular issue on a specific timeframe in order to permit others to do jobs for which they are contractually obligated. It would be really useful to have a couple of examples of where you see this happening in the SOW. There are places where we worked to make sure the IAB (or some entity) was in a loop, but I don't believe there was the intention of making the IAB critical path. So, it would be helpful to know where you read it that way. But the SOW here appears to require just that sort of commitment from the IAB and presumably for the IAB to be able to make decisions that involve the informed actions of the vast majority of its members. Without that, either possibly-important decisions are made by a few individuals, in the dark, and with no real community input or accountability or the various contractual actors are unable to proceed with their work. I note that willingness and a commitment to work actively on this sort of matter is not part of the IAB role description in RFC 2850 nor is it part of the IAB job description most recently given to the Nomcom. If the RFI is going to assume this level of commitment by the IAB, it would be useful to know that at least the current IAB membership has accepted that responsibility and obligation. (4) If a potential responder for some of these roles is, individually or organizationally, an active part of the IETF community and standards process (or of the community that might present Independent Submissions to the Independent Submission Editor), there is a potential for at least the appearance of conflicts of interest. It seems to me that a key question for the RFI is to find out how various parties would propose to deal with those issues. (5) There is an inherent contradiction between (i) the apparent requirement that a potential vendor respondent to the RFI supply all of a specific list of information (the list under The IASA is seeking... on pages 3 and 4 or its near-equivalent in Appendix B) and presumably be committed to
Re: Last Call: RFC Editor Services Draft RFI
On Jan 7, 2009, at 11:57 PM, John C Klensin wrote: This document is hard to comment on because it raises, and mixes, a number of separate issues. A large number of those involve questions that the RFI responses might reasonably address; I have omitted those from these comments unless they are directly related to more immediate issues. The document is repetitive internally and duplicates material from other materials. In particularly, Appendix B duplicates much of the material on pages 3 - 5. I have not made these comments longer by pointing out each place a particular problem occurs. Major issues: snip (13) The Production Center is committed to follow the provisions of a Style Manual that does not exist today, is unlikely to exist when the RFP goes out, and may become the first task for the newly-appointed RFC Series Editor in January 2010. I hope the IAB has a plan about how that particular bit of transition is going to be handled and that the plan has been vetted by the IAOC. If not, this is another internal normative dependency. John, The Style Manual is located here: http://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt Ray snip ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: RFC Editor Services Draft RFI
--On Thursday, January 08, 2009 13:09 -0500 Ray Pelletier rpellet...@isoc.org wrote: (13) The Production Center is committed to follow the provisions of a Style Manual that does not exist today, is unlikely to exist when the RFP goes out, and may become the first task for the newly-appointed RFC Series Editor in January 2010. I hope the IAB has a plan about how that particular bit of transition is going to be handled and that the plan has been vetted by the IAOC. If not, this is another internal normative dependency. John, The Style Manual is located here: http://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08. txt Sorry to be pedantic about this. Regardless of how it is titled, that is a informal style guide (reading it makes that clear) whose actual status (e.g., whether it complements RFC 2223 or the long-in-draft 2223bis or supercedes them) is unclear. What would turn it into a style manual would presumably be IAB signoff under the RFC Editor Model document, which is itself a draft. And, at least when I last looked at that section, the RFC Editor Model draft assigns responsibility for the style manual to the Series Editor and does not grandfather the current RFC Editor into that specific role, the aggregate RFC Editor function notwithstanding. So one cannot assume, absent language in the draft RFI that isn't there, that the Production House should assume that rfc-style-manual-08 is the reference Style Manual until and unless it is replaced or updated. If, for the purposes of the RFI, you want to identify that draft as the basis for the Style Manual that will be used by the Production House until it is replaced, then say so and reference it. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: RFC Editor Services Draft RFI
This document is hard to comment on because it raises, and mixes, a number of separate issues. A large number of those involve questions that the RFI responses might reasonably address; I have omitted those from these comments unless they are directly related to more immediate issues. The document is repetitive internally and duplicates material from other materials. In particularly, Appendix B duplicates much of the material on pages 3 - 5. I have not made these comments longer by pointing out each place a particular problem occurs. Major issues: (1) This document is heavily dependent on the IAB's RFC Editor model document. It is unfortunate that the comment cutoff on this document occurs while that one is still being tuned. In RFC Editor process language, there is a clear normative dependency between this one and the IAB document and final decisions cannot be made on this one before that one has solidified. IMO, closing the comment period on this one before the IAB signs off on that one is not consistent with the spirit of the comments and commitment made during and after the Minneapolis Plenary. (2) That dependency is particularly important for two reasons. First, the RFC Editor Model document leaves a number of loose ends which the community has been assured will be straightened out by the IAOC and the RPI, RFP, and ongoing management processes without the community having to be involved. That is fine as long as the issues involved are administrative details. But there is nothing in BCP 101 and its relationship to RFC 4846 that permits the IAB to delegate fundamental policy decisions to the IAOC. The RFC Editor Model document is still not clear on where the IAB believes the boundary lies. For the record, any decision on that subject presumably creates an appealable event, with an appeal timer that does not start until at least the date on which the IAB hands the document off to the RFC Editor. To the extent to which RFC3932bis is relevant (I suggest in (10), below, that it is not), almost the same comments about normative dependencies would apply to it. (3) The second reason is, in some respects, almost the opposite. The RFI goes well beyond either the draft RFC Editor Model document or RFC 4844/ 4846 in assigning critical-path responsibilities to the IAB. The two RFCs carefully avoid getting the IAB into a position in which it much respond to a particular issue on a specific timeframe in order to permit others to do jobs for which they are contractually obligated. But the SOW here appears to require just that sort of commitment from the IAB and presumably for the IAB to be able to make decisions that involve the informed actions of the vast majority of its members. Without that, either possibly-important decisions are made by a few individuals, in the dark, and with no real community input or accountability or the various contractual actors are unable to proceed with their work. I note that willingness and a commitment to work actively on this sort of matter is not part of the IAB role description in RFC 2850 nor is it part of the IAB job description most recently given to the Nomcom. If the RFI is going to assume this level of commitment by the IAB, it would be useful to know that at least the current IAB membership has accepted that responsibility and obligation. (4) If a potential responder for some of these roles is, individually or organizationally, an active part of the IETF community and standards process (or of the community that might present Independent Submissions to the Independent Submission Editor), there is a potential for at least the appearance of conflicts of interest. It seems to me that a key question for the RFI is to find out how various parties would propose to deal with those issues. (5) There is an inherent contradiction between (i) the apparent requirement that a potential vendor respondent to the RFI supply all of a specific list of information (the list under The IASA is seeking... on pages 3 and 4 or its near-equivalent in Appendix B) and presumably be committed to it should the vendor choose to respond to an RFP and (ii) the disclaimer in item (4) on page 5 that a non-response to the RFI does not bar someone from responding to an RFP. While some of the information requested in Appendix B are entirely appropriate to an RFI response that is not binding on either the IASA or the respondent, others, especially the requirement to identify a specific candidate person for the Series Editor if someone might later submit a proposal specifying that position is a deterrent to getting useful responses. It would be completely appropriate for an RFI to request a discussion of the job description for the Series Editor that is present in the RFC Editor Model document (except that the description there is mostly hand-waving) or to discuss that role more generally, and even to ask for comments on how that position might effectively be filled, but that
