The Internet Society (“ISOC”) on behalf of the IETF Administrative OversightCommittee (IAOC) is solicitingthis request (“Request”) for Proposals ("Proposals") toprovide Python development services using the Django framework. Proposals from anycommercial or non-commercial vendor are welcome.

Those submitting a Proposal(“Vendor”) shall do so in accordance to this Request

I.

Introduction

The Internet Engineering Task Force (IETF) standards development work issupported by an IT infrastructure using MySQL database and tools developed in Python.Some earlier tools developed using Perl are being phased out. The IETF is undertakingthe Life Cycle Datatracker Project and desires to enhance the current

tool infrastructurewith Python using the Django framework and to extend the current architecture tosupport authors, working group chairs, the RFC Editor, the IANA administrators, andothers.

TheInternet Societydesires to enter into an Indefinite Delivery/IndefiniteQuantity (IDIQ) Master Services Agreement (MSA) with one or more softwaredevelopment companies with which to accomplish its objectives over the next twenty-four(24)months. Through the MSA, ISOC,through the IAOC,

will thereafter issueWork Orders for the delivery of specified software.

Awarding a contract or contracts will be a two-step process:

1. Responses to this RFP will be used to identify qualified vendorsasdefined in Section IV. Dto proceed to step two;

2. Invited vendors will be asked to provide pricing information for thedevelopment of a specific application, the assumptions and analysis used to reachthat price.

Attachment 1 contains information for an application in which an existing Djangoapplication is to be enhanced with the functionality of an existing Perl application. ThisRFP requests the proposer to evaluate the information and describe the approach that thevendor would take to accomplish the work.

II.

Current Architecture

The current Datatracker infrastructure provides support for the work of theInternet Engineering Steering Group (IESG), the IETF Secretariat, and through theietf.org website provides information to the community at large. The current tools arewritten in Perl and Python and interface with the MySQL database.

III.

Life Cycle Datatracker Project

3

The Datatracker would provide enhanced support for the IESG, extend theDatatracker to include support for a authors, working group chairs, the RFC Editor, theIANA administrators, and others. Eventually providing management tools and adashboard to better monitor and manage the work of the IETF.

IV.

Instructions and Procedures

A.

Submissions

Proposals must be received via email at rpelletier@isoc.org no later thanDecember 11,2009, 5:00 P.M. EST.

Vendor assumes all risk and responsibility for submission of its Proposal by theabove deadline.ISOCshall have no responsibility for non-receipt of Proposals due tonetwork or system failures, outages, delays or other events beyond its reasonable control.

All Proposals shall become the property of the Internet Society.

B.

Questions and Inquiries

Any inquiries regarding this Request must be submitted in writing to the emailaddress listed in IV.A above. Other than such inquiries, Vendors are prohibited fromcontacting any person or institution involved in the selection process concerning thisRequest.

All questions/inquiries must be submitted in writing and must be received no laterthan midnight, ET,November 16,

2009.

Responses to

questions and inquiries shall be posted on the IAOC website,iaoc.ietf.org/rfpsrfis.html by midnight, EST,November 20,

2009.

C.

Addenda and Updates

Any addenda and updates to this Request shall be posted on the IAOC website,iaoc.ietf.org/rfpsrfis.html. Each Vendor is responsible for checking the IAOC websiteprior to submission of any Proposal to ensure that it has complied with all addenda andupdates to this Request.

D.

Selection Criteria

Each Proposalmust describe the approach that the vendor

would take to enhancean existing Django application with the functionality of an existing Perl application.Attachment 1 provides the background information and context for the application.

Further, each Proposal must specifically address each of theselection criterialisted inSection V

below in a format corresponding to this Request. Each Proposalshould also be accompanied by any technical or product literature that the Vendor wishestheISOCto consider.

4

The IAOC, on behalf of ISOC,

shall select from among those submittingproposals those Vendors which in its discretion are the most qualified to perform thework. Thosevendors

making the short list shall be invited to provide pricing informationfor the development of the application, as well as the assumptions and analysis used todevelop the pricing model.

The IAOC may select one or more Vendors to accomplish the tasks reflected inthis Request.

E.

Cancellation; Rejection

ISOCreserves the right to cancel this Request, in whole or in part, at any time.The IAOC may reject any or all Proposals received in response to this Request in its solediscretion.ISOCmakes no guarantee or commitment to purchase, license or procure anygoods or services resulting from this Request.

F.

Master Services Agreement and Work Orders

Any Final Proposal that is selected by the Internet Society shall be subject tonegotiation and execution of a binding Master Services Agreement (MSA) between theInternet Society and the Vendor.

The MSA shall be for a three-year period with an option for two, one-yearextensions. The MSA is an Indefinite Delivery/Indefinite Quantity (IDIQ) contract as itcannot be determined at this time the nature and number of applications that will benecessary to complete the project.

