Home Page

Project Focused on DNS, DHCP, and IP address management (IPAM) at RIT

The interface and workflows that administrators use to manage computer objects in CLAWS will change.

Project Overview

The ITS Netcomm team, eager to take ownership and drive the evolution of the DDI service, is excited to partner on this project that will integrate core network services into their team portfolio. The team recognizes this as the foundational step in the DDI service's lifecycle, paving the way for continuous product and service improvements beyond project completion. 

What are the goals of the project?

  • A reliable DDI service foundation in a future focused, scalable product solution

  • Remove DNS, DHCP, IPAM functionality from CLAWS

  • At the end of the project, transition from project to DDI service lifecycle

We understand that replacing a bespoke, incremental, internally developed system like CLAWS and it's rich feature set with commercial off the shelf (COTS) solution(s) may leave some ITS internal and external partners disappointed and will leave gaps in functionality, but COTSs provide a lot of benefits in creating reliable, sustainable foundations for the future.  

Share your concerns with the team using the form below.

Our project approach is, first and foremost, to work in ways that are aligned with our principles.  They are our guardrails.  This is not to say that they won't change, but 

  • They won't be changed from outside the core team

  • They won't change without intention and thoughtful conversation within the core team

  • They won't change frequently

Since this project is complex in nature and we anticipate learning important things we didn't know as we go along, we understand that

  • The closer the plan is today, the more accurate it will be.  We will strive to meet our next milestone, and future milestones will be adjusted according to what we've accomplished.   We will not work in phases, we work in a way that will support DDI lifecycle

  • Replacing a home grown system that provided rich functionality with COTS solution will leave gaps and disappoint people

  • We must embrace and embody continuous improvement 

  • We must strive to create plans of work achievable in regular time periods, planned at a regular cadence

  • We must welcome participants to the project conversation, with the expectation that new participants honor the principles

  • Our goal is to create a reliable, adaptable solution that lays the groundwork for future growth. We're not going to be everything to everybody.  

  • History matters, but we won't start from a place of status quo. Expect change.

  • We value the power of simplicity, even when it demands tough choices. We are willing to sacrifice some functionality to ensure our solutions are intuitive, reliable, and sustainable. Less is more, with intention.

  • We strive to provide frequent, clear, and honest communication. We'll embrace constructive dissent and the understand the value of learning from mistakes. We'll share what we can, when we can.

  • We'll focus on delivering value, not hitting dates. We adapt, learn, and iterate, prioritizing milestones as stepping stones. At the end of the project, seamless transition to DDI operational service support is key. We'll be outcome-driven, not deadline focused.

  • We strive to provide a standard suite of services equitably across internal and external stakeholders. No haves and have nots.

  • We all need to learn more in this space, no one knows it all. Everyone is expected to be a learner.

  • We'll ask why something was done for clarity of understanding, without judgment. We adhere to the Retrospective Prime Directive:

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

--Norm Kerth, Project Retrospectives: A Handbook for Team Review

Design Approach

  • Foundational, reliable & sustainable first; Future growth second

  • Modular/Interchangeable components

  • Standards-based

  • Enforce permission structures within the tool

  • Leverage mature off-the-shelf and open source for middleware functions

  • Beyond “start”-like webpages, no custom-developed user interfaces

Learn basics about DDI

DDI is shorthand for the integration of DNS, DHCP, and Internet Protocol Address Management (IPAM) into a united service or solution.  DDI comprises the foundation of core network services that enables all communications over an IP-based network.

Domain Name Server (DNS) can be thought of as the phone book for the internet.  It translates human readable domain names that we easily remember, like www.rit.edu into IP addresses which allows computers, servers, and other networked devices, each with their own unique IP addresses, to exchange information.

See the following for more information on DNS:

Dynamic Host Configuration Protocol (DHCP) is the standard mechanism to dynamically assign IP addresses within a network.  When a device (smartphone, laptop, etc.) joins a network it typically asks for an IP address from a DHCP server.  The server assigns an IP address and other parameters and then the device can communicate with both the internal network and the public internet.

See the following for more information on DHCP:

Internet Protocol Address Management (IPAM) is a method for planning, tracking, and managing IP address space on a network.  IPAM software tools can give network admins a real-time inventory of both used and unassigned IP addresses, including details like their subnets, status, hostname, and associated hardware.

See the following for more information on IPAM:

Network Access Control, sometimes called "NAC", is the process of restricting unauthorized users and devices from gaining access to a corporate or private network. NAC ensures that only users who are authenticated and devices that are authorized and compliant with security policies can enter the network.

