3-26TH10RFI Network Monitoring Solution - FINAL 03.18.2026.pdf

REQUEST FOR INFORMATION

NETWORK MONITORING SOLUTION

RFI # 26TH10RFI

RESPONSE DUE

FRIDAY, APRIL 10, 2026

2:00 p.m. MDT

QUESTIONS DUE

MONDAY, APRIL 6, 2026

11:00 a.m. MDT

Jordan School District Purchasing Department

Senior Buyer: Tonya Hodges, NIGP-CPP, CPPB 7905 South Redwood Road

West Jordan, Utah 84088-4601

Jordan School District RFI # 26TH10RFI Network Monitoring Solution

CONTENTS

PART 1: OVERVIEW AND NOTICES

1. PURPOSE OF REQUEST FOR INFORMATION (RFI)

2. NOTICES

3. QUESTION AND ANSWER PERIOD

4. SUBMIT VIA U3P BONFIRE

5. PROTECTED INFORMATION

A. PROCESS FOR REQUESTING NONDISCLOSURE

B. REDACTED COPY

PART 2: SCOPE OF WORK AND REQUESTED INFORMATION

1. RFI INTENT

2. RESPONSE GUIDANCE

3. BACKGROUND AND ENVIRONMENT OVERVIEW

A. NETWORK ARCHITECTURE

B. DEPLOYMENT MODEL

C. OPERATIONAL MONITORING REQUIREMENTS

D. ALERTING AND INCIDENT RESPONSE

E. DEVICE TELEMETRY AND HARDWARE MONITORING

F. PERFORMANCE AND TRAFFIC ANALYSIS

G. NETWORK VISUALIZATION AND MAPPING

H. NETWORK ADDRESS AND DEVICE TRACKING

I. LOGGING, EVENT CORRELATION, AND HISTORICAL ANALYSIS

J. CONFIGURATION MANAGEMENT AND CHANGE TRACKING

K. WIRELESS NETWORK MONITORING

L. AUTOMATION AND SYSTEM INTEGRATION

M. CLIENT ACCESS AND MOBILE SUPPORT

N. SUPPORT AND OPERATIONS

O. COST STRUCTURE

4. RFI RESPONSE MATERIALS

A. ATTACHMENT A: VENDOR DIFFERENTIATING CAPABILITIES

B. ATTACHMENT B: YOUR COMPANY’S TECHNICAL RESPONSE

C. ATTACHMENT C: PRODUCT IDENTIFICATION AND LICENSING MAPPING

D. ATTACHMENT D: CLAIM OF BUSINESS CONFIDENTIALITY (IF APPLICABLE)

PART 3: RFI EVALUATION

REQUEST FOR INFORMATION

NETWORK MONITORING SOLUTION

RFI # 26TH10RFI

This Request for Information (RFI), having been determined to be the appropriate method for gathering information for Jordan School District (JSD), is designed to provide interested vendors with sufficient information to submit responses to this RFI meeting the intent of the request. It is not intended to limit a vendor’s content or exclude any relevant or essential data.

This RFI is issued in accordance with State of Utah Procurement Code, Utah Code Annotated (UCA) Chapter 63G-6a, and applicable Rules found in the Utah Administrative Rule (UAR). If any provision of this RFI conflicts with the UCA or UAR, the UCA or UAR will take precedence.

PART 1: OVERVIEW AND NOTICES

The reference number for this RFI is 26TH10RFI. This number should be referred to on all responses, correspondence, and documentation relating to this RFI.

1. PURPOSE OF REQUEST FOR INFORMATION (RFI)

The JSD Information Systems (IT) department is seeking information on solutions for enterprise network monitoring and visibility.

This RFI is intentionally structured differently from a traditional checkbox-driven or compliance-only RFI. The evaluation team has decades of experience reviewing vendor responses and recognizes that many RFIs result in copy-and-paste marketing language, generic product descriptions, or large addenda of datasheets that do not directly answer the questions being asked. That is not the objective of this RFI.

The intent of this RFI is to create an opportunity for vendors to help Jordan School District truly understand, in technical and operational detail, how their solution works in practice — including architecture, workflows, dependencies, tradeoffs, and limitations.

Vendors are encouraged to:

• Treat this as a technical conversation, not a marketing exercise.

• Explain how capabilities are implemented, not just that they exist.

• Clearly identify where functionality is core vs. add-on vs. separate product.

• Be transparent about assumptions, prerequisites, and areas of partial support.

JSD has deliberately structured this RFI to make it easy to respond to directly, with guided sections and clear context about current workflows and constraints. In return, vendors are asked to:

• Provide clear, concise, and well-structured answers.

• Avoid excessive attachments or datasheet dumps.

• Make responses easy to read and easy to map to the questions asked.

