Instructions

COLUMN A: Complete the "Page" column. This is the page number from the RFP located in the upper right hand corner of the page. Do not include the total page number. Enter only the page number where the topic begins.

COLUMN B: Complete the "Section/Paragraph" column with the applicable section and paragraph number (if applicable) of the RFP. For example: B2, C, or L5.1.2. For a section and paragraph number reference do not place a dot between the letter and the first number. Additional subparagraph references should be separated with a dot regardless of the format in the RFP, for example, L5.1.2.a. Do not including any other extraneous identifiers or other information other then instructed here. If the reference is to a CLIN, Clause, Appendix, or Attachment etc. the entry goes in the next column. At a minimum you will always insert at least the Section letter A through J in this column.

COLUMN C: Complete the "CLIN/Clause/Other" column. Insert the CLIN, Clause, Provision, Appendix, or Attachment number. For example: CLIN 0001, 52.217-8, Appendix A, or Attachment L3. Insert the section letter only in the Column B. This column will be completed only when there is not a more precise RFP reference number. NOTES: CLINs are in Section B. Most sections contain clauses so ensure you reference the correct section.

COLUMN D: Complete the Questions/Comments/Recommendations column. Start the question by referencing the topic. This may help the sort process. For example: Minimum Qualifications Checklist or Performance Area 10. Then insert the question or comment.

Issues must be submitted to the Contracting Officer and Contract Specialist listed in L.

&"Aptos"&10&K000000 Confidential - Oracle Restricted \Employees Only&1#_x000D_

_x000D_&1#&"Aptos"&10&K000000 Confidential - Oracle Restricted \Employees Only

Q&A

Offerings that fully satisfy all standard onboarding criteria under Section G12(a) (First-Party) or Section G12(b) (Third-Party) are eligible for ordering immediately upon catalog inclusion, without prior KO negotiation.

Offerings submitted under Section G12(c) (non-standard additions) only become active and eligible for ordering after the KO formally approves the request and notifies the Contractor in writing, and any required bilateral contract modification is executed.

2 29-30 G12 Please confirm the Government will establish a review timeframe for G12(c) requests. The Government confirms and clarifies.

Offerings meeting all G12(a) or G12(b) criteria are eligible for immediate ordering upon inclusion in the catalog, without KO negotiation.

Offerings submitted under G12(c) (non-standard additions) only become eligible for ordering after explicit KO review/notification and the execution of any required bilateral contract modification.

Because G12(c) requests require individualized technical and price evaluations, the Government will not establish a fixed, guaranteed approval timeframe for G12(c) actions.

COM (Commercial): Designates commercial Cloud Services operating within the Offeror’s general public/commercial cloud infrastructure that do not possess a dedicated DoD Provisional Authorization (PA) or DoD-specific boundary controls. In the schema, COM is utilized for commercial list price benchmarking, commercial catalog mapping, or unclassified non-sensitive commercial evaluation services.

IL2 (DoD Impact Level 2): Designates CSOs that possess an active DoD Provisional Authorization (PA) (or FedRAMP Moderate/High equivalency formally recognized by DISA) authorized to host DoD Non-Controlled Unclassified Information (Non-CUI) and publicly releasable DoD mission data within the evaluated DoD security boundary pursuant to the DoD CSP SRG.

8 CDRL A004 Attachment A, csoParentServiceSchema tab - availableforUsage In CDRL A004 Attachment A, csoParentServiceSchema tab - impactLevel, "Available for Usage" values are only True or False. Can the Government clarify how we should identify a service that is available in some regions but not all regions? The Government provided an update to Attachment J-3 to add a regionsAvailable field to the parent service schema.

availableForUsage remains a parent-level Boolean. If the Cloud Service is available for use in any Government-authorized region for the applicable Impact Level, the Offeror shall set availableForUsage to True.

regionsAvailable shall identify the specific region(s) where the Cloud Service is available. Enter region values using the format defined in Attachment J-3 (pipe-separated if multiple regions apply).

Regional availability shall be reflected in the catalog through these fields rather than through the Exception Log, unless a separate PWS exception is required.

