This is a new model that is being proposed so that we can better keep up with the costs of running the firewalls such as annual maintenance and hardware refresh.  This model has not been put into practice yet and customers will be notified prior to implementation if approved.

I apologize, DNG is our groups abbreviation: “Data Network Group”.

– beyond the annual report, is there a portal for customers to monitor network uptime and issues?

ITAlerts is the location to monitor any ongoing issues, or upcoming planned outages.  At this time there is not a public portal for viewing our network monitoring application.  We certainly recognize that this would be useful to the campus community and will investigate whether access can be made available in a format that will be useful to our customers.

– in the past, network performance has been affected by security issues – it’s understandable that UNM would not want to publish publicly on IT Alerts what the exact cause is. Would it be possible to publish, behind a NetID site, more detailed information for the UNM IT community? With an understanding of the situation, the UNM IT community could monitor and improve their security posture, and inform end users, generally, that the issues are due to an external threat.

Major P1 incidents are reviewed internally, and then presented at IT UNM in order to give the campus community a better understanding of major incidents that have occurred.  Whether or not a site should be created for posting incident updates seems to be inclusive of all IT SLAs and beyond the scope of just network access.

– would switches fall under the 2 business day failure replacement window? What happens if it’s a device affecting an entire building?

The two business day text is a typo from a previous draft of this document, so we will update it.  UNM IT will be alerted within 5 minutes of a switch failure.  Every effort is made to keep sufficient spare parts on hand to respond to equipment failure immediately.  In the worst case, we would have to engage a vendor for next day replacement of hardware.  If this situation arises, we will always attempt to find a temporary solution to enable at least some functionality while we wait for equipment to arrive.

3.1 and 5.1
The KSA report references cost-recovery and so it appears that departments may now need to pay for things they didn’t previously (5.1), but may also need to pay for changes initiated by Networking/Security (3.1).
It makes sense to clearly define in this SLA what services will incur charges, and what will remain core-services – if departments are paying for services, their expectations will be higher. Costs and related service expectations are then best noted here.
To avoid misunderstandings, it would be useful to have a well-defined list:

The KSA report does reference cost-recovery.  However, the Networks area has been a cost recovery model for quite some time, so this is no change to the business model.  We would like to point out that while you are not currently charged for “network access,” that is subject to change and we would certainly update the Service Catalog (which is the appropriate document for costs for the service).  We just wanted to re-iterate some of the common costs in the SLA, since most customers haven’t reviewed the Service Catalog.  The Service Catalog is referenced in paragraph 2 for your convenience.

– of the customer initiated requests that will incur charges (firewall changes? DNS additions?)

Minor requests to services such as firewall changes and DNS additions will not be subject to a charge, and are provided as part of the core service.  Note that there may be charges for department specific services.  For example, a standard firewall will be applied to all departments on campus.  If a department needs firewall service that is customized for their area, they will be charged a monthly charge for the dedicated firewall context.  Changes to that dedicated context would be covered under the monthly service fee.
Other customer initiated requests that are larger in nature (i.e adding an additional switch or wireless capacity) will also have charges applied.  Again, the Service Catalog is the appropriate place to point out billable services, and we will always let the customer know prior to performing any work.

– of all UNM Networking initiated changes that will be charged to customers (VLAN requirements? subnet redesigns?)

UNM Networking initiated changes will not be charged to customers under normal circumstances.  Situations that arise from remediation of security risks or non-standard configurations may still incur a charge even if the change is initiated by UNM Networking.  An example of this would be if IT Security issues a policy to block a service at the campus edge.  If the department needs a solution designed that will allow them to continue using the blocked service while maintaining the security of the rest of the network, then a charge would be expected to be incurred.

– Bullet 2 – deactivate hosts and departments
– what is the notification process prior to deactivation?

Most notification efforts will occur after the deactivation and not before.  This is due to the fact that deactivation is always  in response to an active threat and must be mitigated immediately.  In the case that a specific host(s) cannot be quickly identified, the smallest affected network segment that can be identified will be deactivated and departmental IT will be engaged to further isolate the compromised machine(s) prior to restoring network services.  In all cases, notification will occur as soon as possible and Central IT will remain engaged throughout the resolution process.  

– in routine, non-emergency cases where UNM Networking or Security initiate a change that could affect departments, what sign-off or notification process would apply?

ITAlerts will have all changes of this nature posted in advance.  If we are aware of a department that will be specifically affected by such a change, we will of course proactively reach out and try and give notification.  Due the variety of services on campus we will not always know who will be affected, therefore it will be important to monitor ITAlerts for changes that will affect your environment.

– can a department be charged for work if there was no prior sign off or notification?

If steps are taken by IT Networking to respond to an infection or misconfiguration of department resources, it is reasonable to assume that a charge will also be incurred even if no notification was given.  In the example mentioned above where an exception is needed to a new security policy or IT standard, charges will have to be discussed on a case by case basis.  If the charges are for a customer initiated Service Request, we will always communicate the costs and request a billing index and approval prior to completing the billable work.

– what protocol is followed if a network change interrupts a department’s established business process (assuming the process itself did not represent a security issue)?

The only non-security related ones I can think of would occur due to human error in IT Networking.  Unfortunately this does occasionally happen and we work with the department to resolve the issue as soon as we know about it.  When such incidents occur we will always notify the customer of the mistake that was made, and what steps we took to correct it while at the same time ensuring our documentation is up to date and team members are cross trained on the mistake that was made so it can be avoided in the future.

– is there a cost to the department to remediate the change or create a workaround?

No.  If IT Networking is implementing change, we are doing so to improve the network performance and/or security.  Charges would only result if a customer needs a complex configuration set up, and has coordinated the change ahead of time.

– would items 6.1 and 6.2 then apply, where an Incident has occurred affecting the department, and would be assigned a Priority designation?

In all cases a ticket should be opened.  If a service interruption has occurred this will be treated as a high priority ticket and addressed immediately.

In all cases where a charge could occur, should a customer sign off and notification procedure be documented within this SLA?

This SLA is not intended to address special case scenarios and simply points out that there are instances where charges may apply.  DNG service rates are posted in our service catalog for special case scenarios.  The Service Catalog is referenced with a link in Paragraph 2 for your convenience.

• This reply was modified 8 years, 4 months ago by dstaylor.