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: RE: [emergency-rim] RE: [emergency-if] RE: [emergency-rim] Questions & Observations #1: Don's IF SC Use Cases


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 



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