9 29 Section G12 G12 states the Offeror “[m]ust include the signed Mandatory addendum to License Agreements and Service Level Agreements (see Section H20) for each offering.” However, the Mandatory Addendum under Section H20 applies to 3SPs, not CSPs. Sections 6.2.11.12 and 13 also appear to suggest the Addendum encompasses the requirements that apply to 3SPs.

(a) Can the Government clarify whether the Mandatory Addendum only applies to third-party offerings?

(b) Can the Government clarify that the Mandatory Addendum is required once per third party service provider (rather than for every third-party offering)?

(c) Can the Government confirm that for 3SPs that provide BYOL products, which are 'price-free', do not require a signed 3SP mandatory addendum?

The Government clarifies:

(a) Confirmed. The Section H20 Mandatory Addendum applies exclusively to Third-Party Service Providers (3SPs) offering products in the marketplace. First-party Cloud Service Offerings (CSOs) are governed directly by the prime contract terms and do not require a separate Section H20 Addendum. The solicitation is amended to remove the reference to the Section H20 Addendum under Section G12(a)(4)

(b) Confirmed. The Section H20 Mandatory Addendum is executed once per 3SP / master license agreement, not per individual SKU or meter.

(c) Confirmed. In accordance with Section G12(b)(2)(ii), for Bring Your Own License (BYOL) offerings, no additional terms and conditions or signed addenda are presented to or required of the Government, as licensing is managed independently between the customer and software vendor.

10 29 G12(a) Section G12(a)(4) requires a signed Mandatory Addendum per H20 for First-Party Offerings, but H20's addendum language appears tailored to Third-Party Service Providers. Please clarify whether G12(a)(4) was intended to apply to First-Party Offerings, and if so, what the Contractor is expected to sign given it is already bound by the UCM Core contract terms.

The Government clarifies. The requirement in Section G12(a)(4) referencing the Section H20 Mandatory Addendum for First-Party offerings was an inadvertent cross-reference error. Native First-Party offerings are provided directly under the prime contract and do not require a signed Section H20 Addendum. The solicitation is amended to address the changes.

11 39 H14 (a) Section H14 requires added or modified offerings to be made available in the Catalog within 24 hours. Given that fully authorized services launch new features weekly, this requirement would result in weekly catalog submissions, creating a significant review and maintenance burden for the Government. We recommend striking or revising the 24-hour requirement in favor of a periodic submission cadence (e.g., quarterly) aligned with the existing CDRL A004 delivery schedule. The Government declines the recommendation. The 24-hour requirement does not mandate daily or weekly catalog submissions. Catalog schema files are submitted on a standard monthly cadence per CDRL A004.

The 24-hour rule is an operational deployment SLA: once a new or modified service is formally approved under the Section G12 modification process, the Contractor must make that approved offering visible on the live console within 24 hours to prevent capability deployment delays for end-users.

12 24 6.2.11.1 Can the Government explain the intent of the requirement, under PWS Section 6.2.11, to restrict TS services until directed by the JWCC KO? Would the KO's approval of the JWCC Catalog suffice for TS services to be offered? The concern is the potential gap in availability of TS Services until KO approval when there are current JWCC customers utilizing TS services that are mission critical that could negatively impact existing or time sensitive production workloads.

"The Contractor’s JWCC UCM Core Console shall be available at all offered classification levels and ILs. Services included in the TS Console shall be restricted to prevent fulfilling orders, provisioning, deploying, cloud operations, schedule non-provisionable or deployable JWCC UCM Core Services (e.g., Cloud Support Packages) until directed by the JWCC KO." The Government clarifies. The restriction on fulfilling, provisioning, and deploying Top Secret (TS) services until directed in writing by the JWCC UCM Core KO is an intentional security and governance safeguard. While commercial offerings may achieve technical provisional authorization, TS environment operations require verification of final facility clearances (FCL), operational accreditation, secure connectivity (DoD CAP/BCAP traversal), and execution of required security documentation (e.g., DD Form 254, Co-Use Agreements).