Responses that prioritize clarity, technical depth, and honesty will be more valuable to the evaluation process than responses that prioritize breadth or marketing language.

Based on RFI responses, JSD may:

• Invite select vendors to participate in a Proof of Concept (POC).

• Issue a subsequent RFP with defined technical requirements and minimum capabilities.

• Select a preferred solution and conduct a subsequent pricing-only solicitation.

2. NOTICES

An RFI is a request for information only. An RFI is not a solicitation for quotations, bids, or proposals. Vendors should not include pricing information in RFI responses. An RFI is not a procurement process and may not be used to enter into a contract or to make a purchase.

Information submitted in response to this RFI may be used to develop a subsequent solicitation. Failure to respond to this RFI will not disqualify any vendor from participation in a subsequent solicitation.

All costs associated with preparing and responding to this RFI are the sole responsibility of the responding vendor and will not be reimbursed by JSD. All materials submitted in response to this RFI will become the property of JSD.

JSD reserves the right to cancel this RFI at any time.

3. QUESTION AND ANSWER PERIOD

All questions should be submitted through Utah Public Procurement Place Bonfire (U3P Bonfire) at https://utah.bonfirehub.com during the designated time for questions (Q&A period) listed on U3P Bonfire. Questions submitted through any other channel will not be answered. Questions may be answered in the order that they are submitted or may be compiled into one document and answered via an addendum after the Q&A period has ended.

Answers disseminated by JSD through U3P Bonfire via Q&A or via Public Notice will constitute an addendum to this RFI. Addenda may modify the scope of this RFI. Vendors should periodically check U3P Bonfire for answered questions and addenda before the due date.

4. SUBMIT VIA U3P BONFIRE

RFI responses must be submitted digitally via U3P Bonfire at https://utah.bonfirehub.com by the deadline posted on U3P Bonfire. Late submissions will not be accepted.

When submitting an RFI response, allow sufficient time to complete the online forms and to upload documents. The RFI will end at the deadline. If a vendor is in the middle of uploading materials when the deadline arrives, the system will stop the upload process and the response will not be accepted by U3P Bonfire.

5. PROTECTED INFORMATION

The Government Records Access and Management Act (GRAMA), UCA 63G-2-305, provides in part that:

https://utah.bonfirehub.com/ https://utah.bonfirehub.com/ the following records are protected if properly classified by a governmental entity:

(1) trade secrets as defined in Section 13-24-2 [Uniform Trade Secrets Act] if the person submitting the trade secret has provided the governmental entity with the information specified in Section 63G-2-309 [Confidentiality Claims];

(2) commercial information or nonindividual financial information obtained from a person if:

(a) disclosure of the information could reasonably be expected to result in unfair competitive injury to the person submitting the information or would impair the ability of the governmental entity to obtain necessary information in the future;

(b) the person submitting the information has a greater interest in prohibiting access than the public in obtaining access; and

(c) the person submitting the information has provided the governmental entity with the information specified in 63G-2-309 [Confidentiality Claims];

(7) information submitted to or by a governmental entity in response to a request for information, except, subject to Subsections (1) and (2), that this Subsection (7) does not restrict the right of a person to have access to the information, after:

(a) a contract directly relating to the subject of the request for information has been awarded and signed by all parties; or

(b)

(i) a final determination is made not to enter into a contract that relates to the subject of the request for information; and

(ii) at least two years have passed after the day on which the request for information is issued;

A. PROCESS FOR REQUESTING NONDISCLOSURE

Any vendor requesting that a record be protected shall complete and include with the RFI response a Claim of Business Confidentiality Form (see Attachment D), including a concise statement of reasons supporting the claim of business confidentiality (UCA 63G-2- 309[1]) and a redacted copy of their RFI response clearly marked “Redacted Version.”

Vendor acknowledges that notations in the header, footer, or watermark of the RFI response will not be considered sufficient to constitute a request for nondisclosure of protected/proprietary information.

B. REDACTED COPY

If a vendor submits a response that contains information claimed to be business confidential or protected information, the vendor should submit one electronic redacted copy of the RFI response for public release, with all protected business confidential information either blacked-out or removed, clearly marked as “Redacted Version.”

Vendor acknowledges that their RFI response or redacted copy will be made public upon JSD’s receipt of a GRAMA request. Vendor will not be notified of any GRAMA request made to JSD for the vendor’s RFI response. If the vendor submits a redacted copy, then JSD will respond to a GRAMA request for vendor’s RFI response with the redacted copy. However, if a vendor fails to submit a redacted copy, then JSD will respond to a GRAMA request with the vendor’s RFI response, which will result in the vendor’s protected/proprietary information, if any, being made public.

