Loren Data's SAM Daily™

fbodaily.com
Home Today's SAM Search Archives Numbered Notes CBD Archives Subscribe
FBO DAILY ISSUE OF JULY 20, 2011 FBO #3525
MODIFICATION

A -- CROSS DOMAIN INNOVATIVE TECHNOLOGIES

Notice Date
7/18/2011
 
Notice Type
Modification/Amendment
 
NAICS
541712 — Research and Development in the Physical, Engineering, and Life Sciences (except Biotechnology)
 
Contracting Office
Department of the Air Force, Air Force Materiel Command, AFRL - Rome Research Site, AFRL/Information Directorate, 26 Electronic Parkway, Rome, New York, 13441-4514
 
ZIP Code
13441-4514
 
Solicitation Number
BAA-10-09-RIKA
 
Point of Contact
Lynn G. White, Phone: (315) 330-4996
 
E-Mail Address
Lynn.White@rl.af.mil
(Lynn.White@rl.af.mil)
 
Small Business Set-Aside
N/A
 
Description
The purpose of this modification is to republish the original announcement, incorporating all previous modifications, pursuant to FAR 35.016(c). This republishing also includes the following changes: (a) Section I Funding Opportunity Description: Deleted and added focus areas applicable to all FYs, deleted FY11 Focus Area, added focus areas for FY12, deleted and added focus areas for FY13; (b) Section III.3 and III.4, Eligibility Information: Added information concerning CCR and Executive Compensation and First-Tier Sub-contract/Sub-recipient Awards; (c) Section IV.3, Submission Dates and Times: deleted FY11 submission date, changed FY12 and FY13 submission dates and added sentence to indicate the closing date of the BAA; and (d) Section VI.3, Award Administration Information: Added more detailed reporting instructions. No other changes have been made. NAICS CODE: 541712 FEDERAL AGENCY NAME: Department of the Air Force, Air Force Materiel Command, AFRL - Rome Research Site, AFRL/Information Directorate, 26 Electronic Parkway, Rome, NY, 13441-4514 TITLE: Cross Domain Innovative Technologies ANNOUNCEMENT TYPE: Initial announcement FUNDING OPPORTUNITY NUMBER: BAA 10-09-RIKA CFDA Number: 12.800 I. FUNDING OPPORTUNITY DESCRIPTION: The Cross Domain Innovation & Science (CDIS) group of the Air Force Research Laboratory's Information Directorate is interested in new innovative technologies and capabilities that promote the state of the art for secure, accreditable capabilities to enhance the sharing of information between multiple independent security domains. General Focus Areas Applicable to all FYs: - Multiple Independent Levels of Security/Multiple Level Security technologies: MILS & MLS technologies are operating systems or equivalents which allow for trustworthy handling of data at different classifications. These are often core functionalities utilized in cross domain solutions. Examples of MILS systems include Green Hills "Integrity" Real-Time Operating System (RTOS), Linux Works LynxOS, or Wind River's offerings. Examples of MLS operating systems include Trusted Solaris 10 with Trusted Extensions, or Security Enhanced Linux (SE-Linux). - Object level auditing: Modern auditing is typically performed on specific events, such as accessing a new process, potential modification point, etc. This tends to lead to massive amounts of audit data, some with little or no security relevance. An alternate approach is to have data objects be capable of recognizing appropriately auditable events - creation, deletion, copying, etc - and report their occurrence to some centralized service(s). Such an effort would face an extreme amount of validation requirements to be accreditable. - Policy-based configuration and management: Most modern systems are typically configured independently, leading to difficulty in reconfiguring a network of multiple systems to handle an overarching change. Additionally, most are directly configured, rather than being dynamically reactive to policy changes. Having systems being both centrally configured and reactive to policy changes could greatly reduce the administrative overhead of such systems. On the management side, the Government must be able to represent policies for access to system resources electronically, allowing for a simple policy change to affect the configuration of systems and networks in a highly assured manner. - Workflow Enforcement: Most systems are good at maintaining a workflow within their capabilities. However, few systems are easily adaptable to enforce new workflows across multiple systems, maintaining non-repudiation and auditability across each step. Solutions that allow for adaptable workflows will greatly improve system flexibility and reactivity to changes when needed. - Redaction: The ability to modify an information flow (either in limited formats or optimally in any format) to remove information inappropriate to its destination. The ultimate goal would be a system capable of automatically preventing inadvertent or malicious release of inappropriate information while not restricting the appropriate sharing of information. Further challenges include determining the point at which redaction removes the value of transmitting any resulting information, which if successful would reduce the bandwidth & processing requirements for cross domain solutions. - Data Trust: Being able to assure that the content (‘data') matches the labels and metadata associated with it. This is a dual task. The system must assure an appropriate linkage between specific data and metadata by automated inspection wherever possible and human inspection where automation is infeasible. It must also allow for highly-trusted validation mechanisms to reduce the computational overhead, while still fulfilling the certification and accreditation requirements. - Enterprise Common Operational Picture (COP): An awareness of challenges, risks and problems to an enterprise is critical to being able to respond appropriately to react to enterprise events including load balancing, fail over and matching of appropriate device based on information to be shared. As such, a Common Operational Picture (COP) or dashboard environment is required to measure environmental factors of all machines within the enterprise so that an appropriate reaction can be made to quickly adapt to the changes needed. Note that there are non-trivial operational and need-to-know issues involved. - Service management: Given the growing interest in and support of Service Oriented Architecture (SOA) in the various domains, improving the management of such resources becomes increasingly urgent. Adding in the desire of many customers to form ‘mashable' (data rapidly adaptable by users) interfaces to critical data sources via SOA, this management requirement becomes even more critical. Additional concerns come into play when these single-domain SOA-based enterprises begin incorporating cross domain solutions. Thus, determining the risks to one or more cross-domain solutions as provided by such ‘mashable' interfaces' capabilities becomes an urgent concern. This can also be known as ‘service orchestration'. - Data Aggregation & Attestation: A classic concern with automated data handling is the data aggregation issue, also referred to as the ‘sources and methods' problem. That is, a document made up of multiple pieces of information may end up with a final classification higher than any of its constituent parts. Finding methods to assure this does not happen within automated, adaptable services is a major challenge. Further, finding automated or automatable methods to validate and attest that it has not occurred increase the level of difficulty. - Trustworthy labeling tools & services: Being able to appropriately and securely label information is an early precursor to flattening the networks. As such, the integrity of the labels - especially classification & releasability labels at a bare minimum - is critical in the long run. Various methods are being researched for this, from authoritative information servers to various cryptographic binding methods, and including other approaches. Given the importance of appropriate labeling of data in a flattened networking environment, the tools to add labeling to data become very important targets of malicious users. Finding ways to assure that the labeling is correct and not maliciously applied or reapplied becomes critical. - Identity management: Maintaining track of who has access to what resources is a non-trivial, but mostly understood challenge within a single domain. When this capability is extended into a cross domain environment, many critical issues immediately arise and make what seems reasonably solvable in a single domain quite thorny. Examples include need-to-know issues, such as: Do low-side users need to know about high-side users? When and why and how do you allow only appropriate information flows? How and when do accounts getting locked in one domain affect account(s) in other domains? - Storage of sensitive data with multiple owners: Given the focus of centralization of capabilities currently ongoing within the various communities (Defense Enterprise Computing Centers (DECCs), Regional Service Centers (RSCs), etc., the issue of sensitive information owned by multiple disparate organizations being collocated on a single device becomes a potential showstopper. Finding ways to protect the need to know of the information at a level acceptable to all the various data owners in question becomes a very difficult problem, especially when you add in the modern need-to-share requirements. - Secure non-hierarchical data sharing: The Bell-LaPadula concepts (‘write up, read down') work extremely well for hierarchical separation schemes, such as with classification. However, there are many non-hierarchical separation schemes in use across the various domains - releasability, caveats and code words can all be examples of non-hierarchical classification schemes. What are the equivalents of Bell-LaPadula's concepts in such non-hierarchical information spaces? - Appropriate discovery and subscription to data flows in other domains: A common theme across academic approaches to web services and SOA is discovery - sharing information about how to get information. This is a great advantage to the transfer of information, but the common, open standards typically used are completely insecure. To allow for discovery of services in trusted networks, there must be some level of need-to-know enforcement built into the standard academic discovery approaches. - Disadvantaged (‘tactical') user support: The Tactical user is unable to handle the information load expected within the enterprise, as they are typically limited to the computer hardware they can carry or have mounted to a vehicle. Yet these users are still in need of many of the enterprises' data feeds, and are the ultimate reason for those enterprises' existence. How do we link these users back into the enterprises, given the challenges on weight, power, bandwidth, and effective time? (Would you rather have a soldier on the front lines performing administrative tasks, or fighting?) - Cross domain enterprise management: This area investigates quality of service (QOS) in different security domain being handled at the transfer device improving enterprise information sharing. This area identifies ways to achieve greater mission assurance by enabling Cross Domain content review mechanisms to be efficiently adapted to changes in information assurance and mission policies. To achieve this, a Cross-Domain content review architecture supporting expandable set of service-based data filters and a data flow orchestration mechanism responsive to policy changes must be defined, leveraged and/or developed. - Secure Information Sharing - In order to prevent malicious insider and outsider threats to the many different security domains, within a Cross Domain System (CDS), Technology that improves/enhances cyber capabilities via assured isolation & mitigation of high concern threats, covert channels, and other defensive cyber capabilities within cross domain environments must be developed. In doing so, balance among the three legs of the CIA Triad; Confidentiality, Integrity, and Availability must be maintained. - Advance Trusted Computing Technologies: Advance the state of the art in trusted computing technologies though active research of commercial companies and technologies to determine what trusted computing technologies are on the market today. Once identified, this area will assist in defining a Technology Roadmap and Trusted Computing Strategy based on those findings and investigate the identified trusted computing architectures, looking at ways to modify and improve architectures for operational use. After analysis is complete, the development and population of a test-bed of trusted computing technologies for testing security, functionality, and performance of modified systems can be created and a strategic marketing and outreach execution which impacts commercial development of Trusted Computing products and services of selected candidates provided that is based on the test results. Focus Areas for FY12: Cognitive support for discourse level analysis: - Using innovative techniques to enhance the sharing of documents between multiple security domains, there is an additional need to expand the capability beyond single documents and create machine comprehension of multiple documents. This is useful in ‘chatroom' and many other multiple-person interaction collaboration formats. As a bonus these techniques may be able to detect phishing/social engineering efforts. Automation of RHR: - Increasing the speed and efficiency of the human review process required on transfer of most information from a higher classification domain to a lower classification domain. Methods are expected to be highly variable, from full machine comprehension to statistical techniques that aid the reviewer. Example tools needed to improve the RHR process include: identifying, revealing and/or cleansing of hidden content; data security labeling verification; data owner/data steward identity verification; pedigree representation; cognitive text analysis and many others. RHR remains a continual bottleneck for the efficient sharing of information between multiple security domains. In order to improve sharing, the need exists to automate, as much as feasible, tools to cognitively analyze the documents and messages being transferred in order to make an effective decision. This capability must prove to be highly reliable and accurate with a proven ability to substantially reduce the number of false positive and false negative responses. The solution must take into account the Information Assurances aspects of the capability so that the tools can be extended into an accreditable automated RHR capability. Streaming Full-Motion Video Across Security Domains: Operational requirements exist to send video streams across security domains. Unfortunately it is extremely difficult to validate that the content in a video stream is completely appropriate for lower security environments. As such, using Key-Length-Value technologies and cryptographic techniques early in the information lifecycle will indicate its origin, greatly assisting in determining the appropriateness of release into other security domains while also indicating potential accidental or malicious tampering with the information stream. Using Heuristic Algorithms for Reasoning About Data: This capability will improve the efficiency and effectiveness of sharing documents across security domains by translating the output of multiple inspection tools (e.g. dirty word filters, anti-virus and stegonagraphy detection) into numerical values, and interprets the combined results to heuristically apply a ranking or "risk factor." This allows administrators to set the appropriate risk policies for the system, enabling automated decisions such as documents with a low risk factor will be allowed to automatically pass to a Cross Domain Solution (CDS) while those with a high risk factor will require further RHR. Additionally, this capability will employ cognitive capabilities to analyze the risk scores of the various documents over time and "learn" to assign an appropriate risk rating based on patterns and similarities across documents. Cross-Domain VTC: Leveraging prior success of within audio and the Streaming Full-motion Video Across Security Domains for video, this effort will investigate a prototype video teleconferencing (VTC) capability intended to be usable across security domains. This will include the ability to invite users in different security domains to a VTC session, eliminate or reduce covert channels to an acceptable level, and automate interactions to a high degree. Focus Areas for FY13: Brokering authoritative trust within multiple security domains: - Investigate and develop innovative mechanisms for the development of multi-domain authentication and authorization services. Currently, there are many single domain mechanisms for single domains that cannot be used for multi-domain brokering due to information assurance issues with trust. There is a need to determine how best to leverage those single-domain solutions to allow for trust between different security domains. This trust obviously cannot be cryptographically secured, and due to concerns of operational security should obscure to a large degree the domain that the information that the trust is being based upon is being drawn from. Multi-Security Multi-Organization Environments: Investigate and prototype secure communications on a ‘flattened network', where information is being passed between all appropriate members. Members are deemed to be appropriate or not based on the approved maximum classifications of the user, of the user's hardware, of the user's network, and of the information being passed. This is intended to minimally impact the broad range of investments previously made by organizations, allowing for organizations to utilize less-secure commercial software (MS Office, Adobe Acrobat, etc) while maintaining high degrees of assurance of integrity, confidentiality and availability. Next Generation Trusted Data Services: As SOAs move towards secure Cloud Computing within a Global Information Grid environment, the research, analysis, and assembly of appropriate secured services is required to ensure that data within this environment is trustworthy, reliable, readily available to the appropriate parties, protected from unauthorized parties, timely, and accurate. This area seeks to identify, select, implement and test various services against a finely tuned set of performance, security, and reliability metrics and develop a prototype solution that fuses these capabilities into an accreditable prototype solution. Key Terms: Secure: The solutions must be highly resistant to inappropriate use, either deliberate or accidental. Accreditable: The solutions must be able to pass appropriate accreditation procedures, such as DOD Information Assurance Certification and Accreditation Process (DIACAP), Director of Central Intelligence Directive (DCID) 6/3, and/or the emerging National Institute of Standards & Technology (NIST) 8500 standards in its final form. (Systems will not need to be immediately accredited, but must make all reasonable efforts to retain the ability to be accredited via best practices and good security design, such as Defense Information Systems Agency's (DISA's) Security Technical Implementation Guide (STIG) series, National Institute of Standards & Technology (NIST)'s Special Publication 800-53v3, and other appropriate guidance.) Need to Know: Not every user will necessarily be allowed access to every potential resource. Solutions must have appropriate measures to allow enforcement of access policies. Sharing: Information handled through these solutions must be able to be easily shared with appropriate personnel and/or systems. This typically requires adherence to published data, security, infrastructure and interoperability standards such as those available from World Wide Web Consortium (W3C) and/or Organization for the Advancement of Structured Information Standards (OASIS) among others. In general, solutions should be capable of interacting appropriately via SOA/web service means. Independent Security Domains: By default, each level of classification is required to run on physically separated infrastructures. Cross-domain solutions are the bridges between these infrastructures, and hence require an exceedingly detailed security analysis and risk identification. II. AWARD INFORMATION: Total funding for this BAA is approximately $24 M. The anticipated funding to be obligated under this BAA is broken out by fiscal year as follows: FY 11 - $8M; FY 12 - $8M; FY 13 - $8M. Individual awards will not normally exceed 36 months with dollar amounts normally ranging between $250K to $1M per year. There is also the potential to make awards up to any dollar value. Awards of efforts as a result of this announcement will be in the form of contracts, grants or cooperative agreements depending upon the nature of the work proposed. III. ELIGIBILITY INFORMATION: 1. ELIGIBLE APPLICANTS: All potential applicants are eligible. Foreign or foreign-owned offerors are advised that their participation is subject to foreign disclosure review procedures. Foreign or foreign-owned offerors should immediately contact the contracting office focal point, Lynn G. White, Contracting Officer, telephone (315) 330-4996 or e-mail Lynn.White@rl.af.mil for information if they contemplate responding. The e-mail must reference the title and BAA 10-09-RIKA. 2. COST SHARING OR MATCHING: Cost sharing is not a requirement. 3. CCR Registration: Unless exempted by 2 CFR 25.110 all offerors must: (a) Be registered in the Central Contractor Registration (CCR) prior to submitting an application or proposal; (b) Maintain an active CCR registration with current information at all times during which it has an active Federal award or an application or proposal under consideration by an agency; and (c) Provide its DUNS number in each application or proposal it submits to the agency. 4. Executive Compensation and First-Tier Sub-contract/Sub-recipient Awards: Any contract award resulting from this announcement may contain the clause at FAR 52.204-10 - Reporting Executive Compensation and First-Tier Subcontract Awards. Any grant or agreement award resulting from this announcement may contain the award term set forth in 2 CFR, Appendix A to Part 25 http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=c55a4687d6faa13b137a26d0eb436edb&rgn=div5&view=text&node=2:1.1.1.41&idno=2#2:1.1.1.4.1.2.1.1 IV. APPLICATION AND SUBMISSION INFORMATION: 1. APPLICATION PACKAGE: THIS ANNOUNCEMENT CONSTITUTES THE ONLY SOLICITATION. WE ARE SOLICITING WHITE PAPERS ONLY. DO NOT SUBMIT A FORMAL PROPOSAL AT THIS TIME. Those white papers found to be consistent with the intent of this BAA may be invited to submit a technical and cost proposal, see Section VI of this announcement for further details. For additional information, a copy of the AFRL/Rome Research Sites "Broad Agency Announcement (BAA): A Guide for Industry," April 2007, may be accessed at: http://www.fbo.gov/spg/USAF/AFMC/AFRLRRS/Reference%2DNumber%2DBAAGUIDE/listing.html 2. CONTENT AND FORM OF SUBMISSION: Offerors are required to submit 3 copies of a 3 to 5 page white paper summarizing their proposed approach/solution. The purpose of the white paper is to preclude unwarranted effort on the part of an offeror whose proposed work is not of interest to the Government. The white paper will be formatted as follows: Section A: Title, Period of Performance, Estimated Cost, Name/Address of Company, Technical and Contracting Points of Contact (phone, fax and email)(this section is NOT included in the page count); Section B: Task Objective; and Section C: Technical Summary and Proposed Deliverables. Multiple white papers within the purview of this announcement may be submitted by each offeror. If the offeror wishes to restrict its white papers/proposals, they must be marked with the restrictive language stated in FAR 15.609(a) and (b). All white papers/proposals shall be double spaced with a font no smaller than 12 pitch. In addition, respondents are requested to provide their Commercial and Government Entity (CAGE) number, their Dun & Bradstreet (D&B) Data Universal Numbering System (DUNS) number, a fax number, an e-mail address, and reference BAA 10-09-RIKA with their submission. All responses to this announcement must be addressed to the technical POC, as discussed in paragraph six of this section. 3. SUBMISSION DATES AND TIMES: It is recommended that white papers be received by the following dates to maximize the possibility of award: FY 12 by 2 Sep 11 and FY 13 by 7 Sep 12. White papers will be accepted until 2pm Eastern time on 30 September 2013, but it is less likely that funding will be available in each respective fiscal year after the dates cited. The closing date for this BAA is 30 September 2013. FORMAL PROPOSALS ARE NOT BEING REQUESTED AT THIS TIME. 4. FUNDING RESTRICTIONS: The cost of preparing white papers/proposals in response to this announcement is not considered an allowable direct charge to any resulting contract or any other contract, but may be an allowable expense to the normal bid and proposal indirect cost specified in FAR 31.205-18. Incurring pre-award costs for ASSISTANCE INSTRUMENTS ONLY, are regulated by the DoD Grant and Agreements Regulations (DODGARS). 5. All Proposers should review the NATIONAL INDUSTRIAL SECURITY PROGRAM OPERATING MANUAL, (NISPOM), dated February 28, 2006 as it provides baseline standards for the protection of classified information and prescribes the requirements concerning Contractor Developed Information under paragraph 4-105. Defense Security Service (DSS) Site for the NISPOM is: https://www.dss.mil/portal/ShowBinary/BEA%20Repository/new_dss_internet//isp/fac_clear/download_nispom.html. 6. OTHER SUBMISSION REQUIREMENTS: DO NOT send white papers to the Contracting Officer. All responses to this announcement must be addressed to ATTN: Michael J. Mayhew AFRL/RIEBB CDIS BAA: BAA-10-09-RIKA 525 Brooks Road Rome, NY 13441-4505 Electronic submission to Michael.Mayhew@rl.af.mil will also be accepted. V. APPLICATION REVIEW INFORMATION: 1. CRITERIA: The following criteria, which are listed in descending order of importance, will be used to determine whether white papers and proposals submitted are consistent with the intent of this BAA and of interest to the Government: (1) Overall Scientific and Technical Merit -- Including the degree of innovation for the approach and the use of innovative modern architectures in development and/or enhancement of the proposed technology; the use of analysis, metrics & testing and adherence to Information Assurance and Cross-Domain Certification & Accreditation requirements, (2) Related Experience - The extent to which the offeror demonstrates relevant technology and domain knowledge, (3) Openness, Maturity & Assurance of Solution - The extent to which existing capabilities and standards are leveraged and the relative maturity of the proposed technology in terms of Confidentiality, Integrity, Availability, Reliability and Robustness, and (4) Reasonableness and realism of proposed costs and fees (if any). No further evaluation criteria will be used in selecting white papers/proposals. Individual white paper/proposal evaluations will be evaluated against the evaluation criteria without regard to other white papers and proposals submitted under this BAA. White papers and proposals submitted will be evaluated as they are received. 2. REVIEW AND SELECTION PROCESS: The Government may use the services of MITRE in an advisory role for the technical evaluation of proposals. The exclusive responsibility for evaluation and selection/non-selection of proposals remains with the Government. Representatives of the foregoing firm participating in the evaluation process will be precluded from submitting a white paper/proposal under this BAA, and will sign a non-disclosure agreement in order to highlight the sensitivity of the evaluation process and to protect any proprietary information within the proposals. Any objection to the use of any or all of the personnel identified above must be in writing to the Contracting Officer and shall include a detailed statement of the basis for the objection. The Air Force Research Laboratory's Information Directorate has contracted for various business and staff support services, some of which require contractors to obtain administrative access to proprietary information submitted by other contractors. Administrative access is defined as "handling or having physical control over information for the sole purpose of accomplishing the administrative functions specified in the administrative support contract, which do not require the review, reading, or comprehension of the content of the information on the part of non-technical professionals assigned to accomplish the specified administrative tasks." These contractors have signed general non-disclosure agreements and organizational conflict of interest statements. The required administrative access will be granted to non-technical professionals. Examples of the administrative tasks performed include: a. Assembling and organizing information for R&D case files; b. Accessing library files for use by government personnel; and c. Handling and administration of proposals, contracts, contract funding and queries. Any objection to administrative access must be in writing to the Contracting Officer and shall include a detailed statement of the basis for the objection. VI. AWARD ADMINISTRATION INFORMATION: 1. AWARD NOTICES: Those white papers found to be consistent with the intent of this BAA may be invited to submit a technical and cost proposal. Notification by email or letter will be sent by the technical POC. Such invitation does not assure that the submitting organization will be awarded a contract. Those white papers not selected to submit a proposal will be notified in the same manner. Prospective offerors are advised that only Contracting Officers are legally authorized to commit the Government. All offerors submitting white papers will be contacted by the technical POC, referenced in Section VII of this announcement. Offerors can email the technical POC for status of their white paper/proposal no earlier than 45 days after submission. 2. ADMINISTRATIVE AND NATIONAL POLICY REQUIREMENTS: Depending on the work to be performed, the offeror may require a secret or top secret facility clearance and safeguarding capability; therefore, personnel identified for assignment to a classified effort must be cleared for access to secret or top secret information at the time of award. In addition, the offeror may be required to have, or have access to, a certified and Government-approved facility to support work under this BAA. Data subject to export control constraints may be involved and only firms holding certification under the US/Canada Joint Certification Program (JCP) (www.dlis.dla.mil/jcp) are allowed access to such data. 3. REPORTING: Once a proposal has been selected for award, offerors will be required to submit their reporting requirement through one of our web-based, reporting systems known as JIFFY or TFIMS. Prior to award, the offeror will be notified which reporting system they are to use, and will be given complete instructions regarding its use. Please note that use of the JIFFY or TFIMS application requires customers outside of the.mil domain to purchase an approved External Certificate Authority certificate to facilitate a secured log on process. It is necessary to obtain an ECA certificate BEFORE obtaining a JIFFY or TFIMS user account. Additional information on obtaining an ECA is available at: http://iase.disa.mil/pki/eca/index.html. VII. AGENCY CONTACTS: Questions of a technical nature shall be directed to the cognizant technical point of contact, as specified below: Michael J. Mayhew Telephone: (315) 330-2898 Email: michael.mayhew@rl.af.mil Questions of a contractual/business nature shall be directed to the cognizant contracting officer, as specified below: Lynn White Telephone (315) 330-4996 Email: Lynn.White@rl.af.mil The email must reference the solicitation (BAA) number and title of the acquisition. In accordance with AFFARS 5301.91, an Ombudsman has been appointed to hear and facilitate the resolution of concerns from offerors, potential offerors, and others for this acquisition announcement. Before consulting with an ombudsman, interested parties must first address their concerns, issues, disagreements, and/or recommendations to the contracting officer for resolution. AFFARS Clause 5352.201-9101 Ombudsman (Apr 2010) will be incorporated into all contracts awarded under this BAA. The AFRL Ombudsman is as follows: Susan Hunter Building 15, Room 225 1864 Fourth Street Wright-Patterson AFB OH 45433-7130 FAX: (937) 225-5036; Comm: (937) 904-4407 All responsible organizations may submit a white paper which shall be considered. The purpose of this modification is to change whitepaper/proposal submission dates for FY12 and FY13 in the following section: Replace IV.3. SUBMISSION DATES AND TIMES in its entirety with the following: 3. SUBMISSION DATES AND TIMES: It is recommended that white papers be received by the following dates to maximize the possibility of award: FY 11 should be submitted by 13 Aug 2010; FY 12 by 1 Aug 11 and FY 13 by 1 Aug 12. White papers will be accepted until 2pm Eastern time on 30 September 2013, but it is less likely that funding will be available in each respective fiscal year after the dates cited. FORMAL PROPOSALS ARE NOT BEING REQUESTED AT THIS TIME. No other changes have been made.
 
Web Link
FBO.gov Permalink
(https://www.fbo.gov/spg/USAF/AFMC/AFRLRRS/BAA-10-09-RIKA/listing.html)
 
Record
SN02502265-W 20110720/110719000623-6dc7a884e23d24afdb21f1d6afc6cea6 (fbodaily.com)
 
Source
FedBizOpps Link to This Notice
(may not be valid after Archive Date)

FSG Index  |  This Issue's Index  |  Today's FBO Daily Index Page |
ECGrid: EDI VAN Interconnect ECGridOS: EDI Web Services Interconnect API Government Data Publications CBDDisk Subscribers
 Privacy Policy  Jenny in Wanderland!  © 1994-2024, Loren Data Corp.