KO catalog approval alone does not constitute authorization to initiate live classified operations; explicit written authorization from the JWCC UCM Core KO is required before the TS Console can fulfill orders. Existing mission partners transitioning to JWCC UCM Core will be coordinated during the 30-day post-award onboarding window to ensure continuous mission support without operational disruption

Please confirm that this requirement does not apply to third-party tactical edge devices. The Government clarifies. The specific requirement in Section G12(b)(2) referencing PWS Section 6.2.11.6 (Bring Your Own License – BYOL) and Section 6.2.11.7 (no markup on third-party marketplace software) applies to third-party software, applications, and Software-as-a-Service (SaaS) offerings sold through the JWCC UCM Core Console / Marketplace. Physical hardware, including third-party Tactical Edge (TE) devices, is not governed by a BYOL software licensing model.

However, third-party TE devices offered under PWS Section 6.2.7 remain subject to commercial price parity: the unit price for the hardware device or appliance shall not exceed the original manufacturer's established commercial catalog list price (less negotiated contract discounts). In accordance with PWS Section 6.2.7, any allowable ancillary services and fees associated with TE device delivery, specialized ruggedized staging, CONUS pickup/shipping, or maintenance may be separately identified and priced in the JWCC UCM Core Service Catalog.

The language is revised within G12(b)(2).

17 29 G12 G12.a(4) requires First-Party Offerings to "include the signed Mandatory Addendum to License Agreements and Service Level Agreements (see section H20) for each Offering," with a link to those agreements "included in CDRL A004 for each Offering." This guidance is inconsistent, given:

H20 (1) and (2) encompass overall scope of JWCC offerings. However H20 (3) is specific to Third Party Marketplace items and would not apply to G12a(4). It seems that clause H12 explicitly covers First-Party CSP offerings and that G12a(4) should not require the H20 Addendum.

L6, TAB C requires formatting "strictly according to the field names, types, and constraints" of the three defined schemas, none of which includes a license agreement or SLA field. Will the Government add a defined field, or confirm the link is delivered outside CDRL A004?

G12 gives two locations for the same link. G12.a(4) requires it in CDRL A004; the closing paragraph of G12 requires all agreements "be hosted at the link incorporated in H20." Which controls?

Additionally, "For each Offering" is unworkable. Thousands of offerings are governed by a handful of common agreements, and H14.a requires added or modified offerings to be available "within 24 hours" — which a per-offering signature cycle cannot meet.

Given the above inconsistencies, we request that the existing G12a(4) language be replaced with "Must adhere to H12 terms." The Government clarifies and accepts the Offeror’s recommendations in part:

First-Party Offerings & Clause Applicability: The Government confirms that native First-Party Offerings are directly governed by the terms, conditions, and order of precedence established in Section H12 (DISA's Contract Takes Precedence Over Vendor's Standard Commercial Terms and Conditions) and the contract's standard commercial clauses (FAR 52.212-4). Section H20 applies specifically to Third-Party Marketplace Service Providers (3SPs). The requirement in Section G12(a)(4) mandating a signed Section H20 Mandatory Addendum for First-Party offerings will be updated/deleted to reflect changes.

Execution Cadence ('For Each Offering'): The Government confirms that licensing agreements and SLAs are not required to be executed on an individual SKU-by-SKU basis. Enterprise-level commercial terms of service and SLAs apply across common product families.

Hosting Location & Schema Alignment: Offerors are not required to alter the tabular database schemas in CDRL A004 / Section L6 TAB C to insert license text. The master repository link to the Contractor's commercial terms and SLAs (incorporating Section H12 / H20 compliance) shall be provided via the Contractor Cloud Information Portal / Ordering Guide Inputs (CDRL A001) and referenced at the contract level, rather than embedding individual agreement URLs within the CDRL A004 pricing tables.

The clarifying language is provided within the amendment.

In Attachment J-3 (csParentServiceSchema), the [ILX]_AuthorizationTimeline fields are designated as Required: No (Optional). Offerors are not required to provide a timeline if one is not established.

