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

[Gary Ham <gham@grandpaham.com>]

Not to mention the TEP interoperability work going on this month. De  
wrapping - multiple applications. And (of course since it is me  
writing this) the expanded capability of dm-open 2.0 when it comes  
availabe.

Sent from my iPhone

On Apr 2, 2010, at 7:08 PM, "Lee Tincher" <ltincher@evotecinc.com>  
wrote:

> Don,
>
> I respectfully disagree on one point in this...not only does DNDO  
> use the DE
> for virtually every message exchange - I personally have it as the  
> main
> focus of our commercial product that does a whole lot more than  
> point to
> point exchanges...I even use it to carry multiple CAP messages as  
> payloads
> for routing distribution down the pipe...it carries HAVE and SiTRep  
> reports
> as well as Justice defined NIEM IEP's...I rely heavily on it as do  
> all of
> the recipient and "re-distributors" that use our product....
>
> Thanks,
> Lee
>
> The aim of education should be to teach us rather how to think, than  
> what to
> think - rather to improve our minds, so as to enable us to think for
> ourselves, than to load the memory with thoughts of other men.  ~Bill
> Beattie
>
>
> -----Original Message-----
> From: McGarry, Donald P. [mailto:dmcgarry@mitre.org]
> Sent: Friday, April 02, 2010 4:11 PM
> To: rexb@starbourne.com; Hans Jespersen
> Cc: Gary Ham; emergency-if@lists.oasis-open.org;
> emergency-rim@lists.oasis-open.org; emergency@lists.oasis-open.org
> Subject: [emergency-rim] RE: [emergency-if] RE: [emergency-rim]  
> Questions &
> Observations #1: Don's IF SC Use Cases
>
> All-
> 1. My feeling is that if it doesn't stand the test of time we can  
> change it.
> Frankly I don't see how changing one character in the name of one  
> element
> will cause any harm.  In fact we really aren't changing anything  
> outside the
> name since once again I point out it is typed as <string>.  I still  
> like my
> idea of moving all of the URN stuff into a routing sub-element and  
> putting a
> generic ValueList component in the root.
> 2. Our method for people not mucking it up now seems to be no one  
> using it
> at all, beyond just passing point to point data.  I'd rather have  
> people
> start using it and have them grow with the standard rather that have  
> the
> "perfect standard" that is so theoretically wonderful that no one  
> uses it.
> 3. I fail to see how preforming an unintended DoS attack on an  
> improperly
> tuned webserver applies to this, but point taken that people can and  
> will
> mess anything up.
> 4. I'm still waiting for what "should" be a simple answer to my
> questions...What does limiting our spec to a URN buy us?  If it was so
> important why was it completely overlooked in 1.0?  What is the  
> architecture
> that disproves a unique string (which could be a URI) can't do the  
> same job.
>
> If we are willing to agree to compromise and move on, so be it.  I  
> would
> suggest that given this outcome, that all non-constructive criticism  
> also go
> with it.  As a researcher who's completing my dissertation in this  
> stuff I'm
> more than happy to accommodate anyone who can present legitimate  
> technical
> contributions that will point out oversights in my (or any other OASIS
> member's) product or work.  However, opinion, undocumented claims,  
> etc. are
> starting to wear very thin and are without merit.  I'm sure I speak  
> for many
> folks on these committees when I ask that that comments, opinions, and
> criticisms be brought out only when there is solid technical  
> evidence to
> support the counterpoint.  I think this is in both the true spirit of
> industry, academia, and general to overall productivity.
>
> -Don
> Office: 315-838-2669
> Cell: 315-383-1197
> dmcgarry@mitre.org
>
> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com]
> Sent: Friday, April 02, 2010 2:31 PM
> To: Hans Jespersen
> Cc: Gary Ham; McGarry, Donald P.; emergency-if@lists.oasis-open.org;
> emergency-rim@lists.oasis-open.org; emergency@lists.oasis-open.org
> Subject: Re: [emergency-if] RE: [emergency-rim] Questions &  
> Observations #1:
> Don's IF SC Use Cases
>
> My intention to reply in depth to Don's post has managed to get pushed
> farther and farther down my priority list, especially since Gary's
> proposed compromise, which I indicated I could live with, and today  
> has
> been particularly difficult in that regard, so I must, in essence,  
> throw
> in the towel with a couple of comments only.
>
> While I can live with Gary's compromise, I don't think it will stand  
> the
> test of time, but we'll see about that. That's just my opinion. Having
> weighed the opposition, I decided that fighting it didn't make sense  
> and
> was wasting precious time. I don't like it, but that's happened before
> and it hasn't proved fatal to me personally, and not as far as I  
> know to
> anyone else, yet.
>
> The problem with the compromise is that no matter how well we caveat  
> it,
> people will find a way to muck it up. Hopefully we can catch as much  
> of
> that as possible in testing. Case in point, when we initially finished
> CAP one of our three letter agencies decided to use it and promptly
> caused its network to crash because so many of their systems went out
> over the web at the same time to get the schema and validate it. I  
> would
> never have guessed that folks with that much experience and  
> intelligence
> would not actually cache the schema locally, but they didn't.
>
> Stuff happens.
>
> I will ask that we carefully and accurately document our requirements
> and our caveats. I think it would be especially helpful if we  
> carefully
> delineate where users can safely use <explicitAddress>. Where URNs are
> required for policy, we will need to ask that those networks make that
> clear so that we minimize inadvertent mismatches.
>
> Cheers,
> Rex
>
> Hans Jespersen wrote:
>> Comments inline denoted [hj]
>>
>> -hans
>>
>> -----Original Message-----
>> From: Gary Ham [mailto:gham@grandpaham.com]
>> Sent: Wednesday, 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: 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.
>>
>> [hj]or not as the case may be. Not every ValueList element MUST be  
>> used
>> by every DE implementation.
>>
>> 2. If your network does not find a URN it needs for distribution,  
>> refuse
>> it, or do not redistribute.
>>
>> [hj] or add one so that downstream nodes know more about the  
>> message and
>> can treat it accordingly.
>>
>> 3. Any URI would be acceptable in the schema, but only those with  
>> formal
>> URNs might be used on some networks.
>>
>> [hj] Seems fine to me as long as everyone understands that any URI  
>> can
>> be in these fields and they should not fail to parse, choke, or drop
>> messages if it's a URN and not a URL (i.e the opposite of #2 should  
>> not
>> happen).
>>
>> 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.
>>
>>
>> R/s
>>
>> Gary
>>
>>
>> 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;
>>>
>> emergency-rim@lists.oasis-open.org
>>
>>> Subject: [emergency-rim] 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/3
>> 6650/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
>>>
>>>
>>> --- 
>>> ------------------------------------------------------------------
>>> 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
>> http://grandpaham.com
>> 703-899-6241
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>>
>>
>
> --
> 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
>