OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-rim message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Questions & Observations #1: Don's IF SC Use Cases


Hi Everyone,

Don McGarry produced a pdf of a set of Visio files as Use Cases and 
uploaded them 2 March 2010.

http://www.oasis-open.org/apps/org/workgroup/emergency-if/download.php/36650/Visio-DE_IF_Use_Cases_v1.vsd.pdf

I happened to be out of pocket at the NCOIC March Plenary at the time 
and didn't notice this until it was pointed out to me yesterday in a 
call with Dave Ellis. If I had been here I would certainly have asked a 
number of questions and made a few observations about these diagrammatic 
illustrations. However, I found myself at a loss when asked how I could 
support something I had never seen, to which I said I couldn't and it 
was at this point that Dave pointed me to this file.

So this sets up an interesting set of disconnects for me wrt how I want 
to respond to this as it relates to the ValueListURx discussions in both 
the Infrastructure Framework and the Reference Information Model SCs. I 
assume we all know what ASSUME stands for? All puns intended.

Now, it looks to me like we have had dueling assumptions, and both sets 
of assumptions appear to have been asserted and defended without giving 
the opposing set of assumptions the benefit of the doubt, and both have 
been argued out of context, in my opinion.

For now, in this particular message, I'm going to stick with just asking 
my questions about this set of Use Cases. I will be composing and 
sending out a couple or a few more messages where I hope to focus on 
different specific aspects of this discussion.

I will give them separate Subject Lines so, hopefully, we can harvest 
any further discussions more easily. I've tried this before and it 
usually breaks down because people ignore Subject Lines which would 
otherwise serve to collect related discussions in an easily referenced 
way and react only to specific comments within a message. I don't expect 
this to be any different, but I keep trying in the hope that one fine 
day, it will "take."

Question #1: What list is it that the user wants to update?

This makes an incredible difference since, (in my opinion) IF it relates 
to the user's social structure; e.g. a change in the permissions 
(policy) assigned to a given role (job description and title) for a 
position in Mitre or OASIS or Foo or Bar or The Dept of Redundancy Dept; 
THEN (In my opinion and in any repeatable Service Oriented pattern I 
work on) it definitely should not be submitted to the List Server or the 
Https Server or the Router through any external network In-Band.

My opinion (with the understanding that this Infrastructure is only now 
beginning to be implemented):

It should be submitted through the social structure's duly authorized 
method to a Third Party Registry (possibly a public-private shared 
resource) or Broker Service where it can be separately validated, 
authorized and authenticated before being propagated to the network 
routers where it would be updated system-wide just like DNS. I could 
argue that no significant change should be submitted In-Band, but I 
think that for the next few years we can probably allow simple changes 
in the kind of ValueLists which are aimed solely to document a given 
jurisdiction's facilities, terminologies and equipment names to simply 
be published separately and shared among the partners with whom the 
jurisdiction has mutual aid or other service level agreements. I would 
envision those lists being shared by municipalities and counties in 
shared DBs once we educate them to the value of such datasharing.

I recognize that this seems like a more heavyweight process than may 
seem needed, but I think that there is more than sufficient need for 
verifiable security, financial liability assurance, audit trails and 
confidence, as well as scalability. Once it is done a few times, we can 
learn how to streamline the process, and once in place, maintenance 
should be much easier than most people think. However, it does require 
practice and making that maintenance a regular SOP. We need to set up 
24/7 365 testbeds anyway, so this should help take the sting out of the 
learning curve, especially if we can use students to do the initial 
documentation.

Cheers,
Rex



-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]