Network Access Services SLA

2.2.2

– beyond the annual report, is there a portal for customers to monitor network uptime and issues?
– 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.
– would switches fall under the 2 business day failure replacement window? What happens if it’s a device affecting an entire building?

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:

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

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

-If a condition is not listed, then would customers assume it is a core-service and they are not to be charged for it?

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

– 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?

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

– 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)?

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

– 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 where a charge could occur, should a customer sign off and notification procedure be documented within this SLA?

• This reply was modified 8 years, 9 months ago by ccovey01.

– 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, 9 months ago by dstaylor.

Charge for Network Access

Sean, thank you for the detailed responses.

-“We would like to point out that while you are not currently charged for ‘network access, that is subject to change”

This seems to allude to some significant changes coming along – would it be possible to schedule meetings with IT UNM and IT Agents to provide a roadmap for these changes?

Monthly Fees

“If a department needs firewall service that is customized for their area, they will be charged a monthly charge for the dedicated firewall context”

-In the past, most of us were accustomed to one-time charges for discrete work like a firewall change – what other monthly charges will now be possible? The Service Catalog doesn’t seem to reflect the monthly charge http://it.unm.edu/servicecatalog/asset_list.php?type=2&a_id=136

DNG

Sean, not sure what DNG is? I couldn’t find it in the catalog
http://it.unm.edu/servicecatalog/results.html?q=DNG

Grandfathering

“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.“

It looks like this SLA, as it is now written:

• would allow a customer to lose a business to process to a re-configuration

• would not provide any accommodation to the customer if they did not receive prior notification

• and could leave the customer on the look to pay to fix the break (unintended though it was).

I think we all understand that improvements need to be made, and that those will at times lead to breaks – but perhaps this SLA could make it ironclad in such cases that customers will not be charged, particularly if they’ve already experienced a business disruption?

Cost recovery for a customer’s new requests makes sense, that’s only fair. Networking will likely uncover odd, older configurations, undocumented firewall rules, etc., over time. But what is non-standard now was ‘standard’ at the time, and supported customers’ business processes for what may have been decades, even to this day. In which case, those configurations have become in practice part of the core-service.

I don’t have an answer for this dilemma, but I’m wondering if perhaps a committee or IT Agents should develop some grandfather clause for this SLA that fairly balances Networking’s resources with customers and their longstanding business processes, which are dependent on these ‘non-standard’ configurations? One item that could really help smooth acceptance would be a detailed discussion of the prior notification process in those cases.

• This reply was modified 8 years, 9 months ago by ccovey01.