See the following for more information on NAC:

Michelle Poysa
IT Project Manager III
585-475-2835
Shawn Plummer
ITS Director
585-475-5348
Geremy Gersh
Associate CIO and Chief Technology Officer
585-353-6126
Alex Polge
Network Engineer II
585-475-6288
Arthur Miller
ITS Network Engineering Manager
585-475-6161
Jim Shanks
Network Engineer III
585-475-5560
Joshua Winterkorn
Network Engineer II
585-475-6589
Kevin Schoenfeld
Network Engineer IV
585-475-7660
Robert Heine
Network Engineer II
585-475-4909
Ronald Soriano Cabrera
Network Engineer II
585-475-5579
Tony Lam
Network Engineer III
585-475-5566
Valerie Slujalkovsky Torchio
Network Engineer II
585-475-5844

Late July & August 2025

  • MarComm reviewed Network DDI Policy draft
  • Demo of Network DDI solution with policy feedback participants that were interested
  • Recommendation for COTS solution was submitted and accepted
  • Security review documentation gathering underway
  • Started the internal to ITS conversation about self registration process (self-registration of devices using start.rit.edu) 
  • Started the internal to ITS conversation about behind the scenes, migration aligned, planning and work

June & July 2025

  • Further exploration of solutions to assess ability to support Network DDI Policy
  • Build and Submit Recommendation to RIT Leadership
  • Meet with ITS Leadership to share Network DDI Policy
  • Meet with Marketing and Communications to give overview of the project
  • Plan and Execute demo for those interested, from the Campus IT conversations
  • Plan and discuss the device self registration process (Computers functionality on start.rit.edu) that will move out of start.rit.edu with the Web Team
  • Updated data to Campus IT partners in support of moving to new 3rd levels
  • Understand the current process for creating new 3rd levels

May 2025

  • Draft Recommendation to leadership
  • Preparation for extended testing 
  • Prepare for those that want to see raw solution in action
  • Address Network DDI Policy “holes”, collaborate with Web team on new policy
  • Prepare to meet with ITS Leadership to share Network DDI Policy (after MarComm)
  • Prepare to meet with ITS Managers to share Network DDI Policy (after Leadership)
  • Reformat the Policy conversations so that they are more conducive to larger groups as opposed to smaller groups, as well as less detailed and more tailored to
  • Will this impact me?
  • What teams are impacted?

Work continues, however the technical team has had shifts in their prioritization that has caused a slow down on this project work.

April 2025

  • Shared draft policy with Executive Sponsor, Primary Stakeholder, and PMO Director for Feedback
  • Continuing conversations across campus to share draft Network DDI Policy 
    • 11 Conversations across campus across: GCCIS, Student Affairs, ITS Support (Hannam), Apps Dev (Seary), NTID, ISO, CAD, Library (Blevins), GIS
    • Campus IT Update and 1 “Open Project Hours” session of 3 held at the suggestion of executive sponsor
  • Further refinement of Network DDI Policy
  • Discussions with Apps Dev regarding 3rd level domains and existing policy
  • Project team and Systems Team discussions of technically related issues
  • Continued development of materials for leadership and education
  • Continued refinement of inquiry quotes
  • Creation of new 3rd level for the network team to start migration work (net.rit.edu)
  • Back to 2 week sprints after 1 week sprints for Proof of Concept

February 2025

  • Continuing Execution of Proof oConcept (POC)

  • Network DDI Solution Evaluation

    • POC round 1, concluded with our 1st vendor!

      1. core and non-core participants in POC filled qualitative product survey

      2. tests and scenarios completed, with pass/fail against requirements captured

    • POC, round 1, is underway with our 2nd vendor!

  • Preparation for the callback round of the POC

  • Outreach and execution of 1:1 and small group conversations to 

    • (Re) Introduce and receive feedback to improve

      • Project principles, architectural positions

      • Draft Governance

    • Start to understand migration planning and needs

    • Build "next round" conversation participants

  • Scheduled Campus IT updates

  • Refining documentation, including project timeline

  • High level POC schedule

    • Round 1 (1/13/2024 through 3/7/2024): 3 POCs across the major players in the Network DDI space

    • Round 2 (3/10/2024 through 3/28/2024): 1 eliminated, at most 2 progress to hardware tests during callbacks

    • Procurement and Legal continue their engagement