Where an Offeror plans to submit an un-authorized service for DoD authorization, this field allows the vendor to indicate its estimated submission timeframe (e.g., 'Q3 FY27' or 'Submitted in Jan 2024' as shown in Sheet 4). This supports Government visibility into upcoming service pipelines in alignment with PWS Section 6.1.3 ('Demand Signal and Feasibility Plans'). The field will remain optional in the schema.

To maintain relational integrity and automated database parsing, each discrete PWS requirement exception must be submitted as an individual row in Tab 2 (csExceptionSchema), linked by the parent csShortName. Submitting multiple comma-separated exceptions within a single text cell is prohibited as it prevents automated compliance tracking.

Third-party marketplace offerings shall be represented within the existing three-table schema structure by designating offeringIndicator as 'Third-Party' in Tab 1 (csParentServiceSchema). The Government will not establish a separate schema; third-party offerings link through csShortName to itemized pricing in Tab 3 (csPricingSchema).

28 N/A J7 Block 14 indicates that the JWCC UCM Core Catalog must be submitted as a Comma Separated Values (CSV). CSV files cannot be multi tabular, necessitating submission of separate files for each schema. Please confirm this understanding and update J-7. The Government confirms. (Note: references to schema tabs within the following response have been updated and are reflected in the amendment.)

Because individual CSV files cannot contain multiple worksheets, Offerors submitting in CSV format shall provide three separate, relationally linked CSV files corresponding to the three schemas: (1) csParentServiceCatalog.csv, (2) csExceptionLog.csv, and (3) csPricingCatalog.csv. Alternatively, Offerors may submit a single Microsoft Excel workbook (.xlsx) containing the three defined tabs.

The solicitation is amended to address the changes.

The monthly submission of the structured relational dataset pursuant to CDRL A004 satisfies the delivery requirement of Section G12(a)(3) and Section G12(b)(3). Change tracking is captured directly within Table 1 (csParentServiceSchema) via the csChangeType field (with permissible values: Add, Modify, Remove, Deprecate) and the notes field.

For routine catalog additions and modifications, submitting the updated dataset with the appropriate csChangeType populated fulfills the requirement without necessitating a separate narrative report document. The Government revised Section G12 to conform the deliverable title to match Section J: 'CDRL A004: JWCC UCM Core Service Catalog'.

32 43-49 Section H The Addendum states it is for Third Party Providers, but elsewhere (e.g. G12) it indicates it is for 1st Party offerings as well. Please confirm if it should be signed by the CSP, 3P Marketplace Providers, or both. The Government clarifies. The Mandatory Addendum in Section H20 applies exclusively to Third-Party Marketplace Service Providers (3SPs) and must be signed by the authorized representative of the 3SP.

The prime CSP does not sign the Section H20 Addendum for its own native (First-Party) offerings. The CSP’s native offerings are directly bound to the Government via the prime contract and Section H12 (DISA’s Contract Takes Precedence Over Vendor’s Standard Commercial Terms and Conditions). The solicitation will be amended to address the changes.

33 99 Section L6, Volume IV – Price Submission Instructions; Tab C, “JWCC UCM Core Service Catalog”; catalog minimum-details list Will the JWCC UCM Core catalog identify the underlying processor manufacturer, processor generation, and accelerator capabilities associated with each compute or bare-metal Cloud Service Offering? The Government clarifies. (Note: references to schema tabs within the following response have been updated and are reflected in the amendment.)

The JWCC UCM Core Catalog database schemas (Attachment J-3) do not contain separate, dedicated columns for processor manufacturer, processor generation, or accelerator type.

Instead, consistent with commercial cloud catalog naming conventions, Offerors shall identify these hardware characteristics within the title and/or description fields of Table 3: CS Pricing Catalog (csPricingSchema) for compute, GPU, and bare-metal SKUs (e.g., instance family, vCPU count, memory, processor architecture, and accelerator type such as 'GPU - 2xA100 Instance', as illustrated in the Attachment J-3 pricing examples). Full underlying technical specifications and chip architectures remain accessible to Mission Owners via the Contractor’s Cloud Information Portal (referenced via productUrl), the Contractor's Calculator (PWS Section 6.2.4), and CDRL A009 for Edge Devices.

