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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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

Subject: RE: [emergency] Re: [emergency-if] RE: [emergency-rim] Questions & Observations #1: Don's IF SC Use Cases


We are holding an Emergency Standards workshop at GeoWeb 2010 (NIEM,
EDXL, CAP etc). IF you are interested in participating let me know.


-----Original Message-----
From: Gary Ham [mailto:gham@grandpaham.com] 
Sent: March 31, 2010 8:56 AM
To: McGarry, Donald P.
Cc: rexb@starbourne.com; emergency-if@lists.oasis-open.org;
emergency-rim@lists.oasis-open.org; emergency@lists.oasis-open.org
Subject: [emergency] Re: [emergency-if] RE: [emergency-rim] Questions &
Observations #1: Don's IF SC Use Cases

Sounds to me like network rules related to ValueList elements
1. Parse them.
2. If your network does not find a URN it needs for distribution, refuse
it, or do not redistribute.
3. Any URI would be acceptable in the schema, but only those with formal
URNs might be used on some networks.

Adds the need to parse to all push redistributors.   But it would seem
to me that they would need to do that anyway.

The rules need to be put into the DE documentation so that it is not
ambiguous. I.e,"Warning: If you do not use a formal URN, some of the
more security conscious networks will not be able to use your document."
But you can use other URI's for categorization, filtering, etc.
Seems to be a reasonable compromise to me. 



On Mar 31, 2010, at 11:42 AM, McGarry, Donald P. wrote:

> Rex-
> Agree with your in-band / out-of-band assessment; however I think we
are getting to bogged down in some implementation details...
> 1. Proponents of the URN feel that it is required to adequately
extract authority context from its structure to do secure routing.
> 2. Proponents of the URI feel that:
> 	a. URIs/URNs/URLs are just structured strings.  Although URNs
imply a unique name; newer principles of REST state that URLs (or more
generally URIs) also can act unique names for resources - including a
name of a list
> 	b. Although URNs can be registered at an authoritative source
(IANA or your own infrastructure), at some point someone needs to go and
verify that unique 	name from the authoritative source.  This can be
done in-band, out-of-band, or periodically; but it still has to be done
and has a host of security issues, not completely dis-similar from
verifying a certificate chain in a registered uri/url
> 	c. If you want to add a dynamic component to your lists; URNs
require that you have a custom URN resolution software to resolve the
URN to a location to pull the list from; If you do an out of band push,
you still need to resolve /authorize the entity pushing the update.
Again, not completely dis-similar from pulling list data from a url
location and authenticating the server through CAS
> 3. The valuelist concept is about flexibility.  Everytime we want to
allow implementers to use their own terminology we plug this thing in.
That's to provide flexibility.
> 4. The DE is about distributing data.
> 5. Since the purpose of the URN/URI is to identify the referenced list
and the authority context associated with it in a "secure" system, if
you only want to work with URN's drop the message when you the first
characters != 'urn'...You need to parse the string anyway...if there are
no 'urn' identified list in the DE...then your system shouldn't be
getting it anyway...
> I think pushing this back to the subcommittee is a bad idea.  To date,
we've been discussing this over and over, yet there exists no
architecture diagram coupled with a use case to refute this point.  If
this was so important in the DE 1.0, why was it typed as <string>?  I
don't think we should have to hold back the DE 2.0 to further "discuss"
this.  Given the perceived "importance" of this structure I would think
that there could be a clear use case and architecture to support the
claims of the URN camp available now.  I think that we are continuing
down the path we have already been down and that we'll end up in the
same spot that we are at right now next quarter if we don't change our
approach to this.
> -Don
> Office: 315-838-2669
> Cell: 315-383-1197
> dmcgarry@mitre.org
> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Wednesday, March 31, 2010 10:32 AM
> To: emergency-if@lists.oasis-open.org;
> Subject: [emergency-rim] Questions & Observations #1: Don's IF SC Use
> Hi Everyone,
> Don McGarry produced a pdf of a set of Visio files as Use Cases and
uploaded them 2 March 2010.
> 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
> Cheers,
> Rex
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-898-0670
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Gary Ham

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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