From nobody at xyzzy.claranet.de Fri May 9 00:09:42 2008 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Fri, 9 May 2008 09:09:42 +0200 Subject: [rfc-i] RFC 5000 on Internet Official Protocol Standards References: <20080508232458.80A7D129742@bosco.isi.edu> Message-ID: The RFC Editor Team wrote: > URL: http://www.rfc-editor.org/rfc/rfc5000.txt Thanks. From paul.hoffman at vpnc.org Fri May 9 09:24:26 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Fri, 9 May 2008 09:24:26 -0700 Subject: [rfc-i] RFC 5000 on Internet Official Protocol Standards In-Reply-To: References: <20080508232458.80A7D129742@bosco.isi.edu> Message-ID: At 9:09 AM +0200 5/9/08, Frank Ellermann wrote: > > URL: http://www.rfc-editor.org/rfc/rfc5000.txt > >Thanks. Maybe thanks are not in order. While it's certainly time to update STD 1, I can't remember an RFC with as many problems as this one. - It says that it's Informational, while all previous versions of STD 1 have been Standards Track. In specific, RFC 5000 obsoletes RFC 3700. RFC 3700 and its predecessors were on standards track; RFC 5000 is Informational. It's hard to see how a document can both be Informational and STD. This seems like a glaring error. - The data is not timely; according to the abstract it's describing the situation as of almost three months ago. If the purpose was to obsolete RFC 3700, a one-page RFC that just described rfcxx00.html would have been much more useful. - It shows how slowly the RFC publishing process is running. This RFC sat in the queue for almost three months, as the first sentence of the abstract makes clear. - The "author" is an organization, not a person, breaking with decades of practice. This could lead to companies using only the company's name without a responsible individual's name for Informational RFCs that describe their protocols; that would be a bad change from the current policy. - On an editorial level, it references RFC 2026 but there is no "References" section. All of these problems (other than the slowness) could have been avoided if the authors had published an Internet Draft and asked for comments, as is normal for documents that will become RFCs (other than April 1 RFCs). I'm sure people on this list would have been happy to review the draft and make suggestions. --Paul Hoffman, Director --VPN Consortium From braden at ISI.EDU Fri May 9 09:59:52 2008 From: braden at ISI.EDU (Bob Braden) Date: Fri, 9 May 2008 09:59:52 -0700 (PDT) Subject: [rfc-i] RFC 5000 on Internet Official Protocol Standards Message-ID: <200805091659.JAA11454@gra.isi.edu> Paul, Well, thanks for your comments, anyway. *> > *> >Thanks. *> *> Maybe thanks are not in order. While it's certainly time to update *> STD 1, I can't remember an RFC with as many problems as this one. *> We agree. *> - It says that it's Informational, while all previous versions of STD *> 1 have been Standards Track. In specific, RFC 5000 obsoletes RFC *> 3700. RFC 3700 and its predecessors were on standards track; RFC 5000 *> is Informational. It's hard to see how a document can both be *> Informational and STD. This seems like a glaring error. *> The error, in this case, belongs in the IAB and IESG. We asked to circumvent 2026 and publish 5000 as a Standard, but the IETF has to follow its own rules strictly, I guess, so we were told that we can publish it only as Informational. The RFC Editor certainly agrees with you on this one. *> - The data is not timely; according to the abstract it's describing *> the situation as of almost three months ago. If the purpose was to *> obsolete RFC 3700, a one-page RFC that just described rfcxx00.html *> would have been much more useful. *> It has taken 3 months to get permission from the IETF management. *> - It shows how slowly the RFC publishing process is running. This RFC *> sat in the queue for almost three months, as the first sentence of *> the abstract makes clear. *> Actually, it shows exactly nothing about how fast the process of editing and publishing goes. It does show how fast the IETF management can make decisions. *> - The "author" is an organization, not a person, breaking with *> decades of practice. This could lead to companies using only the *> company's name without a responsible individual's name for *> Informational RFCs that describe their protocols; that would be a bad *> change from the current policy. *> We would be very happy if you could please resurrect that person. We miss him greatly. But you are greatly over-reacting about the policy. *> - On an editorial level, it references RFC 2026 but there is no *> "References" section. *> Well, we will give you this one. *> All of these problems (other than the slowness) could have been *> avoided if the authors had published an Internet Draft and asked for *> comments, as is normal for documents that will become RFCs (other *> than April 1 RFCs). I'm sure people on this list would have been *> happy to review the draft and make suggestions. *> I fail to see how that would have helped, given the situation. Bob Braden for the RFC Editor *> --Paul Hoffman, Director *> --VPN Consortium *> _______________________________________________ *> rfc-interest mailing list *> rfc-interest at rfc-editor.org *> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest *> From paul.hoffman at vpnc.org Sun May 11 16:24:33 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Sun, 11 May 2008 16:24:33 -0700 Subject: [rfc-i] RFC 5000 on Internet Official Protocol Standards In-Reply-To: <200805091659.JAA11454@gra.isi.edu> References: <200805091659.JAA11454@gra.isi.edu> Message-ID: At 9:59 AM -0700 5/9/08, Bob Braden wrote: > *> - The data is not timely; according to the abstract it's describing > *> the situation as of almost three months ago. If the purpose was to > *> obsolete RFC 3700, a one-page RFC that just described rfcxx00.html > *> would have been much more useful. > *> > >It has taken 3 months to get permission from the IETF >management. Maybe you could have re-run the data to bring it up to date after you got permission. > *> - It shows how slowly the RFC publishing process is running. This RFC > *> sat in the queue for almost three months, as the first sentence of > *> the abstract makes clear. > *> > >Actually, it shows exactly nothing about how fast the process of >editing and publishing goes. It does show how fast the IETF >management can make decisions. Maybe you could have re-run the data to bring it up to date after you got permission. > *> - The "author" is an organization, not a person, breaking with > *> decades of practice. This could lead to companies using only the > *> company's name without a responsible individual's name for > *> Informational RFCs that describe their protocols; that would be a bad > *> change from the current policy. > *> > >We would be very happy if you could please resurrect that person. >We miss him greatly. But you are greatly over-reacting about the >policy. Fully disagree. The policy is very important, and it is particularly disturbing that you decided to change the policy (a) when your employer was the author, (b) when this updates a document that has an author's names on it, and (c) when you did so without an Internet-Draft where people could comment on it. This is about the current RFC Editor, not Jon. Blaming it on him (or the lack of him) seems odd this many years out. > *> All of these problems (other than the slowness) could have been > *> avoided if the authors had published an Internet Draft and asked for > *> comments, as is normal for documents that will become RFCs (other > *> than April 1 RFCs). I'm sure people on this list would have been > *> happy to review the draft and make suggestions. > *> > >I fail to see how that would have helped, given the situation. More transparency when making policy changes is always better. An Internet-Draft of what you submitted to the IESG and IAB would have helped those of us who care about the RFC process to see what was going on. So would a notice to this mailing list. Please consider being more open with the community in the future. --Paul Hoffman, Director --VPN Consortium From nobody at xyzzy.claranet.de Thu May 15 10:07:52 2008 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Thu, 15 May 2008 19:07:52 +0200 Subject: [rfc-i] RFC 5000 on Internet Official Protocol Standards References: <20080508232458.80A7D129742@bosco.isi.edu> Message-ID: Paul Hoffman wrote: > Maybe thanks are not in order. Okay, I was in a hurry and didn't look for nits, but I saw that STD 10 is now almost "empty" for the next about 30 months... ;-) The IESG might be be mystified when they lost control over what is and what is not a STD. I take it as a call for attention. > these problems (other than the slowness) > could have been avoided if the authors > had published an Internet Draft and asked > for comments, as is normal for documents > that will become RFCs Yes, the "IETF daily dose" listed 5000 once as I-D, but I was unable to figure out where the "daily dose" script found this draft... Frank From olaf at NLnetLabs.nl Thu May 15 10:42:07 2008 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Thu, 15 May 2008 19:42:07 +0200 Subject: [rfc-i] RFC 5000 on Internet Official Protocol Standards Message-ID: Bob, Paul, Colleagues, On May 9, 2008, at 6:59 PM, Bob Braden wrote: > *> - It says that it's Informational, while all previous versions of > STD > *> 1 have been Standards Track. In specific, RFC 5000 obsoletes RFC > *> 3700. RFC 3700 and its predecessors were on standards track; RFC > 5000 > *> is Informational. It's hard to see how a document can both be > *> Informational and STD. This seems like a glaring error. > *> > > The error, in this case, belongs in the IAB and IESG. We asked to > circumvent 2026 and publish 5000 as a Standard, but the IETF has to > follow its own rules strictly, I guess, so we were told that we can > publish it only as Informational. The RFC Editor certainly agrees > with you on this one. The RFC Editor brought up the issue with the IAB. The RFC Editor should expect the IAB to follow the IETF processes. The IAB argues, in its oversight role, as follows: The premise is that the RFC Editor is not in the business of directly publishing Standards Track documents. In fact, only IETF Stream documents can be published as Standards Track documents. Therefore these index documents, published as part of the Independent Stream, should be published as Informational documents, and the RFCs that were previously published as Standard Track documents should be obsoleted or made Historic. Since obsoleting Standard Track documents is an IESG action the pragmatic approach of adding an IESG note was followed. Leaving the inconsistency of an informational document being published as STD1. RFC2026 specifically mentions this practice: The "Official Protocol Standards" RFC (STD1) lists a general requirement level for each TS, using the nomenclature defined in this section. This RFC is updated periodically. This text allows a (pragmatic) exception to the convention that documents with STD numbers should be Standard Track documents. That the RFC Editor wants to go on record as not agreeing with this argument is fine, but calling it an error goes too far. [...] Paul Hoffman argued: > > *> - The "author" is an organization, not a person, breaking with > *> decades of practice. This could lead to companies using only the > *> company's name without a responsible individual's name for > *> Informational RFCs that describe their protocols; that would be a > bad > *> change from the current policy. BCP78 uses the term "Contributor": an individual submitting a Contribution. From an IPR perspective an RFC should list individuals as authors of documents created by functional entities (such as the IAB or the RFC Editor). For IAB Stream documents we usually list the editors and "the IAB" as authors. Paul Hoffman also argued, > *> All of these problems (other than the slowness) could have been > *> avoided if the authors had published an Internet Draft and asked > for > *> comments, as is normal for documents that will become RFCs (other > *> than April 1 RFCs). I'm sure people on this list would have been > *> happy to review the draft and make suggestions. It seems good practice to follow documented practices of RFC4846, which include, as a first step, publication of an Internet-Draft. And although the documented steps may occur in rapid progression there is still some time for an open and transparent process. For the IAB, --Olaf Kolkman -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 235 bytes Desc: This is a digitally signed message part Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20080515/4587c232/PGP.bin From paul.hoffman at vpnc.org Mon May 19 18:37:02 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Mon, 19 May 2008 18:37:02 -0700 Subject: [rfc-i] People's names on the contributor list In-Reply-To: <200805091659.JAA11454@gra.isi.edu> References: <200805091659.JAA11454@gra.isi.edu> Message-ID: At 7:42 PM +0200 5/15/08, Olaf Kolkman wrote: >BCP78 uses the term "Contributor": an individual submitting a >Contribution. From an IPR perspective an RFC should list individuals >as authors of documents created by functional entities (such as the >IAB or the RFC Editor). At 9:59 AM -0700 5/9/08, Bob Braden wrote: >But you are greatly over-reacting about the >policy. Maybe. By "greatly over-reacting", did you mean "because this was a one-time mistake" or "because this is the way ISI is going to do it regardless of what others think"? Just published: Network Working Group RFC Editor Internet-Draft USC/ISI Intended status: Informational May 20, 2008 Expires: November 21, 2008 RFC Editor Proposal for Handling RFC Errata draft-rfc-editor-errata-process-01 --Paul Hoffman, Director --VPN Consortium From braden at ISI.EDU Tue May 20 09:45:22 2008 From: braden at ISI.EDU (Bob Braden) Date: Tue, 20 May 2008 09:45:22 -0700 (PDT) Subject: [rfc-i] RFC 5000 on Internet Official Protocol Standards Message-ID: <200805201645.JAA15027@gra.isi.edu> Olaf, You wrote: *> *> That the RFC Editor wants to go on record as not agreeing with this *> argument is fine, but calling it an error goes too far. *> *> [...] If you trace this thread back, you will find that the word "error" was introduced by Paul Hoffman. I apologize for quoting his word without putting quotation marks around it, as I should have since it was his word. Bob Braden From braden at ISI.EDU Tue May 20 09:51:09 2008 From: braden at ISI.EDU (Bob Braden) Date: Tue, 20 May 2008 09:51:09 -0700 (PDT) Subject: [rfc-i] People's names on the contributor list Message-ID: <200805201651.JAA15044@gra.isi.edu> *> *> At 7:42 PM +0200 5/15/08, Olaf Kolkman wrote: *> >BCP78 uses the term "Contributor": an individual submitting a *> >Contribution. From an IPR perspective an RFC should list individuals *> >as authors of documents created by functional entities (such as the *> >IAB or the RFC Editor). *> I note that a search for "IAB" under author shows about 10 RFCs in which the IAB seems to be listed as an author. Bob Braden From paul.hoffman at vpnc.org Tue May 20 10:21:29 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue, 20 May 2008 10:21:29 -0700 Subject: [rfc-i] People's names on the contributor list In-Reply-To: <200805201651.JAA15044@gra.isi.edu> References: <200805201651.JAA15044@gra.isi.edu> Message-ID: At 9:51 AM -0700 5/20/08, Bob Braden wrote: > *> > *> At 7:42 PM +0200 5/15/08, Olaf Kolkman wrote: > *> >BCP78 uses the term "Contributor": an individual submitting a > *> >Contribution. From an IPR perspective an RFC should list individuals > *> >as authors of documents created by functional entities (such as the > *> >IAB or the RFC Editor). > *> > >I note that a search for "IAB" under author shows about 10 RFCs in >which the IAB seems to be listed as an author. Which RFCs are you talking about? I just looked at the past many years, and all the ones that I found that list the IAB as an author also list at least one responsible person. --Paul Hoffman, Director --VPN Consortium From paul.hoffman at vpnc.org Tue May 20 10:17:57 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue, 20 May 2008 10:17:57 -0700 Subject: [rfc-i] RFC 5000 on Internet Official Protocol Standards In-Reply-To: <200805201645.JAA15027@gra.isi.edu> References: <200805201645.JAA15027@gra.isi.edu> Message-ID: At 9:45 AM -0700 5/20/08, Bob Braden wrote: >Olaf, > >You wrote: > > *> > *> That the RFC Editor wants to go on record as not agreeing with this > *> argument is fine, but calling it an error goes too far. > *> > *> [...] > > >If you trace this thread back, you will find that the word "error" >was introduced by Paul Hoffman. I apologize for quoting his >word without putting quotation marks around it, as I should have >since it was his word. Correct. I said "This seems like a glaring error." The "seems like" part was due to the decision about the document being made without an Internet Draft or any consultation with the public (or even this mailing list). I now see that it was a conscious decision by the IAB, and am fine with that, even if I somewhat disagree with their conclusion. --Paul Hoffman, Director --VPN Consortium From olaf at NLnetLabs.nl Wed May 21 14:05:30 2008 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Wed, 21 May 2008 23:05:30 +0200 Subject: [rfc-i] RFC 5000 on Internet Official Protocol Standards In-Reply-To: <200805201645.JAA15027@gra.isi.edu> References: <200805201645.JAA15027@gra.isi.edu> Message-ID: <5B699E76-A532-43C2-A8F9-60FD3C632580@nlnetlabs.nl> For the IAB I wrote: > *> That the RFC Editor wants to go on record as not agreeing with this > *> argument is fine, but calling it an error goes too far. > *> > *> [...] You responded: > If you trace this thread back, you will find that the word "error" > was introduced by Paul Hoffman. I apologize for quoting his > word without putting quotation marks around it, as I should have > since it was his word. This seems to be one of those cases where mail fails to capture tone. Let us just remember the original intend of our mail exchange: inform about the decision process and the arguments used. In fact, and for completeness, there were two other arguments why STD1 should be Informational that I had not mentioned in my previous mail. o STD1 references Draft Standards and Proposed Standards, which an "Internet Standard" (per RFC2026) is not allowed to do, but an Informational doc can. o STD1 contains no normative language, and nothing one can claim conformance to or implement. Instead, it is basically a roadmap document (and roadmap RFCs are Informational). --Olaf From braden at ISI.EDU Wed May 21 14:25:49 2008 From: braden at ISI.EDU (Bob Braden) Date: Wed, 21 May 2008 14:25:49 -0700 (PDT) Subject: [rfc-i] RFC 5000 on Internet Official Protocol Standards Message-ID: <200805212125.OAA15693@gra.isi.edu> *> *> o STD1 references Draft Standards and Proposed Standards, which an *> "Internet Standard" (per RFC2026) is not allowed to do, but an *> Informational doc can. *> *> o STD1 contains no normative language, and nothing one can claim *> conformance to or implement. Instead, it is basically a roadmap *> document (and roadmap RFCs are Informational). *> *> *> --Olaf Olaf, In my world, an index/catalog is a unique kind of object, that does not have to, and indeed probably cannot, follow the same rules as the documents it indexes. It is a unique kind of beast. As in Goeddels (sp?) theorem. Oh well, let's quit and do something more useful. Bob Braden From olaf at NLnetLabs.nl Fri May 30 09:46:33 2008 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Fri, 30 May 2008 18:46:33 +0200 Subject: [rfc-i] RFC Editor Structure Message-ID: <8456FB73-2EAF-4AB3-B1FD-43D5379B4D8E@nlnetlabs.nl> Dear Colleagues, Below is a proposed change in the RFC Editor model with specific requests for input. The Internet Architecture Board, being responsible for the oversight of the RFC series, welcomes your feedback and deliberations. The plan is also available through http://www.iab.org/documents/resources/RFC-Editor-Model.html . Discussion about this proposal should take place on this list (RFC-interest at rfc-editor.org ). The IAB intends to judge consensus and draw conclusions after the IETF in Dublin (July 27 - August 1, 2008). For the IAB, --Olaf Kolkman ---------- Proposed RFC Editor Structure Introduction The IAB, on behalf of the Internet technical community, is concerned with ensuring the continuity of the RFC Series, orderly RFC Editor succession, maintaining RFC quality, and RFC document accessibility. The IAB is also sensitive to the concerns of the IAOC about providing the necessary services in a cost effective and efficient manner. The definition of the RFC series is described in RFC 4844. Section 3.1 defines "RFC Editor": 3.1. RFC Editor Originally, there was a single person acting as editor of the RFC Series (the RFC Editor). The task has grown, and the work now requires the organized activity of several experts, so there are RFC Editors, or an RFC Editor organization. In time, there may be multiple organizations working together to undertake the work required by the RFC Series. For simplicity's sake, and without attempting to predict how the role might be subdivided among them, this document refers to this collection of experts and organizations as the "RFC Editor". The RFC Editor is an expert technical editor and series editor, acting to support the mission of the RFC Series. As such, the RFC Editor is the implementer handling the editorial management of the RFC Series, in accordance with the defined processes. In addition, the RFC Editor is expected to be the expert and prime mover in discussions about policies for editing, publishing, and archiving RFCs. RFC 4844 envisions changes in the RFC Editor organizational structure. The IAB is considering a change to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality, maintaining timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency. The IAB and the IAOC want to know if the Internet community agrees that the proposed RFC Editor structure will meet the needs of the entire Internet community. Expenses for the RFC Editor The expenses discussed in this document are not new expenses. They are part of the IASA budget. Today, these expenses are part of the RFC Editor contract with ISI. The model is constructed in such a way that it allows for all these functions to be implemented jointly or under different contracts. In fact, a bidder could put together a proposal that includes one or more subcontractors. Since the reporting structure would depend on how the manner that the contracts are awarded, they are subject to change over time. As a result, the model does only describe responsibilities, procedures, and process. The exact implementation is a responsibility of the IAOC. Proposed RFC Editor Model The proposed RFC Editor model divides the responsibilities for the RFC Series into the following: 1. RFC Editor 2. Independent Stream Supervisor 3. RFC Production 4. RFC Publisher The RFC Series Production and Process under this structure is schematically represented by the figure at http://www.iab.org/documents/resources/RFCEditorProd.png RFC Editor The RFC Editor is a single person, and this person is responsible for: 1. RFC Series continuity 2. RFC Style Manual publication for use by authors and editors 3. RFC errata process management 4. Liaison with the IAB The RFC Editor is a senior managerial position with a strong understanding of the IETF process and seasoned management skills. The IAB is considering possible models for filling this position in the future. The IAB is seeking input on the two possible models outlined below, and the IAB is interested in other potential models. The first alternative for the selection of the RFC Editor is through a Request for Proposal (RFP) process run by the IAOC. As in the first alternative, the IAOC would seek a person with the listed qualifications in a broadly distributed RFP. The winner would be selected by the IAOC in consultation with the IAB, and then, the IAOC would contract for the services. Contract terms, including length of contract, extensions and renewals, shall be as defined in an RFP. The opportunity to bid shall be broadly available. Expenses to support the administrative operation of the RFC Editor would be part of the awarded contract and be part of the IASA budget. The second alternative is an individual with the listed qualifications selected by the community and confirmed by the IAB. An approach similar to the one used by the IAB to select an IAOC member every other year as described in RFC 4333 could be used. Expenses to support the administrative operation of the RFC Editor selected in this manner would be part of the IASA budget. Independent Stream Supervisor The Independent Stream Supervisor is a single person, and this person is responsible for: 1. Independent Submissions approval and processing 2. Forwarding RFCs in the independent stream to the RFC Publisher 3. Independent Submissions RFC errata review and approval The Independent Stream Supervisor is a senior position for which the following qualifications are desired: 1. Technical competence 2. An understanding of the IETF process 3. An ability to assess the technical competence of potential Editorial Board members 4. Good standing in the technical community in and beyond the IETF The IAB is considering possible models for filling this position in the future. The IAB is seeking input on a possible model outlined below, and the IAB is interested in other potential models. The proposal is an individual with the listed qualifications selected by the community and confirmed by the IAB. An approach similar to the one used by the IAB to select an IAOC member every other year as described in RFC 4333 could be used. Expenses to support the administrative operation of the Independent Stream Supervisor selected in this manner would be part of the IASA budget. Today, the RFC Editor when acting in the Independent Stream Supervisor role is supported by an Editorial Board, and no changes to the Editorial Board are being proposed. RFC Production In the proposed split of activities, RFC Production is performed by a paid contractor, and the contractor responsibilities include: 1. Editing inputs from all RFC streams to comply with the RFC Style Manual 2. Creating records of edits performed on documents 3. Engaging in dialogue with authors when clarification is needed 4. Creating records of dialogue with documents authors 5. Requesting advice from the RFC Editor as needed 6. Provide suggestions to the RFC Editor as needed 7. Coordinating with IANA to obtain registry information 8. RFC number assignment 9. Forwarding ready-to-publish documents to the RFC Publisher 10. Forwarding records of edits and author dialogue to RFC Publisher 11. Liaison with IESG and IAB The RFC Production contractor is expected to be selected by the IAOC through an RFP process, perhaps as part of the same contract as the RFC Editor. The IAOC would seek a bidder who, among other things, is able to provide a timely and cost effective service against the established style and production guidelines. Contract terms, including length of contract, extensions and renewals, shall be as defined in an RFP. The opportunity to bid shall be broadly available. RFC Publisher In the proposed model, the RFC Publisher responsibilities include: 1. Announce and provide online access to RFCs 2. Provide online system to submit RFC Errata 3. Provide online access to approved RFC Errata 4. Provide backups 5. Provide storage and preservation of records 6. Authenticate RFCs for legal proceedings The IAOC is considering two possibilities for selection of the RFC Publisher. The IAOC is seeking input on the two alternatives outlined below, and the IAOC is interested in other potential alternatives. The first alternative is to extend the IETF Secretariat contract to include these services. Expenses to support these services would be part of the revised contract. The second alternative is a separate vendor selected by the IAOC through an RFP process. Expenses to support service would be part of the awarded contract. _______________________________________________