Any MSA that is entered into by ISOC and Vendor does not imply a guarantee ofwork for that Vendor.

Work orders for individual applications will be placed against the MSA.Attachment 1 identifies the first Work Order under the MSA.

G.

Costs and Expenses

Each Vendor is responsible for its own costs and expenses involved in preparingand submitting its Proposal and any supplemental information requested by the IAOC.ISOC shall not reimburse any such costs or expenses.

H.

Notification

The IAOC will

notify Vendors of their selection following receipt andconsideration of all Proposals. The IAOC will attempt to make its selection(s) within tendays of receipt of final proposals, but shall have full discretion to make a decision earlieror later.

I.

Public Information

5

The IETF is a community committed to transparency in the manner in which itconducts its operations. Accordingly, the following principles will apply to the Proposal,negotiations, MSA and Work Order(s):

The names of all Vendors submitting Proposals may be announced publicly, butthe Proposals

and individual negotiations with Vendors will not be publicly announced.

Any Master Service Agreement negotiated with a Vendor, excluding cost, will bemade public after execution.

J.

Intellectual Property Rights

All work performed, all software and other materials developed by the Vendorunder the MSA, shall be “works for hire” and shall be owned exclusively by the IETFTrust, and the Vendor shall obtain or retain any rights or licensesfrom

any workproduced for the “Work Order”.

The IETF Trust intends to release the applications to the public under theSimplified BSD Software License, and Vendor will be required to represent and warrantthat no impediment to such method of release exists. The Simplified BSD SoftwareLicense can be found at http://www.opensource.org/licenses/bsd-license.php.

V.

Selection Criteria

The selection of Vendor(s) for the next steps in the development of theDatatracker will be based on a number of important criteria that are enumerated below.These criteria include performance features, availability and licensing, cost, and potentialfor future improvements.

A.

Application Requirements

A

read-only view of a subset of the information of the current IETF workflowapplication (“Existing Django Application”) can be inspected athttps://datatracker.ietf.org/idtracker/. The Existing Django Application source code willbe available to all bidders athttp://tools.ietf.org/tools/ietfdb/browser. Read-only accessto the SVN repository can be provided upon request.

A

read-write view of the information of the current IETF workflow application(“Existing Perl Application”) is not available to Vendors as login

is required. TheExisting Perl Application source code will be provided to those who are selected for theshort list by the IAOC.

The Replacement Application must conform to the following requirements. EachProposal must describe the technical features of the Replacement Application that will beused to implement the following requirements:

6

1.

The Replacement Application should retain the same functionality anddatabase structure as the Existing Django Application and the Existing PerlApplication tothe greatest extent possible. The “look and feel” of theReplacement Application should be reasonably close to the Existing PerlApplication. Any proposed reduction in functionality must be described in theFinal Proposal.

2.

The Existing Perl Application maintains metadata about a document,including a state machine and ballot positions from evaluators. There is also anadministrative interface, which allows the administrator to record ballot positionsthat are provided offline and maintain additionaldata.

3.

All actions on a document are logged in a comment log and sent by emailto a list of interested parties. In addition, certain workflow actions cause atemplate email message to be sent to a wider audience (e.g., IETF Last Call, ordocument approval messages).

4.

The Existing Perl Application is currently implemented in thousands oflines of perl, which will be provided for reference to those making the short list.The Replacement Application must be implemented in Python using the Djangoframework, marinating all of the functionality of the Existing Django Applicationand adding the functionality of the Existing Perl Application. Read-only accesswill not require login, but read-write access will require a login. It is expectedthat Django models for many of the relevant database tables already exist, butmay have to be augmented for this work.

5.

The code must be readable and have adequate comments. Designdocumentation that enables later developers to understand and continue workingwith the delivered code must be provided. All software will be delivered insource code, and executable form if applicable.

B

Development Practices

1.