PART 2: SCOPE OF WORK AND REQUESTED INFORMATION

1. RFI INTENT

The Information Systems (IT) department is seeking information on solutions for enterprise network monitoring and visibility. The objective of this RFI is to:

• Gather detailed information on how vendors implement network monitoring, device telemetry collection, alerting, and operational performance analysis capabilities..

• Identify architectural dependencies, limitations, scalability considerations, and operational requirements of each solution.

• Evaluate how solutions support hybrid environments consisting primarily of on-premises infrastructure with optional cloud-based services.

• Assess vendor support models, automation capabilities, and long-term platform extensibility.

Based on RFI responses, JSD may:

• Invite select vendors to participate in a Proof of Concept (POC).

• Issue a subsequent RFP with defined technical requirements and minimum capabilities.

• Select a preferred solution and conduct a subsequent pricing-only solicitation.

2. RESPONSE GUIDANCE

In compiling the RFI response, vendors should:

• Answer questions as written and provide detailed explanations of how capabilities are implemented.

• Avoid marketing brochures, generic product descriptions, or large datasheet submissions without explanation.

• Clearly indicate whether functionality is:

o Native o Add-on module o Third-party integration o Open-source dependency

Clearly identify product names, editions, licensing tiers, or modules required to meet the requested functionality.

• Explain any architectural limitations, licensing implications, or deployment considerations that my affect implementation.

Do not include pricing quotes in the RFI response.

3. BACKGROUND AND ENVIRONMENT OVERVIEW

The following context is provided to assist vendors in understanding the operational environment and network architecture within JSD. This information is intended to explain why certain monitoring capabilities are required and to assist vendors in providing relevant responses.

A. NETWORK ARCHITECTURE

JSD operates a large distributed network environment consisting of multiple campuses and administrative facilities connected through centralized core infrastructure.

Network devices include:

• Core switches and routers

• Distribution and access layer switching infrastructure

• Wireless access points and controllers

• Firewalls and security appliances

• Internet edge connectivity

• Voice and unified communication systems

Network monitoring must support multi-site environments with centralized visibility while allowing operational monitoring across distributed locations.

B. DEPLOYMENT MODEL

JSD strongly prefers solutions that support on-premises deployment models with optional cloud services for mobile access, alert delivery, or remote monitoring.

Solutions that require full cloud-hosted monitoring infrastructure or rely exclusively on SaaS-based management platforms may not meet operational requirements.

Preferred architectures include:

• Fully on-premise monitoring platforms

• Hybrid systems with local collectors and optional cloud services

• Platforms that retain operational monitoring and telemetry data within the local environment

C. OPERATIONAL MONITORING REQUIREMENTS

JSD requires comprehensive monitoring across multiple layers of the network infrastructure, including:

• Network device health and performance

• Link utilization and error conditions

• Environmental and hardware health metrics

• Traffic analysis and capacity planning

• Wireless performance and client experience monitoring

Monitoring systems must provide clear operational visibility, historical data analysis, and automated alerting for network events and anomalies.

D. ALERTING AND INCIDENT RESPONSE

The monitoring platform must support multiple alerting mechanisms to notify IT staff of operational issues in real time.

Preferred alerting capabilities include:

• Email alerts

• SMS/text message alerts

• Mobile push notifications

• Desktop notifications

• Webhook integrations with collaboration platforms (such as Slack)

Alerts should support threshold-based monitoring, anomaly detection, and customizable escalation workflows.

E. DEVICE TELEMETRY AND HARDWARE MONITORING

Network infrastructure monitoring must include the ability to collect and interpret device telemetry through SNMP or similar protocols.

This includes monitoring for:

• Power supply status

• Fan status and hardware failures

• Device temperature sensors

• Interface status and operational statistics

Solutions should also allow direct access to OID libraries for monitoring vendor-specific telemetry, such as:

• SFP optical light levels

• SFP voltage readings

• SFP temperature readings

F. PERFORMANCE AND TRAFFIC ANALYSIS

JSD requires visibility into both network utilization and application traffic patterns.

Solutions should support:

• Bandwidth monitoring

• Interface utilization tracking

• NetFlow or sFlow traffic analysis

• Packet-level inspection for identifying latency, jitter, and packet loss conditions

These capabilities are important for troubleshooting performance issues and identifying congestion or abnormal traffic patterns.

G. NETWORK VISUALIZATION AND MAPPING

The monitoring system should provide dynamic network visualization capabilities, including:

• Network topology maps

• Device dependency mapping

• Link state monitoring

• Link speed identification

• Configurable link thresholds

Visualization tools should allow administrators to quickly identify infrastructure failures or degraded network conditions.

H. NETWORK ADDRESS AND DEVICE TRACKING

