...
[13:52:14 CST(-0600)] <apetro_> the open-ended description field might work kinda okay for that today, but might be some profit in embiggening the registrations to track that
[13:52:23 CST(-0600)] <Ozy_work> yeah
[13:52:25 CST(-0600)] <apetro_> notify on errors, perhaps
[13:52:43 CST(-0600)] <apetro_> could get it down to a single email address per service
[13:52:55 CST(-0600)] <apetro_> and then if you want it to go to multiple folks, point it at an alias or list or something.
[13:53:15 CST(-0600)] <Ozy_work> well, we use SSO_ID, which is an internal, unique identifier that links to the person record in another table
[13:53:51 CST(-0600)] <apetro_> yup
[13:54:06 CST(-0600)] <apetro_> I suppose if it's a user id, that'd be great for affording some kind of service-owner-view on services registry management
[13:54:17 CST(-0600)] <apetro_> maybe these are two different features
[13:54:22 CST(-0600)] <apetro_> notify an email address on failure
[13:54:32 CST(-0600)] <apetro_> enumerate set of zero or more userids of service owners
[13:55:09 CST(-0600)] <apetro_> getting to the end of time I can afford for IRC today
[13:55:18 CST(-0600)] <Ozy_work> same here
[13:55:20 CST(-0600)] <apetro_> but I've really appreciated hearing about what you're really doing with CAS
[13:55:29 CST(-0600)] <apetro_> and welcome further feedback / discussion / input
[13:55:40 CST(-0600)] <Ozy_work> PM'd you the headers and an example entry
[13:55:44 CST(-0600)] <apetro_> want to follow through on incremental but real services management improvement for 3.5
[13:55:48 CST(-0600)] <apetro_> ]awesome
[13:55:51 CST(-0600)] <Ozy_work> i gave you my email if you have anything specific
[13:57:16 CST(-0600)] <Ozy_work> those two features are our most heavily.... needed... features
[13:57:35 CST(-0600)] <Ozy_work> all the changes are related to requirements, directly
[13:57:58 CST(-0600)] <apetro_> awesome
[13:58:45 CST(-0600)] <Ozy_work> have a good one, and dont hesitate to ask if there is anything we can do