Development should use best current practice for software development,which we expect would mean that some variation on iterative agile softwaredevelopment (http://en.wikipedia.org/wiki/Agile_software_development) such asfor instance scrum (http://en.wikipedia.org/wiki/Scrum_%28development%29) isused.

2.

During both design and coding work, it is expected that a representative of theIETF will be actively involved as the customer representative in the developmentprocess.

3.

During both design and coding work, it is expected that an easily accessibleversion repository will be used to commit consistent increments of designdocuments and working code. Examples of such repository/access methods aresvn/trac, svn/code.google.com, git/github. The Existing Django Application isbeing maintained using svn/trac, athttp://svn.tools.ietf.org/svn/tools/ietfdb/

and

7

http://tools.ietf.org/tools/ietfdb/

. Continuing to use this for the development ofthe Replacement Django Application would be an advantage.

4.

During both design and coding work, it is expected that an easily accessibleissue tracking system that integrates with the source repository is available. Theexamples given for code repositories above also provide this capability.

C.

Intellectual Property

Vendor shall describe

any intellectual property rights owned or licensed by youwhich may cover all or part ofthe Replacement Application, including a list anddescription of all U.S. and foreign patents and patent applications.

Vendor shall describe

any intellectual property owned or licensed by third partieswhich is required to utilize all or part of the Replacement Application in the mannercontemplated by this Request.

Vendor shall describe

in detail any claims or disputes relating to the intellectualproperty embodied, or claimed to be embodied, in all or part of the ReplacementApplication.

D.

Personnel

Vendor shall describe

the personnel who would form the team that will be directlyinvolved in the performance of services under the Service Agreement, includingsupervisory, managerial, liaison, development and support personnel. Provide detailedCVs for each team member to the greatest extent possible.

Vendor shall describe

each team member’s experience with projects of similartechnical requirements and scope, and the percentage of such team member’s full-timeeffort that will be devoted to this project.

E.

Support and Maintenance

Vendor shall describe

the technical support that will be available for theReplacement Application, including qualifications of support staff, availability, responsetimes, manner of response, escalation and any other pertinent information. It is expectedthat support and maintenance will be available throughout the duration of the contract.

The Replacement Application must be warranted to operate in accordance with itsspecifications and otherwise in a reliable and secure manner for at least one year fromacceptance. There shall be no charge for work required by Vendor to repair or fix seriouserrors to bring the Replacement Application into compliance during the warranted time.

F.

Pricing

Pricing will be a component of the Final Proposal submitted by those on the shortlist. The development and implementation portion of this project will be on a fixed-cost

8

basis. Each Proposal must provide a fixed-cost bid, without escalation, for thedevelopment and implementation of the Replacement Application (through finalacceptance of all features and functionality). It is expected that payment will be madebased on Vendor’s timely achievement of enumerated delivery and acceptancemilestones.

Each Proposal must also provide pricing for support, maintenance and futuredevelopment work.

All pricing shall be denominated in U.S. dollars.

G.

Timing

Time is

of the essence in the development and deployment of the ReplacementApplication. The Service Agreement will contain binding timeframes for delivery of theReplacement Application, including penalties for late or incomplete delivery.

Each Final Proposal

must include a timeline for the development andimplementation of the Replacement Application, including major milestones andproposed penalties for late or incomplete delivery.

H.

Relationships

Describe any relationship between your company, or any parent, subsidiary orrelated company, or any director or officer of any of them, with the ISOC, IAOC, IETFor the IETF Trust, or any employee, director, officer or consultant of any of them.

VI.

Proposal Format

A.

Proposal Submissions

Proposals shall be submitted using the following format:

1. Transmittal letter with signature of authorized representative

2. Executive Summary

3. Table of Contents

4. Experience, Qualifications and Accomplishments

5. Key Personnel

8. References (Three references attesting to performance)

9. Describe the approach to create the application in Attachment 1

10. Resumes of Key Personnel

11. Subcontractor Information (if any)

12. Assumptions

13. IPR

14. Relationships

15. Miscellaneous Information

9

Attachment 1–

Authentication in

the first Work Order

The first Work Order will merge the Existing Django Application and the Existing PerlApplication to create the Replacement Application. In the resulting application, no loginwill be required to view much of the data, and login will be required to update thedatabase. Presently, there are two authentication levels: IESG and Secretariat.Additional authentication levels will be introduced in future enhancements.

Access-control functionality for the Django application will be added

to the datatrackercode. It makes no sense to have separate "public tracker" and "non-public tracker" code.The first access-controlled functionality will be common tasks done by IESG, such asballoting.

For authentication, the existing Apache htpasswd

files will be used. These files aremaintained by the IETF Secretariat. Initially, there won't be any automatic functionalityfor creating accounts or resetting lost passwords.

The Django code will not access the htpasswd files in any way; the actual authenticationis done by Apache. Apache configuration will be modified so that "/login/" URL (orsimilar) requires a password. Then, the Django authentication framework is used to getthe user name from the REMOTE_USER environment variable set by Apache.

(Note:this requires Django version 1.1).

Apache will not request authentication for any other URLs; instead, access control isdone by Django code, based on a cookie set by the login page. Pages that absolutelyrequire authentication would redirect the client to /login/; other pages might showdifferent views to unauthenticated users (e.g., anyone can view the ballot page, but fillingin a ballot is only available to IESG members after login.

Authorization information will be used to determine which users are allowed to performvarious tasks. The Django framework will be used to access existing database tables todetermine authorization, for example, which users are IESG members. These databasetables are maintained by the IETF Secretariat. It is also be possible to read the Apache.perms file, but it's not clear if this will be needed.

Volunteers will be available for consulting on the authentication and authorizationarchitecture if needed.