34 0094 L4 Public Commercial Catalog – Must Volume II Tab E include a generally available public commercial catalog that is in the market at proposal, or is a commercial price list or analog (including prices sold commercially other than via a public cloud website) sufficient? The Government clarifies. In Volume II, TAB E, the 'commercial service catalog' is submitted as technical supporting documentation to substantiate commercial availability and functionality of proposed CSOs (to support Gate Criteria and Section M technical evaluations) and must represent generally available commercial offerings in the market at proposal submission.

Pursuant to Section L2.2, all pricing information must be completely redacted and excluded from Volume II, TAB E. Any commercial price lists, commercial unit prices, or rate analogues shall be submitted exclusively within Volume IV (Price), TAB C in accordance with Section L6 and Attachment J-3. The solicitation is amended to address the changes.

Specifically, when Tactical Edge (TE) devices are returned to the Contractor, the Contractor shall either dispose of or sanitize the TE device in accordance with applicable requirements of the DoD CSP SRG or ICD 503 (as determined by the CSO’s authorization) and Attachment J-2 ('JWCC UCM Core DD254'), following procedures approved by the cognizant Authorizing Official (AO). Once properly sanitized and validated in accordance with the AO's procedures and security classification guidelines, reuse of hardware is permissible. The solicitation is amended to address the changes.

(a) “Seamless connectivity” refers to the integration and interoperability capabilities required by the PWS to securely connect systems/cloud environments, applications, and data sources. Applicable capabilities include industry-standard network protocols, secure data transfer, VPN integrations, APIs, and multi-environment peering, as described in PWS Sections 6.2 and 6.4.

(b) Examples of “diverse systems and data sources” may include hybrid cloud environments and other internal or external systems, applications, and data sources that Mission Owners need to integrate in support of their requirements. The specific systems and integration needs will depend on the applicable mission and Task Order.

(a) 'Base or minimum requirements' establishes the mandatory operational and security baseline that all contracted offerings must satisfy. Services offering capabilities beyond this baseline remain fully subject to all applicable contract terms, clauses, security mandates, and pricing rules.

(b) A Contractor may offer a commercial service in unclassified environments (IL2/IL4/IL5) without deploying it to classified regions, provided the service meets all applicable PWS requirements for its authorized Impact Level, and the Contractor formally documents the classification/regional disparity in Tab 2: CS Exception Log Schema (csExceptionSchema) pursuant to Section L6 TAB C, PWS Section 6.2.5, and CDRL A006.

41 15 6.2 "All authorized CSOs must be capable of operating at the operational and TE levels, including in DDIL environments." Regarding the scope of this requirement, does the Government distinguish between regional/strategic CSOs and those designed for tactical Edge?

(a) New peering locations are strategic enterprise network connection points (e.g., new DISN Core Data Centers or Boundary Cloud Access Points (BCAPs)) identified based on Combatant Command operational requirements and designated in formal written notification issued by the Contracting Officer.

(b) In accordance with PWS Section 6.2.3.4, the Contractor has 12 months from Government notification to establish compliant peering and verify latency.

(c) The sub-8-millisecond latency requirement is measured between the designated Government boundary connection point (e.g., BCAP meet-me point/demarcation router) and the Contractor’s nearest authorized cloud edge/peering gateway servicing that geographic theater.

43 17 6.2.3.3 "Total bandwidth capacity of at least 40 gigabits per second, utilizing redundant links, to peer with the DoD on each continent." Given AI/ML objectives, does the Government believe 40 Gbps is sufficient? Does "40 Gbps utilizing redundant links" refer to aggregate including redundancy, or usable capacity? The Government clarifies. The requirement for 'at least 40 gigabits per second, utilizing redundant links, to peer with the DoD on each continent' establishes the minimum usable baseline bandwidth capacity that must remain available for mission traffic, supported by diverse and redundant physical circuits to ensure high availability.

The 40 Gbps represents the mandatory contract minimum across all continents; individual Task Orders may procure additional bandwidth, dedicated cross-connects, or higher throughput configurations under applicable CLINs to support localized, data-intensive AI/ML mission requirements.