January 2025🎊 Happy New Year!!🎉

  • Draft 1 Governance is in the works after reviewing Draft 0 and getting feedback

  • Continuing Preparation and Execution Related to Proof of Concept (POC)

    • Proof of Concept(s) (POCs) and interactions with vendors are starting

    • Continuing outreach to planned POC participants (or their supervisors)

      1. Requesting their participation

      2. Meetings (re)introducing them to the project and sharing project material to receive feedback

    • Creating POC qualitative product and comparative assessment surveys

    • Refining documentation

      1. Project Reference Material

      2. Presentations

      3. POC quantitative assessment for core team

      4. Quantitative POC assessment checklists for core team

    • High level POC schedule

      1. Round 1 (1/13/2024 through 3/7/2024): 3 POCs across the major players in the Network DDI space

      2. Round 2 (3/10/2024 through 3/28/2024): 1 eliminated, at most 2 progress to hardware tests during callbacks

    • Procurement and Legal continue their engagement

We hope that you are having a wonderful start to the new year!

 

December 2024 -- Happy Holidays!!

  • Draft 0 of Governance is being "tested", Draft 1 will be updated post feedback

  • Vendor demos

  • Continuing Preparation for Proof of Concept (POC ) approach

    • Outreach to planned POC participants (or their supervisors)

    • Documentation to create / update

      1. Project Reference Material

      2. Presentations

      3. Daily POC schedule

      4. Vendor communications

      5. POC assessment for core team

    • High level POC schedule

      1. Round 1 ( 1/13/2024 through 3/7/2024 ):  3 POCs across the major players in the Network DDI space

      2. Round 2 ( 3/10/2024 through 3/28/2024 ): 1 eliminated, at most 2 progress to hardware tests during callbacks

    • Procurement and Legal have been engaged

... and finally ... enjoy winter shutdown!!

We hope that you and your friends and family have a lovely holiday season!

 

November 2024

  • Review initial positions aligned with principles, backed by data with executive sponsor and primary stakeholder

  • Strawman Network DDI governance related to subdomains

  • Preparation for vendor interaction

    • Completion of a 1.0 version of RFP Requirements document

  • Preparation for Proof of Concept (POC )

    • Outline POC approach and participants

    • Completion of version 1.0 POC architecture

    • Creation of a "drop in" test environment ready to host POC products

    • Creation of a test plans and scenarios aligned with requirements

  • Continuing "Does this/How does this affect me" documentation to address

    • FAQs

    • Help with learning "just the right amount" of information

  • Assessing needs from other ITS teams as the project progresses

  • TL;DR: The team is exiting the Requirements Refinement phase and entering the Proof of Concept/Acquisition phase which is expected to last through April 2025

... and finally ... we start the holiday season (and the season slow down) 

The team hopes that you and your friends and family have a lovely holiday season!

 

October 2024

  • Reviewed initial positions with architects and technical domain experts in ITS

    • Allowing time for formal responses from individuals, awaiting any data supporting opposition to positions

    • Review any data provided and do analysis as to whether the data indicates an update to current positions is warranted

    • A follow-up meeting will be scheduled to review what we learned from the data

  • Preparation for vendor interaction

    • Preparation and submission of IAPQ

    • Refinement of a 1.0 version of RFP Requirements document

  • Preparing for proof of concept

    • Building POC architecture, testing scenarios, and test plans

    • Capturing the groups needed for participation in the POC

  • Preparing strawmen for aspects of Network DDI governance

  • Migration analysis is starting

  • Starting "Does this/How does this affect me" documentation to address

    • FAQs

    • Help with learning "just the right amount" of information

 

September 2024

  • The technology / governance / personas groups are converging to work together as a team

  • Project team is compiling holistic, draft material that will support initiating vendor conversations as well as more technical conversations throughout ITS and with the campus community.

  • Initial review and incremental updates of Draft 0.0

 

August 2024

The Netcomm team intentionally focused on customer satisfaction by setting aside a lot of time over August to support move in and first week of classes.

  • Technology Working Group

    • Continue to develop technical requirements for each requirement category with scenarios and outlined tests so that we are prepared for proof of concept and re-engaging with vendors

  • Governance Group

    • Continuing to develop understanding of RIT Network DDI current governance and operating standards

    • Continuing to develop understanding of peer universities Network DDI governance and operating standards.

      1. Met with University of Rochester and University of Maryland and Duluth (plans to meet with several other colleges were non-responsive)

  • User Stories / Personas

    • Campus IT event to help us to gather user stories that will be used in creating user requirements

      1. Thank you to those of you that particiated in the event!  We held 16 small conversations (14 with unique teams) and have scheduled many follow-up conversations.

 