JSD requires tools to assist in tracking device connectivity and troubleshooting endpoint behavior.

Preferred capabilities include:

• IP address lookup

• MAC address lookup

• Historical IP/MAC address correlation

• Access to ARP and FDB tables

• Historical tracking of endpoint network associations

These tools assist IT staff in troubleshooting connectivity and identifying devices within the network.

I. LOGGING, EVENT CORRELATION, AND HISTORICAL ANALYSIS

The monitoring platform must support centralized log collection and analysis capabilities.

Required capabilities include:

• Log retention for a minimum of 2–6 weeks

• Full-text search across collected logs

• Correlation of logs with network events

• Network event timelines and audit trails

The platform should also support:

• Custom database queries for advanced troubleshooting

• Correlation between network telemetry, logs, and configuration changes

J. CONFIGURATION MANAGEMENT AND CHANGE TRACKING

The monitoring platform should include configuration management capabilities for network devices.

Desired functionality includes:

• Automated configuration backups

• Configuration comparison with change detection

• Historical configuration versioning

• Firmware version tracking for primary and secondary firmware images

These capabilities assist with auditing changes and maintaining configuration consistency across the environment.

K. WIRELESS NETWORK MONITORING

Wireless infrastructure monitoring should include visibility into wireless access point performance and SSID-level metrics.

Preferred capabilities include:

• Wireless access point health monitoring

• SSID performance metrics

• Client performance indicators

• Wireless infrastructure alerts

L. AUTOMATION AND SYSTEM INTEGRATION

The monitoring platform should support integration with other systems through modern automation interfaces.

Preferred capabilities include:

• REST-based APIs

• Automation integration with external tools

• Webhooks for alert forwarding

• Ability to integrate with other systems for future expansion

M. CLIENT ACCESS AND MOBILE SUPPORT

The platform should provide remote access capabilities for operational staff.

Desired access methods include:

• Web-based administration interface

• Mobile applications for both iOS and Android

• Secure remote monitoring capabilities for administrators

N. SUPPORT AND OPERATIONS

Vendors should describe their support offerings, including:

• Paid support models

• Availability of 24/7 support during support contract periods

• Escalation procedures for critical incidents

• Access to documentation, knowledge bases, and support resources

O. COST STRUCTURE

While pricing should not be included in the RFI response, vendors should describe the general licensing structure of their platform including:

• Licensing models (device-based, interface-based, subscription, etc.)

• Required modules or add-ons for full functionality

• Hardware or infrastructure requirements

4. RFI RESPONSE MATERIALS

Vendors that are interested in responding to this RFI should submit the following:

A. ATTACHMENT A: VENDOR DIFFERENTIATING CAPABILITIES

This section is the vendor’s opportunity to clearly and concisely explain why your solution stands out and why it should be seriously considered for further evaluation.

This is not a requirement to cover every feature. It is an opportunity to make a compelling technical case for your solution in a way that is easy to digest for evaluators.

Responses that are thoughtful, specific, and grounded in operational reality will be more impactful than broad or overly polished marketing statements.

Responses should be one (1) page maximum.

B. ATTACHMENT B: YOUR COMPANY’S TECHNICAL RESPONSE

Vendors are asked to provide detailed narratives on the following items from Part 2:

Scope of Work and Requested Information:

A. Network Monitoring supporting multi-site environments with centralized visibility while allowing operational monitoring across distributed locations.

B. On-premises deployment Models C. Operational Monitoring Requirements D. Alerting and Incident Response E. Device Telemetry and Hardware Monitoring F. Performance and Traffic Analysis G. Network Visualization and Mapping H. Network Address and Device Tracking I. Logging, Event Correlation, and Historical Analysis J. Configuration Management and Change Tracking K. Wireless Network Monitoring L. Automation and System Integration M. Client Access and Mobile Support N. Support and Operations O. Cost Structure

C. ATTACHMENT C: PRODUCT IDENTIFICATION AND LICENSING MAPPING

List all products, modules, or SKUs required to meet RFI capabilities.

D. ATTACHMENT D: CLAIM OF BUSINESS CONFIDENTIALITY (IF APPLICABLE)

If applicable, submit a Claim of Business Confidentiality Form (Attachment D) and a redacted copy of the RFI response.

PART 3: RFI EVALUATION

All RFI responses properly submitted will be accepted by JSD.

RFI responses will be evaluated by a JSD evaluation committee. Materials may be evaluated by anyone designated by JSD as part of the evaluation committee.

Information submitted in response to this RFI may be used to:

• Invite select vendors to participate in a proof of concept (POC).

• Issue a subsequent RFP with defined technical minimums.

• Select a preferred solution and conduct a subsequent pricing-only solicitation.

[The end.]

PART 3: RFI EVALUATION