44 17 6.2.3.4 What constitutes a "new DoD location" for purposes of the 12-month peering requirement? Is there a minimum threshold? The Government clarifies. For the purposes of the 12-month peering requirement in PWS Section 6.2.3.4, a 'new DoD location' may include, but is not limited to, a DISA Defense Information Systems Network (DISN) Core Data Center, Boundary Cloud Access Point (BCAP), or Combatant Command enterprise network connection facility designated in writing by the Contracting Officer.

The 12 month peering requirement applies when the Government designates a location as a new DoD peering location under PWS Section 6.2.3 (bullet 4). The establishment of a temporary, tactical, or mission partner location does not, by itself, constitute designation of a new DoD peering location.

When connectivity is available, the Contractor’s key-management capability shall support standard key distribution, rotation, and recovery functions consistent with the CSO’s authorization, including over-the-network automated re-keying and rotation upon restored connectivity.

When connectivity is unavailable, the Edge Device solution shall support offline/local key-management operations sufficient to protect data and maintain required cryptographic services until connectivity is restored. This includes the ability to use pre-positioned or locally resident key material, perform local or policy-driven key operations (including manual/fill-device zeroization where applicable) without reach-back, and recover or re-synchronize keys when connectivity returns. Continuous remote key distribution, rotation, or recovery is not required while the device is fully disconnected.

The specific categories of keys to be managed (e.g., data-at-rest, data-in-transit, device identity, application, or COMSEC key material) depend on the classification level, the CSO’s authorization boundary, and the Mission Owner’s intended use of the Edge Device. Specific operational key schedules and COMSEC custodian procedures will be designated on individual Task Orders based on mission classification level.

Upon award, the Contractor shall document key-management design, processes, and DDIL limitations in the Controlled Cryptographic Item Management Plan (CCIMP) under PWS Section 6.3.6 and in CDRL A009, Edge System Processes and Documentation.

47 20 6.2.7.3.1 — Task 2 – Operations Can the Government define what "control the magnitude of these signatures" means in the context of Edge Device emanation requirements? (a) Does this refer to specific TEMPEST standards (e.g., CNSSAM TEMPEST/01-13)? (b) Will the Government provide measurable thresholds or reference applicable emanation specifications? The Government clarifies:

(a) “Control the magnitude of these signatures” refers to providing sufficient characterization of the Edge Device’s electromagnetic, acoustic, thermal, and other device-specific emanations across its operational states to enable the Government to assess and manage those signatures consistent with the applicable mission environment. PWS Section 6.2.7.3 does not establish a separate universal TEMPEST requirement. Where additional signature-control measures are required for a particular mission or operating environment, those requirements may be identified at the Task Order level.

(b) PWS Section 6.2.7.3 requires device-specific emanations to be documented in CDRL A009, “Edge System Processes and Documentation.” Separately, PWS Section 6.2.7.4.8 requires the applicable deployable Edge Device form factor to be certified as meeting MIL-STD-810H. The MIL-STD-810H requirement does not establish a universal electromagnetic, acoustic, thermal, or TEMPEST threshold.

48 22 6.2.7.6 — Task 2 – Operations (a) Does "dispose" preclude refurbishment and reuse of Edge Devices after sanitization per NIST SP 800-88? (b) If refurbishment is permitted, what sanitization standard must be met before redeployment? (c) Does the Contractor retain ownership of returned Edge Devices, or does title transfer to the Government upon deployment? The Government clarifies:

(a) No. The term 'dispose' does not preclude refurbishment and reuse. In accordance with PWS Section 6.2.7.6, the Contractor shall 'either dispose of or sanitize the Edge Device'. Once properly sanitized and certified in accordance with AO-approved procedures, hardware may be refurbished, redeployed, or reused within authorized classification boundaries.

(b) Sanitization must comply with NIST SP 800-88 (latest version, 'Guidelines for Media Sanitization') or NSA/CSS Policy Manual 9-12, "Storage Device Sanitization and Destruction Manual," as determined by the data classification, the DoD Cloud Computing Security Requirements Guide (DoD CSP SRG),…