June / July 2024

  • Formation of core networking team working groups to lead

    • Outlining approach for requirements gathering, in preparation for (technology)

      • Proof of Concept

      • Reengaging with vendors

    • Understanding of Network DDI current operational standards (governance)

      • Conversations to gather various perspectives on what guides how we make decisions today.

    • Understanding of how peer institutions make decisions in the Network DDI space (governance)

    • Understanding the community needs in the Network DDI space (user stories)

The team has reduce capacity as they take both planned and opportunistic PTO in the summer.

 

April / May 2024

  • High level, 1:1, starter conversations with partners, stakeholders, and those likely impacted by the Network DDI project.

    • RSC, Student Affairs, Saunders, CampusIT (Library Tech, Saunders), SHED Makerspace, CTL

      • More to come!  Would you like to have one of these 30 minute conversations?  Reach out and we'll make that happen! 

  • Continuing current state analysis (Understanding the Network DDI landscape as it exists now)

    • Network engineer story/journey mapping pair work to team view

    • Shared learnings for lenses: Liner notes (interconnections), Navigator (path from where we are to where we need to go)

  • Start ideating about potential future state

  • Continuing to "kick the tires" on couple of solutions in the DDI space

  • Continuing the learning, "Talk to Strangers" exercise

  • Continuing to develop user stories and our understanding of the needs of campus

 

March 2024

  • Current state analysis (Understanding the Network DDI landscape as it exists now)

    • Workshops (core team)

      • Retreat (personas, empathy maps, user story mappings) (3/11/2024)

      • Network engineer story/journey mapping (3/25/2024) ongoing

    • Shared learnings for lenses: Auth DNS, DHCP, CLAWS permissions

  • Continuing to "kick the tires" on couple of solutions in the DDI space

  • Alignment discussions 

  • Meetings to discuss uncovered work

    • Serial to Hostname, high level conversation (3/25/2024)

 

February 2024

  • Core project team rally with executive sponsor (2/6/2024)

  • Workshops to understand current core team knowledge and build team knowledge (2/20/2024)

  • Current state analysis underway, scope refinement

  • Planning sustainable communications for engaging stakeholders

  • Meetings with DDI talking points

    • Geremy Gersh Monthly staff meeting (2/22/2024)

    • CampusIT (2/26/2024)

    • ITS Management Team Meeting (2/27/2024)

 

January 2024: We've only just begun!

  • Core team formed

  • Creating

    • Project operating principles

    • Methods of communication 

  • Michelle Poysa joins the team as Project Manager

Your Questions

Thank you for asking! Here are the questions we have received, with answers when we have them

Q1: Will there be some deliberate body of work to look at DNS filtering, DNS sec? Will we have assurance that it's not spoofed?
A1 (Feb 27, 2024): Yes, we want to build a platform that we can build those things on top of, sustainably, reliably.

Q2: Is there anything about UX (User Experience) that you intend to change with this project?
A2(Feb 27, 2024): TBD.We'll consider it a win if it's intuitive enough that the process guides itself.

Q3: Will the DDI solution/platform integrate with Service Now?
A3 (September 5, 2024): Although we can't answer specifics about particular applications integrating with a future DDI platform, we do anticipate that the new DDI solution will have the capacity to integrate with other RIT systems.

Q4: Will configuration/setup of Student Affairs digital displays, including Apple TV players and Peloton bikes in the fitness center, which are connected to the network be affected by this project?
A4 (September 9, 2024): Here are some answers, please reach out if they do not answer your question

  • If you normally submit a ticket with RSC to have devices registered, your process is likely to remain the same
  • There is no need to register a device that is using wifi via eduroam
  • Will the DDI platform become utilized for possible use by the RIT Service Desk, or will it be delegated to a specific team?

  • The RIT Service Desk gets tickets for DNS changes, computer registrations, and the like. How would DDI impact this process?

  • Would CampusIT have full access to the platform? EG: Large scale projects in GCCIS needing modifications to 30+ computers, DNS, registrations, etc.

There are times when a college’s local support team moves a large number of devices and need multiple CLAWS entries deleted/added for the devices. Right now, we would add/remove these objects in CLAWS as computer items. DDI doesn’t use computer objects, so how would a large move/CLAWS adjustment work with the new DDI platform in regards to DHCP/DNS etc?